feat: Extract design tokens to JSON

[aaronccasanova]

WHAT is this pull request doing?

This PR extracts the Polaris design tokens, previously implemented in TypeScript, to JSON files.

• Converted TypeScript design tokens to JSON
• Created JSON Schema's for all token groups
• Added ajv-cli to validate JSON token files
• Added a validate-tokens script and integrated in our CI

Follow up tasks

• Update Polaris CustomProperties component to use these JSON tokens
• Update Polaris custom-properties-allowed-list Stylelint plugin to use these JSON tokens

How to 🎩

🖥 Local development instructions
🗒 General tophatting guidelines
📄 Changelog guidelines

Copy-paste this code in playground/Playground.tsx:

import React from 'react';
import {Page} from '../src';

export function Playground() {
  return (
    <Page title="Playground">
      {/* Add the code you want to test in here */}
    </Page>
  );
}

🎩 checklist

• Tested on mobile
• Tested on multiple browsers
• Tested for accessibility
• Updated the component's README.md with documentation changes
• Tophatted documentation changes in the style guide
• For visual design changes, ping @ sarahill to update the Polaris UI kit

[alex-page]

Could this be simpler by breaking the color files into individual JSON files? color.light.json

[aaronccasanova]

Great idea 👍

[aaronccasanova]

This will allow us to remove the color specific json schema 🙌

[aaronccasanova]

Okay this commit:

• Removed the _ prefix from all token files
• Extracted color scheme tokens into individual files (e.g. color.light.json & color.dark.json)
• Simplified the validate-tokens script

[github-actions]

size-limit report

Path	Size
cjs	156.99 KB (0%)
esm	90.01 KB (0%)
esnext	138.52 KB (0%)
css	35.9 KB (0%)

[alex-page]

Love this. One thought, we separated the .ts files by adding the _. Now it's not as needed as the tokens are in .json files. We could just remove the _ now.

[aaronccasanova]

If folks haven't worked with JSON Schema this is validating that our tokens are objects with a depth of 1 whose values are strings. Here is an example of the error thrown if we violate this constraint:

[BPScott]

I'd love to see a demo of how these files can get included by the source code

[aaronccasanova]

I'd love to see a demo of how these files can get included by the source code

@BPScott Your in luck! I just submitted a PR to update the CustomProperty component: #4811

[kyledurand]

This looks good but we're back to px values for spacing and shape. Can we follow up to be sure we're converting these to rems?

[alex-page]

This looks good but we're back to px values for spacing and shape. Can we follow up to be sure we're converting these to rems?

If possible I would prefer the values to be pixel based in JSON file and converted to rems in ts. Unsure how complex that would be though. Happy to ship rem values in JSON to speed this up for now.

[kyledurand]

If possible I would prefer the values to be pixel based in JSON file and converted to rems in ts. Unsure how complex that would be though. Happy to ship rem values in JSON to speed this up for now.

Pretty much how our convo went in slack. Namely because rems are pretty hard to read, hard to convert from figma and that could lead to a misunderstanding of the values and increased friction in use / contribution.

I can't see it being too difficult to build but getting it to be performant could get tricky

[aaronccasanova]

@kyledurand @alex-page Here is my first pass: 9856314. Thoughts?

[aaronccasanova]

In an unfortunate git accident this PR was wiped and automatically closed by GitHub. Luckily all the commits we're preserved in the Update CustomProperty component PR# 4811 . There doesn't appear to be a way to restore this PR and thus the contents have been moved to the following PR: #4818