You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think we also need to have a discussion on how metadata properties should be handled in general.
According to the DTCG spec, you'd put it either in property names starting with $ prefix, or you'd put it into the $extensions under the unique namespace of your tool (e.g. style-dictionary). If I'm not mistaken, $metada props are something that belong to the token authors territory, and $extensions is where tools can put their stuff, so I'm leaning towards refactoring everything to scope and read metadata from that $extensions['com.styledictionary'] namespace
In hindsight, this isn't a priority since we only add metadata internally in the dictionary object on the token level (path, filePath and so on), and on the token level the list of properties is either known or using $ prefixes if user is adding more props, as opposed to in token group level where you can have any property key to indicate a nested token group or token. So there shouldn't be any issues with property collisions.
I think we also need to have a discussion on how metadata properties should be handled in general.
According to the DTCG spec, you'd put it either in property names starting with
$
prefix, or you'd put it into the $extensions under the unique namespace of your tool (e.g. style-dictionary). If I'm not mistaken, $metada props are something that belong to the token authors territory, and $extensions is where tools can put their stuff, so I'm leaning towards refactoring everything to scope and read metadata from that$extensions['com.styledictionary']
namespaceOriginally posted by @jorenbroekema in #1007 (comment)
The text was updated successfully, but these errors were encountered: