Storing tokens on GitLab makes a lot of sense. It's version controlled, allows you to work in different branches (think of a brand refresh that lives on a different branch than the current live version) and gives you varying access levels such as Read or Write access. Also you can integrate GitLab CI/CD which will allow you to create a token pipeline with Style Dictionary or other tools.
Already have a GitLab account with a repository? Great, skip to step 3
1. Create a GitLab account
Go to https://gitlab.com/users/sign_up and create an account.
2. Create a new repository
Go to https://gitlab.com/projects/new and create a new repository. Give it any name you like, make it public or private and initialize it with a README.
3. Generate your Personal Access Token
Go to the Personal Access Tokens section by clicking here, or click on your Avatar in the top right, go to
Access Tokens and generate a new token and select scope
api, decide for yourself when that token should expire. Scroll down and click
Create personal access token.
Important: We currently only support Personal Access Tokens, not Project Access Tokens.
Copy that token, you'll need it in a second and won't see it again if you close the page.
Also, never share this token with anyone who shouldn't have access to your repository. The token I shared in the video above was deleted already, treat it like your personal password.
4. Add a new GitLab sync to your Tokens file.
Go to the Sync tab and select GitLab. Add a new item
- Add any name (this is only used for the plugin UI)
- Add your Personal Access Token which we just copied.
- Add your GitLab repository (e.g.
- Add your default branch (probably
- Specify a file path where your tokens should be stored, e.g.
5. Push your initial set of tokens
The plugin will now ask you to push your currently stored tokens to the repository.
Add a commit message, e.g. "Initial commit"
If you're adding a repository that already contains tokens, the plugin will ask you if you want to pull the latest tokens. This will overwrite your locally stored tokens, so make sure to back these up if you don't want them to get removed.
6. Push or pull changes
Whenever you make a change in Tokens Studio for Figma, you have to manually hit
Push to GitLab to push your local changes to the remote. Anytime you do that you have to supply a commit message. You can choose the branch you want to push your changes to, so you could just try new tokens out without overwriting the currently live ones.
If you only want to pull the latest changes, hit
Pull from GitLab. The plugin will let you know when your local changes differ from the ones stored on the remote by showing a blue dot.
7. How to use tokens stored in GitLab in development?
If you now want to use your tokens also in development there's a few steps you need to follow.
The tokens we store on GitLab is the raw source of truth for the plugin. Meaning, it still contains aliases and any math you might have used. Tools such as Style Dictionary can't work with math by default.
To help you get started, we have created a custom Style Dictionary configuration that handles things such as math. You will have to change the configuration to use your tokens based on your token structure. You can find the configuration file in this gist.
Alternatively, you can use this package that transforms the tokens into a format that Style Dictionary can work with: Token Transformer. You or your dev can install that by running
npm install token-transformer.
You can then use it to generate tokens to a JSON that is readable by Style Dictionary, without any aliases, without any math.
node token-transformer tokens.json output.json where tokens.json is the file you stored your tokens in. This will take your input JSON file (which is the file we generate from Tokens Studio for Figma, this should match what you entered in the Sync details) and output the transformed tokens to an output.json
If you use multiple token sets you might also want to create different token files per theme combination. You can do that by giving token-transformer additional parameters:
node token-transformer data/tokens.json output.json global,dark will use the global and dark token sets to generate combinations.
Don't want to include the global set in the output but use it for resolving aliases? Provide another parameter like this and the transformer will exclude that in the output:
node token-transformer tokens.json output.json global,dark global