chore: add plugin for intellisense of css variables (#1748)

.gitignore

@@ -32,7 +32,6 @@ npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
 
-/.vscode
 *.css.map
 !DesignTokens.css
 !Utilities.css

.vscode/extensions.json

@@ -0,0 +1,3 @@
+{
+  "recommendations": ["dbaeumer.vscode-eslint", "phoenisx.cssvar"]
+}

.vscode/settings.json

@@ -6,6 +6,7 @@
     "typescriptreact"
   ],
   "css.validate": false,
+  "cssvar.files": ["src/tokens-dist/css/variables.css"],
   "scss.validate": false,
   "stylelint.enable": true,
   "typescript.validate.enable": true,

docs/CONTRIBUTING.md

@@ -8,6 +8,8 @@
 npx husky install
 ```
 
+- Install the [CSS Var Complete - VS Code Plugin](https://marketplace.visualstudio.com/items?itemName=phoenisx.cssvar) which provides better Intellisense while writing CSS and referencing CSS variables.
+
 ## Git Flow
 
 This project uses [Git-flow](https://nvie.com/posts/a-successful-git-branching-model/) to manage the development workflow. Here's a breakdown of what this means for the design system:
@@ -42,15 +44,14 @@ A few notes about breaking changes:
 - Consider writing a codemod (using [JSCodeShift](https://github.com/facebook/jscodeshift) for systematic changes.
 - There may be a way to make the change in a backwards-compatible way. Consider this during implementation, providing some rationale in cases where it is not feasible/practical to do so.
 
-
 ## Making Edits to Tokens
 
 ### Adding new tokens
 
 When we need to introduce new tokens to account for customizations or features in new or existing components, for each new token, we use the following process:
 
 1. Determine the tier of the new token with design
-2. Work with design to make sure the token is added to figma with the proper naming format 
+2. Work with design to make sure the token is added to figma with the proper naming format
 
 For example, tokens in figma have a name in the format 'Category/token-name', so we'd want the resulting token in code to resolve to `--eds-theme-color-category-token-name`.
 
@@ -71,10 +72,10 @@ For example, if we had a token `--eds-theme-color-background-old-name` which we
 "comment": "@deprecated This token is deprecated. Please use eds-theme-color-new-name instead."
 ```
 
-This has the folling benefits:
+This has the following benefits:
 
 - Users who have added a theme value to `--eds-theme-color-background-old-name` will not have their theme value break upon update.
 - Users can see which tokens are deprecated via the autogenerated comment in the token files.
 - Users can adopt the new token when convenient, and EDS can publish new versions without introducing multiple breaking changes.
 
-4. Finally, we replace all uses of the old token with the new token.
+4. Finally, we replace all uses of the old token with the new token.