Referencing alias without generating

[7studio]

Hi,

Is there a way to include/reference alias without generating entries into output files?

I don't find any solution into documentation, examples or different projects which use Style Dictionnary to load JSON and assign them like alias without include or source.

At this time, I manage to get what I need with the help of filter by excluding tokens with some prop.path but it's very untenable.

Thank you for you help.
Xavier.

[dbanksdesign]

Right now no. Style Dictionary merges all the source files together into 1 big object before any alias resolution happens. Then filtering is the way to remove tokens from the output files. If you have any ideas on how we can make this better we would love to hear it!

[7studio]

Danny,

I think about two ideas :

1. The simplier: enhancing prop object into filter function. For the moment, the object looks like below:

{ 
  value: '#fef1cc',
  original: { value: '#fef1cc' },
  name: 'SecondaryYellow200',
  attributes:
   { category: 'secondary',
     type: 'yellow',
     item: '200',
     subitem: undefined,
     state: undefined 
  },
  path: [ 'secondary', 'yellow', '200' ]
}

IMO, if we add the file path where the property comes from or add the fact that the prop is an include instead of a source (adding the two, will be really awesome 😁) will help filter more correctly than it is possible for now.

2. More complex: this should require to publish a new version because it will change the actual behaviour. The idea is that the files added by the include attribute don't output properties. I don't understand the differences and needs about include and source attributes in fact 😅 All files and properties are deep merged all together.

I hope it will help you improve this project.
Xavier.

[dbanksdesign]

Thank you so much for the suggestions. I like the first idea, especially adding if a token was in 'include' or 'source'.

The thinking behind 'include' and 'source' is for creating parent-child style dictionaries. In my team at Amazon, we have a core style dictionary that both web and mobile inherit from, core is the parent and web and mobile are children. The mobile and web style dictionaries 'include' the tokens from core, and have their 'source' as any additions/overrides. One of the differences between 'include' and 'source' is that Style Dictionary will warn you (or throw an error depending on the log type) if 2 files found in 'source' would override parts of the object, but it won't if a file in 'source' overrides something in 'include' as that is what is intended. Hopefully that helps!

[7studio]

Thank you for your detailed explanation 😊 I had not imagined this use for my project but it's really interesting.

Do you want me to open a PR or do you add this change yourself?

[dbanksdesign]

If you would like to open a PR that would be great! Just to confirm, that PR would add file path and if the token was from 'include' or 'source' onto each token. If you could add test cases to verify the functionality that would be greatly appreciated, and take a quick glance at the contributing guidelines. Thanks!

[davidrpoliti]

+1

[chazzmoney]

@7studio I really like this suggestion. Would love to add it to the project - are you still working on the PR? Do you have any questions?

[7studio]

Hi Charles,
For the moment, my planning is completely full with my project and my baby at home ^^
I introduced this feature in a local copy but I have to solve some problems before submitting my PR:

• all tests for the extend method fail... If I run one describe() block, it works well but not all sequentially...
• validate property names. I started with from for file path and type to know if it's an include or a source. My first intent was to have boolean properties like source: true and include: true but it is more complicated than I thought because there is no callback to alter token into a collision.

If someone has any piece of advice to help me in this work I will be happy to read them 😊

Xavier.

[dbanksdesign]

All extend tests fail? That is really odd.. maybe when you are ready post a PR with tests failing and we can take a look.

For the property names what about filePath and sourceType? Or could we do just one boolean like isSource true/false? My worry about type is that we use that already in the CTI model. It wouldn't actually cause any collisions because these new properties would be on the token itself and not the attributes object, but I'm thinking mostly from a user's perspective.

Thank you for your work on this!

[yinonov]

This is probably one of the first features I was looking for.
When working on web transform it's really important to stick to 1 variable and not re-assigning same value to multiple variables

[dbanksdesign]

This is in 3.0 and available today with npm install style-dictionary@next