amzn
Support for DTCG v2025.10
Proposal
Style Dictionary needs a few updates to align with the newly-published v2025.10 version of the specification. Some are captured in open issues, some I’m proposing in this issue:
- Color: support the new color module
- Border: support new color module
- Gradient: support new color module
- Dimension: #1398 (and #1501 and #1584)
- Duration: #1471
- Resolvers: support the new resolver module
Questions
- Would this constitute a new breaking major release? Or should Style Dictionary support legacy editors drafts and v2025.10 at the same time?
- Which editors drafts should be still supported, in addition to v2025.10? (Are there any difficulties with this?)
- Outside of DTCG format, is there any Style Dictionary JSON that may be particularly tricky / may be broken as a result of some of these changes (I genuinely don’t know, but wanted to ask if anything comes to mind)?
Would love to help contribute to provide support for this. 🙂
#1585 would fix all size tranformers to handle the DTCG Format in a non-breaking fashion.
Since I'm currently unemployed, I don't have the capacity to take this on right now until I find a new job. I've communicated this with @tkgroot as well, the intention is to collaborate as soon as I find some capacity again and get this issue resolved, it's definitely the top priority right now for Style Dictionary.
- Ideally we can do this with backwards compatibility in mind and won't need a breaking version for this spec alignment, but I can't really guarantee it either since some of the changes in the spec are pretty significant.
- We'll have to document clearly some type of compatibility table that shows which versions of the spec which versions of SD is compliant with. This will be good for future updates of the spec as well, so it's clearer whether SD is compliant with updates or not yet. I don't have a strong opinion on how much backward compatibility each major of SD should have with the spec drafts, I think we should take a very pragmatic approach there -> "if we can be backwards compatible without too much hassle, we should try".
- This is a good question, I'm a bit worried about some of the Tokens Studio specific features like math resolution, now that dimension types have a bit more complexity to them. Besides that, it's the expand utility that I am somewhat concerned about. With more token types being objects, we'll have far more cases where a object-value token like typography, will have lots of nested object structures in its value, making it a bit more challenging to correctly expand them into separate tokens for formats that don't have shorthands and require flat values rather than object values.
Edit: fortunately this library has a very high test coverage so a lot of the potential issues/regressions would be flagged by failing tests :)
Thanks for the update @jorenbroekema! Hope you find something fulfilling and worthwhile (after some time off) 🙂
I’m happy to help in the new year with PRs! I’d need help with overall direction, but happy to do the work for scoped-out tasks.