Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: expose --output-references CLI arg for building tokens, registers filters, and updates CSS vars format #3203

Merged

Conversation

adamstankiewicz
Copy link
Member

@adamstankiewicz adamstankiewicz commented Aug 31, 2024

Note: Amongst other changes, addresses some of my feedback on the related, base PR: #3186

Changes

CLI Enhancements

  • 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.

Token Management Improvements

  • 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.

Documentation Site Enhancements

  • 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.

Informational Notes

  • [inform] Related to CSS calc defined within tokens, while we could use sd-transforms to register a transform ts/resolveMath (source), it does not wrap math calculations with calc(...), effectively not evaluating the operation in CSS. There's several related issues (example, example) in style-dictionary and sd-transforms about this issue, with no current resolution; only hacky workarounds.

Deploy Preview

N/A

Updates "Colors" page color swatch previews:

Note: screenshot depicts a local checkout@edx/elm-theme

image

Merge Checklist

  • If your update includes visual changes, have they been reviewed by a designer? Send them a link to the Netlify deploy preview, if applicable.
  • Does your change adhere to the documented style conventions?
  • Do any prop types have missing descriptions in the Props API tables in the documentation site (check deploy preview)?
  • Were your changes tested using all available themes (see theme switcher in the header of the deploy preview, under the "Settings" icon)?
  • Were your changes tested in the example app?
  • Is there adequate test coverage for your changes?
  • Consider whether this change needs to reviewed/QA'ed for accessibility (a11y). If so, please request an a11y review for the PR in the #wg-paragon Open edX Slack channel.

Post-merge Checklist

  • Verify your changes were released to NPM at the expected version.
  • If you'd like, share your contribution in #show-and-tell.
  • 🎉 🙌 Celebrate! Thanks for your contribution.

Copy link

codecov bot commented Aug 31, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.76%. Comparing base (0e1ef04) to head (88a2504).
Report is 1 commits behind head on Peter_Kulko/style-dictionary-v4.

Additional details and impacted files
@@                         Coverage Diff                         @@
##           Peter_Kulko/style-dictionary-v4    #3203      +/-   ##
===================================================================
- Coverage                            93.76%   93.76%   -0.01%     
===================================================================
  Files                                  229      229              
  Lines                                 3787     3785       -2     
  Branches                               902      879      -23     
===================================================================
- Hits                                  3551     3549       -2     
- Misses                                 229      232       +3     
+ Partials                                 7        4       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Comment on lines +88 to +92
{
name: '--output-references',
description: 'Include references in the build output.',
defaultValue: true,
},
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[inform] Currently, running build-tokens with the CLI for a brand package (e.g., @edx/elm-theme), the CSS build output does not include the references, i.e. CSS variables, instead hardcoding the raw value.

I believe we want to default to always including references, even for brand packages, to mitigate risk that updating a reference for a style property, won't change the actual style due to the missing use of the CSS variable.

However, I think it's also reasonable to not want this in some cases so having it be an option seems reasonable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

100% agree. Good call/addition!

{
name: '-v, --verbose',
description: 'Enable verbose logging.',
defaultValue: false,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[inform] Improves the utility of warning/error messages resulting from style-dictionary during build-tokens.

@@ -52,24 +65,30 @@ async function buildTokensCommand(commandArgs) {
destination: 'core/variables.css',
filter: hasSourceTokensOnly ? 'isSource' : undefined,
options: {
outputReferences: !hasSourceTokensOnly,
outputReferences,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[inform] Now relies on the CLI option; outputReferences is now distinct from hasSourceTokensOnly.

Comment on lines 69 to 73
formatting: {
fileHeaderTimestamp: true,
},
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[inform] The custom formatters are updated to rely on the default style-dictionary util fileHeader, but rely on the optional formatting.fileHeaderTimestamp to still include the timestamp in the build output.

I don't feel we need the custom message, so long as the timestamp is included.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call! The default header looks like it covers everything we need, and I'm all for reducing complexity (even in small ways like this!)

/**
 * Do not edit directly, this file was auto-generated.
 * Generated on Tue, 03 Sep 2024 13:46:26 GMT
 */

@@ -52,7 +52,8 @@
"prepare": "husky || true",
"build-tokens": "./bin/paragon-scripts.js build-tokens --build-dir ./styles/css",
"replace-variables-usage-with-css": "./bin/paragon-scripts.js replace-variables -p src -t usage",
"replace-variables-definition-with-css": "./bin/paragon-scripts.js replace-variables -p src -t definition"
"replace-variables-definition-with-css": "./bin/paragon-scripts.js replace-variables -p src -t definition",
"cli:help": "./bin/paragon-scripts.js help"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[inform] Adds a way to run the CLI help command from Paragon root.

--pgn-elevation-zindex-400: 400;
--pgn-elevation-zindex-200: 200;
--pgn-elevation-zindex-0: 0;
--pgn-elevation-zindex-fixed: 1030; /* z-index of for fixed element. */
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By relying on the formattedVariables helper function from style-dictionary/utils, we get inline comments from the token's description field, if any. Much of the other logic we had implemented is provided out-of-the-box (e.g., ordering of CSS variables).


return `${createCustomHeader(StyleDictionary, file).join('\n')}\n:root {\n${variables}\n}\n`;
const { outputReferences, formatting } = options;
const variables = formattedVariables({
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[inform] Relies on helper function formattedVariables provided by style-dictionary/utils to format tokens as CSS variables instead of re-implementing much of its same logic here.

@adamstankiewicz adamstankiewicz marked this pull request as ready for review August 31, 2024 19:37
@@ -1,5 +1,5 @@
.pgn__form-text {
font-size: var(--pgn-typography-font-size-small-base);
font-size: var(--pgn-typography-font-size-sm);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The token representing .small was refactored slightly to be named pgn-typography-font-size-sm.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

var(--pgn-typography-font-size-sm)

We will also need to update the changed design tokens in the edx/elm-theme and ensure that in the consuming MFEs that have already switched to the design tokens in the test format, all tokens will be relevant.
Since we use only native CSS variables, consumers will not see an error/warning about a missing token. Such minor changes are unfortunately easy to miss.

I have described this issue before, maybe we should come back to it in the future. Please let me know your thoughts.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@PKulkoRaccoonGang I have a draft PR brewing to account for edx/elm-theme, based on the changes introduced in this PR and the broader v3 -> v4 upgrade (e.g., adopting the DTCG format).

Note: this linked PR also accounts for a few style bug fixes as well that I noticed while QA'ing elm-theme against the Paragon docs site locally.


I have described #3057 before, maybe we should come back to it in the future. Please let me know your thoughts.

100% agreed we should explore opportunities for linting and/or other validation of tokens, but as a future initiative.

@@ -4,12 +4,12 @@
min-height: 36px;
display: flex;
flex-wrap: nowrap;
font-size: var(--pgn-typography-font-size-small-x);
font-size: var(--pgn-typography-font-size-xs);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The token representing .x-small was refactored slightly to be named pgn-typography-font-size-xs.

Comment on lines +33 to 35
.font-size-normal {
font-size: $font-size-base !important;
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[inform] Adds a new CSS utility class, available to consumers, in place of the custom www-only .fs-16. This way, consumers have a way to override text back to normal/base font-size (e.g., when rendering text in a DataTable row that by default uses .small text).

@@ -738,14 +738,14 @@ $display4-weight: var(--pgn-typography-display-weight-4) !default;
$display-line-height: var(--pgn-typography-display-line-height-base) !default;
$display-mobile-line-height: var(--pgn-typography-display-line-height-mobile) !default;

$lead-font-size: var(--pgn-typography-font-size-lead) !default;
$lead-font-size: var(--pgn-typography-font-size-lg) !default;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[inform] Renamed lead font size token to --pgn-typography-font-size-lg to be consistent with naming of other font size tokens.

@@ -17,7 +17,7 @@
"weight-link": { "source": "$alert-link-font-weight", "$value": "{typography.font.weight.normal}", "$type": "fontWeight" },
"size": { "source": "$alert-font-size", "$value": ".875rem", "$type": "dimension" }
},
"line-height": { "source": "$alert-line-height", "$value": "1.5rem", "$type": "dimension" }
"line-height": { "source": "$alert-line-height", "$value": "1.5rem", "$type": "number" }
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[inform] Fixes line number typography regressions.

@@ -27,7 +27,3 @@ body {
.container-fluid {
max-width: none;
}

.fs-16 {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[inform] removed in favor of new .font-size-normal CSS utility class.

@import url("https://cdn.jsdelivr.net/npm/@edx/[email protected]/dist/core.min.css");
@import url("https://cdn.jsdelivr.net/npm/@edx/[email protected]/dist/light.min.css");
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[inform] At the moment, 2U has no intentions to migrate the existing @edx/brand-edx.org. Instead, MFEs will cutover directly to our new tokens-compatible theme @edx/elm-theme upon upgrade to a Paragon version that relies on tokens.

@adamstankiewicz adamstankiewicz force-pushed the ags/tokens-updates branch 7 times, most recently from 95b9de0 to ec15f2a Compare September 3, 2024 13:48
Comment on lines +122 to +121
filter: hasSourceTokensOnly
? `isSource.${themeVariant}`
: `isThemeVariant.${themeVariant}`,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[inform] Currently, the registered format css/custom-variables performs filtering within its own logic (i.e., filtering on dictionary.allTokens), rather than treating the filter as a legit style-dictionary filter here. New filters are now registered to filter tokens by the appropriate themeVariant file path within the filter property here versus within the definition of css/custom-variables.

Note that other custom filters (e.g., isSource) can automatically opt into having sub-filters created specific to individual theme variants (e.g., isSource.light).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just trying to wrap my head around this change a little bit. Before this change if hasSourceTokensOnly was false we'd have filter as undefined - does that mean it used to apply to all variants?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously, hasSourceTokensOnly: false would rely on filtering implemented within the format function, instead of as a true style-dictionary filter implemented with .registerFilter. That is, formatters should assume any token filtering happens before the format is applied, which already limits the contents of dictionary.allTokens we previously filtered on explicitly.

There's some more detailed rationale about this change provided on my review of Peter's PR here, notably:

IMHO, having unfilteredTokens in the dictionary here suggests a possible code smell that we might want to be doing such filtering as a legit custom filter registered with style-dictionary (similar to how we seem to define an isSource filter today via registerFilter).

See the current implementation of createCustomCSSVariables (source).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the added context! 100% agree that it's better to have

a true style-dictionary filter implemented with .registerFilter

than

filtering implemented within the format function

@PKulkoRaccoonGang PKulkoRaccoonGang deleted the ags/tokens-updates branch September 3, 2024 14:33
@PKulkoRaccoonGang PKulkoRaccoonGang restored the ags/tokens-updates branch September 3, 2024 14:36
Copy link
Contributor

@brian-smith-tcril brian-smith-tcril left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great! I left quite a few comments but they're mostly just questions. Thank you so much for all of this!

Comment on lines +88 to +92
{
name: '--output-references',
description: 'Include references in the build output.',
defaultValue: true,
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

100% agree. Good call/addition!

Comment on lines 69 to 73
formatting: {
fileHeaderTimestamp: true,
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call! The default header looks like it covers everything we need, and I'm all for reducing complexity (even in small ways like this!)

/**
 * Do not edit directly, this file was auto-generated.
 * Generated on Tue, 03 Sep 2024 13:46:26 GMT
 */

Comment on lines +122 to +121
filter: hasSourceTokensOnly
? `isSource.${themeVariant}`
: `isThemeVariant.${themeVariant}`,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just trying to wrap my head around this change a little bit. Before this change if hasSourceTokensOnly was false we'd have filter as undefined - does that mean it used to apply to all variants?

Comment on lines 127 to 129
formatting: {
fileHeaderTimestamp: true,
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see this block now exists in a couple spots in this file. It's only 3 lines so I'm not worried about the copypasta, but I am curious as to if there's a "built-in" way to have a "global" formatting setting. If there isn't a "built-in" way I'm thinking it might be cool to move this out to a const like we have with defaultParams so if anyone wants to change the formatting they can do it in one place.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adamstankiewicz I think this is the last lingering question I have before giving this a ✔️!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plan to investigate later this afternoon. I do recall seeing somewhere in the style-dictionary docs about global settings, so it might be possible. If the global approach isn't possible, I agree abstracting out a defaultParams or similar would be worthwhile to be more DRY. I'll share an update later :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just pushed up a commit to re-introduce a custom file header, and apply it globally across all files in the css platform.

/**
 * Do not edit directly, this file was auto-generated. while transforming design tokens.
 * See <root>/tokens/README.md for more details.
 */

package.json Show resolved Hide resolved
Comment on lines 3 to 22
@mixin mobile-type {
.display-1,
.display-2,
.display-3,
.display-1 {
font-size: $display1-mobile-size;
line-height: $display-mobile-line-height;
}

.display-2 {
font-size: $display2-mobile-size;
line-height: $display-mobile-line-height;
}

.display-3 {
font-size: $display3-mobile-size;
line-height: $display-mobile-line-height;
}

.display-4 {
font-size: $display-mobile-size;
font-size: $display4-mobile-size;
line-height: $display-mobile-line-height;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at this it seems we used to use the same size and line height for .display-1 through .display-4, and this updates it so we have different sizes but not different line heights? Just curious as to the reasoning behind that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great question! So, the new 2U Paragon Elm Theme has distinct sizes for mobile .display-1 through .display-4, but Paragon alpha doesn't currently actually have the tokens/CSS support for level-specific mobile display font sizes. As such, this PR introduces tokens for distinct levels of display size for mobile.

Regarding why there's not currently level-specific mobile line heights is that the Elm Theme continues to rely on a single line height across all mobile display levels (i.e., line-height: 1), which also happens to be the non-mobile default line height as well.

Paragon base theme defines display-mobile-line-height: 3.5rem, and Elm Theme overrides this to be display-mobile-line-height: 1.

There is also only a single line height value configured for all non-mobile display levels, too.

Note that using line-height: 1 (i.e., without a unit like rem) defines the line height to be equal to the font-size which is distinct per level. Given this, line-height: 1 is technically still results in distinct computed line heights per mobile display level.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds very reasonable! I do wonder if supporting different custom line heights for each is something we want to do. I'd lean towards thinking we should, but I could definitely be convinced otherwise.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, supporting that as a use case is how I'm leaning, FWIW. Though, maybe we roll with it as is for this PR and @PKulkoRaccoonGang's related PR(s) to do the style-dictionary upgrade to v4, and treat level-specific display line heights as a standalone fast follow to these PRs before master -> alpha, given it's not necessarily related to the v4 upgrade itself per se and would probably be a reasonably scoped individual contribution.

@@ -21,13 +21,17 @@
$color-levels: 100, 200, 300, 400, 500, 600, 700, 800, 900;

.x-small {
font-size: $x-small-font-size;
font-size: $x-small-font-size !important;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm always slightly wary of !important, could you explain why it's needed here? (Depending on the reasoning it might be nice to add that as a comment in the file itself)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CSS utility class definitions generally should always have !important. See list of other existing utility classes on the Paragon docs site to observe their inclusion of !important.

See example(s) of CSS utility class definitions from Bootstrap v4 (source) as a reference, too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes, I was getting towards the end of the diff and missed the filename.

It looks like almost everything else in the file has !important (only .icon-spin doesn't) - is the lack of !important in .icon-spin intentional?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, in additional icon-spin, the font-weight: normal property on .micro doesn't include !important either, though I don't it should for font-weight (you could want micro-sized copy with font-weight-bold, etc.). IMHO, .micro shouldn't be defining font-weight at all.

Regarding .icon-spin specifically, it appears to only be used with the StatefulButton component across all of the openedx GitHub organization. I actually wonder whether we truly want to consider this a global utility class or not, given its specific to icons.

For example, alternatively, should the Icon component expose a spin prop that extends the rendered icon to add the icon-spin class conditionally?

E.g., proposed usage from StatefulButton:

icons: {
  pending: <Icon src={SpinnerSimple} spin />,
},

I'm struggling to identify use cases for .icon-spin outside of the Icon component. With icon-spin as a global CS utility class, I could also see it getting abused to make things spin/animate on the page that shouldn't (e.g., non-icons).

My 2c recommendation:

  • Remove .icon-spin as a CSS utility class, implementing it instead of a class name specific to Icon component.
  • Expose optional spin prop on Icon component.
  • Update StatefulButton to pass spin prop on its pending icon.

Copy link
Contributor

@brian-smith-tcril brian-smith-tcril Sep 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My 2c recommendation:

  • Remove .icon-spin as a CSS utility class, implementing it instead of a class name specific to Icon component.
  • Expose optional spin prop on Icon component.
  • Update StatefulButton to pass spin prop on its pending icon.

This absolutely sounds like the right move to me!

IMHO, .micro shouldn't be defining font-weight at all.

Do we have a sense of what might break if it didn't?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That being said, I don't think either of those should be part of this PR. Just making a couple follow-up issues to address them seems like the right move to me.

Copy link
Member Author

@adamstankiewicz adamstankiewicz Sep 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO, .micro shouldn't be defining font-weight at all.

Do we have a sense of what might break if it didn't?

It shouldn't break anything. The font-weight in .micro is font-weight: normal, which corresponds to font-weight 400, the default body font weight used elsewhere.

That being said, I don't think either of those should be part of this PR. Just making a couple follow-up issues to address them seems like the right move to me.

100% 😄

@PKulkoRaccoonGang PKulkoRaccoonGang mentioned this pull request Sep 3, 2024
10 tasks
Copy link
Contributor

@brian-smith-tcril brian-smith-tcril left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

Copy link
Contributor

@PKulkoRaccoonGang PKulkoRaccoonGang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is pretty cool! LGTM!

…, and updates CSS vars format

**CLI Enhancements**

* 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.

**Token Management Improvements**

* 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.

**Documentation Site Enhancements**

* 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.
@adamstankiewicz adamstankiewicz merged commit 63a61de into Peter_Kulko/style-dictionary-v4 Sep 3, 2024
6 checks passed
@adamstankiewicz adamstankiewicz deleted the ags/tokens-updates branch September 3, 2024 20:37
PKulkoRaccoonGang pushed a commit that referenced this pull request Sep 3, 2024
…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.
@adamstankiewicz adamstankiewicz restored the ags/tokens-updates branch September 7, 2024 21:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants