@equinor/eds-tokens

@equinor/eds-tokens

Design tokens used in the Equinor Design System (EDS), such as colours, spacings and typography.

Installation

pnpm add @equinor/eds-tokens

Usage

import { tokens } from '@equinor/eds-tokens'

CSS custom properties are also available:

@import '@equinor/eds-tokens/css/variables-static.css'; /* or variables-dynamic.css */

variables-static.css exposes tokens with fixed values, while variables-dynamic.css includes dynamic semantic color tokens.

Tokens

• Clickbounds
• Colors
• Elevation
• Shape
• Spacing
• Interaction states
• Typography (ot, woff or woff2 font required)

Sync variables in Figma to tokens in code

This repository contains a couple of GitHub Actions workflows:

• Sync tokens to Figma
• Sync Figma variables to tokens

These workflows demonstrate bi-directional syncing between variables in Figma and design tokens in a codebase using Figma's Variables REST API. For more background and a graphical representation of what these workflows do, see our Syncing design systems using Variables REST API FigJam file.

To use these workflows, you should copy the code in this repository into your organization and modify it to suit the needs of your design processes.

Prerequisites

To use the "Sync Figma variables to tokens" workflow, you must be a full member of an Enterprise org in Figma. To use the "Sync tokens to Figma" workflow, you must also have an editor seat.

Both workflows assume that you have a single Figma file with local variable collections, along with one or more tokens json files in the tokens/ directory that adhere* to the draft W3C spec for Design Tokens. For demonstration purposes, this directory contains the tokens exported from the Get started with variables Community file. Have a copy of this file ready if you want to try out the workflow with these existing tokens.

*See src/token_types.ts for more details on the format of the expected tokens json files, including the deviations from the draft design tokens spec we've had to make. We expect there to be one tokens file per variable collection and mode.

In addition, you must also have a personal access token for the Figma API to allow these workflows to authenticate with the API. For the "Sync Figma variables to tokens" workflow, the token must have at least the Read-only Variables scope selected. For the "Sync tokens to Figma" workflow, the token must have the Read and write Variables scope selected.

Usage

Before running either of these workflows, you'll need to create an encrypted secret in your repository named GH_ACTION_VARIABLES_SYNC_FIGMA_TOKEN containing your personal access token.

Both workflows are configured to run manually for demonstration purposes, and are designed to be as conservative as possible in their functionality (see details below).

Sync Figma variables to tokens

To run the "Sync Figma variables to tokens" workflow:

• Open the workflow under the Actions tab in your repository and click Run workflow
• You will be asked to provide the file key of the Figma file. The file key can be obtained from any Figma file URL: https://www.figma.com/file/{file_key}/{title}.
• After the workflow finishes, you should see a new pull request if there are changes to be made to the tokens files in the tokens/ directory. If there are no changes to be made, then a pull request will not be created.

This workflow has some key behaviors to note:

• After generating the new tokens json files, this workflow creates a pull request for someone on the team to review. If you prefer, you can modify the workflow to commit directly to a designated branch without creating a pull request.
• If a variable collection or mode is removed from the Figma file, the corresponding tokens file will not be removed from the codebase.

Sync tokens to Figma

To run the "Sync tokens to Figma" workflow:

• Open the workflow under the Actions tab in your repository and click Run workflow
• You will be asked to provide the file key of the Figma file. The file key can be obtained from any Figma file URL: https://www.figma.com/file/{file_key}/{title}. Note: if you are trying out this workflow for the first time, use a file that is separate from your design system to avoid any unintended changes.
• After the workflow finishes, open the file in Figma and observe that the variables should be updated to reflect the tokens in your tokens files.

This workflow has some key behaviors to note:

• Though this workflow is configured to run manually, you're free to modify it to run on code push to a specified branch once you are comfortable with its behavior.
• When syncing to a Figma file that does not have any variable collections, this workflow will add brand-new collections and variables. When syncing to a Figma file that has existing variable collections, this workflow will modify collections and variables in-place using name matching. That is, it will look for existing collections and variables by name, modify their properties and values if names match, and create new variables if names do not match.
• The workflow will not remove variables or variable collections that have been removed in your tokens files.
• When mapping aliases to existing local variables, we assume that variable names are unique across all collections in the Figma file. Figma allows duplicate variable names across collections, so you should make sure that aliases don't have naming conflicts in your file.
• For optional Figma variable properties like scopes and code syntax, the workflow will not modify these properties in Figma if the tokens json files do not contain those properties.
• If a string variable is bound to a text node content in the same file, and the text node uses a shared font in the organization, that variable cannot be updated and will result in a 400 response.

Local development

You can run the GitHub actions locally by running pnpm install and creating a .env file.

Example:

PERSONAL_ACCESS_TOKEN="your_personal_access_token"

How to create your personal access token

and then running:

# Defaults to writing to the tokens directory
pnpm run update-tokens

# and / or

pnpm run update-figma

Figma Variables

• The semantic variable is the variable applied to a layer in Figma.
• A semantic variable can have different modes defined, and the designer can select these

How the variables are setup with references between collections

The semantic variable references the first segment (collection) in the variable. For example, the first segment is “appearance” for the action variables. Variables defined in appearance point to the next segment, which for action variables would be prominence. In the prominence collection, we define a variable for each of the appearance modes so that these are represented in the context of each prominence mode. The variables in the “prominence” collection point to variables in the state collection, and again, we represent all the prominence modes as new variables in the state collection. For action variables, the journey ends here, and the variables in the state collection point to the light/dark color scheme variables in the color scheme collection.

Tokens in code

The color scheme collection variables support all the combinations of modes in the different collections and are used to generate tokens in code. All the combinations of modes in different collections must be provided here so that the code syntax matches tokens in the code.

How to setup variable collections in Figma

To set up tokens in Figma, start with the base value defined in the Colour Scheme collection. Once these are defined, you have all the different combinations of a variable and are ready to set up the collections you want to provide. Using the action variables as an example, you would first create the base values and then start with the variable’s last segment(collection). This is the taxonomy of our action variables: color/action/[appearance]/[prominence]/[state]. The last segment in this example would be the “state” collection. The state collection references the base values you defined in the Colour Scheme collection. In the state collection, you should define a variable for each mode in the previous segment; in this example, that would be all the modes you want to define in the prominence collection. Example: primary, secondary, tertiary. When this is ready, you continue to the segment before the prominence collection; in this example, this would be the appearance collection. The appearance collection is, in this example, the first segment and, therefore, the last collection you need to create. In this collection, you create all the variables you need. In our token taxonomy, we create a variable for different properties (text, icon, border, surface). These variables should reference the variables you created in the previous collection; in this example, that would be the specific appearance variables you created in the prominence collection.