feat: updating to Style Dictionary v4 #3186
Conversation
|
Thanks for the pull request, @PKulkoRaccoonGang! What's next?Please work through the following steps to get your changes ready for engineering review: 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. 🔘 Let us know that your PR is ready for review:Who will review my changes?This repository is currently maintained by Where can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:
When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
openedx-webhooks
added
the
open-source-contribution
✅ Deploy Preview for paragon-openedx ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
PKulkoRaccoonGang
force-pushed
the
Peter_Kulko/style-dictionary-v4
branch
from
70227f8
to
9c58f15
Compare
|
TODO
... ES6 modules |
|
Thank you so much for putting this together! Considering the task of "do some discovery around v4" this is truly above and beyond!
I think it's reasonable to update the
Could you elaborate on this a bit? I worry that moving from Gatsby v4 to v5 would be quite a heavy lift, and I wonder how that compares to some workarounds people have tried gatsbyjs/gatsby#31599 (comment) |
|
Just adding a note based on the discussion in the Paragon WG meeting today: The migration guidelines have a few suggestions for how to handle this - one that seemed to be a good candidate was
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## alpha #3186 +/- ##
==========================================
- Coverage 93.76% 93.76% -0.01%
==========================================
Files 229 229
Lines 3787 3784 -3
Branches 908 908
==========================================
- Hits 3551 3548 -3
Misses 229 229
Partials 7 7 ☔ View full report in Codecov by Sentry. |
| } | ||
| "base": { "source": "$card-border-radius", "$value": "{size.border.radius.base}" }, | ||
| "logo": { "source": "$card-logo-border-radius", "$value": ".25rem" }, | ||
| "inner": { "source": "$card-inner-border-radius", "$value": "calc({size.card.border.radius.base} - {size.card.border.width})" } |
There was a problem hiding this comment.
[curious] Have we looked into whether we can avoid including CSS-specific syntax calc in the token itself, or how such tokens would be transformed outside of CSS variables?
For example, if there is arithmetic like subtraction as in this line, could the token $value be {size.card.border.radius.base} - {size.card.border.width} and have some sort of transform for the CSS variables output to wrap it with calc(...)?
That way, tokens like these would be more portable to other non-CSS based platforms like mobile.
There was a problem hiding this comment.
Dug into this a bit. It appears this still remains a complex problem within the style-dictionary community. There is support for a resolveMath transform, from tokens-studio/sd-transforms; however, when the token outputs references via outputReferences: true | fn, the transformed/resolved math is replaced with the original reference (i.e., a CSS variable with var(--foo: 5px) in this case).
I attempted to craft a solution for tokens-studio/sd-transforms#203, but came to the same realization recently described here:
The big issue is that outputting refs happens on the format lifecycle and wrapping values in calc() statements usually happens in the transform lifecycle that happens before. So even if you wrap the values in calc() in transform, the format part will just undo that work by outputting refs by using the original value.
Either the calc wrapping needs to happen on the format level or the outputting refs util needs to act on the transformed value somehow (keeping in mind the bugs that this used to cause in v3 and not regressing on this again)
There are a couple of open issues to rethink how references are resolved and how values with references in them are transformed for a future v5 version of Style Dictionary, but this topic is rather complex and this issue won't be fixed until we have solutions to that broader topic.
tl;dr; Handling the wrapping of math expressions with the CSS calc syntax remains an open question, and likely will not land in v4 of Style Dictionary per the above. Given this, it probably makes sense to keep the calc syntax for now, but when we begin transforming to non-CSS platforms (e.g., JavaScript, iOS, Android), having calc in the token value itself will present an issue. A possible workaround for if/when this becomes an issue might be to introduce custom transforms for the (future) non-CSS platforms that strips the wrapping calc(...) from the underlying math operations used in the token value.
There was a problem hiding this comment.
This is definitely a very interesting question that we haven't thought about yet. Thanks for your research, now we know more!
A possible workaround for if/when this becomes an issue might be to introduce custom transforms for the (future) non-CSS platforms that strips the wrapping calc(...) from the underlying math operations used in the token value.
It seemed to me earlier that when adding mobile platforms, Style Dictionary would generate the necessary variables taking into account the various CSS tools (calc) that we use for design tokens, converting them into alternatives acceptable for mobile platforms.
I also consulted with Android and iOS developers from Raccoon Gang, they confirmed that there is no alternative to calc CSS. There are tools to do this in the languages of mobile platforms, but it is desirable that Paragon design tokens provide static (integer) values for variables.
I agree with you, most likely in the future (if there are no new Style Dictionary updates) we will have to make additional modifiers for mobile platforms.
Android
<resources>
<dimen name="size_card_border_radius_base">16dp</dimen>
<dimen name="size_card_border_width">2dp</dimen>
</resources>
iOS
<plist version="1.0">
<dict>
<key>size_card_border_radius_base</key>
<string>16</string>
<key>size_card_border_width</key>
<string>2</string>
</dict>
</plist>
Resources
…s format (#3203) * feat: --output-references CLI arg for build-tokens, registers filters, and updates CSS vars format * Exposes `--output-references` CLI argument for `build-tokens` command. Defaults to `true`. Ensures brand package output with the CLI includes references in build output out-of-the-box. * Registers filter(s) `isThemeVariant.{'light'}`, handling future theme variants when implemented (e.g., `isThemeVariant.dark`). * Migrates `createCustomCSSVariables` to use `formattedVariables` to rely on out-of-the-box CSS variable formatting. The formatter still supports token-specific overrides of `outputReferences`. If a token has modifications via `modify`, the modified base reference is not included in the output. * Updates custom fileHeader implementation, including a relative path to design tokens documentation. * Fixes bug with line-height tokens, switching their `$type` from `dimension` to `number` to resolve typography style regressions. * Updates typography tokens related to font size, font weight, and line-height for more consistent naming structure when taking into account mobile. * Updates `@mobile-type` SCSS mixin to support level-specific customization of mobile typography styles for display 1-4. * Renames `"description"` field in tokens to `"$description""` per the DTCG format. * Ensures the "Typography" foundations page properly previews the correct font size for regular "Body" text and includes the missing "HEADING LABEL" example. * Updates to "Colors" page in docs site: * Displays token name instead of CSS variable in the color swatch previews (see screenshot below). * Include `accent-a` and `accent-b` alongside other color names, rather than manually rendering `Swatch` for the accents. * Modifies the grid styles for color swatch preview to be more responsive. * Resolves `NaNpx` bug in `MeasuredItem` component on docs site, while computing the measurements to display for an element (e.g., font size). Instead, it renders an empty block while measurements are resolved. * Updates `CodeBlock` styles on docs site to add its border and background color only to the `LivePreview`, not the entire `CodeBlock` example. * Reduces whitespace on docs site homepage. * Simplifies columns on docs site header, ensuring `SiteTitle` is horizontally aligned in the center.
PKulkoRaccoonGang
force-pushed
the
Peter_Kulko/style-dictionary-v4
branch
from
63a61de
to
da00992
Compare
PKulkoRaccoonGang
force-pushed
the
Peter_Kulko/style-dictionary-v4
branch
from
daffd74
to
a0baaa6
Compare
refactor: corrected expanded tokens refactor: code refactoring refactor: created an abstracted CSS variables refactor: added missing expanded tokens refactor: added missing expanded tokens refactor: small refactoring after review refactor: corrected imports for CSS files feat: expanded --pgn-transition-carousel-base token, some refactoring fix: corrected --pgn-transition-base-timing-function value refactor: some refactoring and updates refactor: corrected progress-bar and typography tokens
PKulkoRaccoonGang
force-pushed
the
Peter_Kulko/style-dictionary-v4
branch
3 times, most recently
from
6676868
to
1be86b9
Compare
PKulkoRaccoonGang
force-pushed
the
Peter_Kulko/style-dictionary-v4
branch
from
1be86b9
to
915d963
Compare
|
@brian-smith-tcril @adamstankiewicz In this commit we removed the brand-openedx theme. Do we want to remove the sidebar toggle button and any mention of the brand in Paragon? 
|
PKulkoRaccoonGang
requested review from
adamstankiewicz and
brian-smith-tcril
| "border": { | ||
| "width": { "value": "1px", "type": "dimension", "source": "$border-width", "description": "Default border width." }, | ||
| "width": { "source": "$border-width", "$value": "1px", "$description": "Default border width." }, |
There was a problem hiding this comment.
[curious] Cross-checking the dimension type with the DTCG spec again, I noticed that it seems you can also define the dimension value and its unit separately, e.g.:
{
"size": {
"$type": "dimension",
"border": {
"width": {
"$value": {
"value": 1,
"unit": "px"
}
}
}
}
}Not sure if this is something style-dictionary v4 supports out-of-the-box. Do we think it's worth exploring defining dimension token values and units separately vs. combined as we have it today (i.e., "$value": "1px").
There was a problem hiding this comment.
Since this is what is documented in the DTCG spec I'd think we'd want to move forward with this change. Let's verify this works with style-dictionary v4 and figure out next steps from there.
There was a problem hiding this comment.
For posterity, we tried to update the token definition to adopt the DTCG format spec for $dimension tokens, but it seems to result in unexpected output, e.g.:
--pgn-size-border-width-value: 1; /* Default border width. */
--pgn-size-border-width-unit: 0px; /* Default border width. */When we'd really want something like:
--pgn-size-border-width-value: 1px; /* Default border width. */I've opened an issue upstream in the style-dictionary repository to try to drive clarity in the expected output for $dimension tokens using the DTCG spec / report a bug, if applicable: amzn/style-dictionary#1398
Given this, for now, we will keep the Paragon $dimension tokens using the combined $value vs. following the DTCG spec.
There was a problem hiding this comment.
I believe all my previous comments have been addressed. This looks great!
Super excited to see all of this come together. Amazing work @PKulkoRaccoonGang!
There was a problem hiding this comment.
Looks great! Appreciate all your iterations on this PR, @PKulkoRaccoonGang! Will be great to see this land.
|
🎉 This PR is included in version 23.0.0-alpha.4 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Description
This PR is an attempt to update the Style Dictionary v3 library to Style Dictionary v4 (including refactoring the design tokens to the DTCG format) + fixed some problems with typography.
Merge Checklist
exampleapp?Post-merge Checklist