Figma tokens automatically turned into code: how we kickstarted our design system

Part 3: From Figma to our codebase

tldr; You can find the example code on this repository: https://github.com/nicodeclercq/extractFigmaTokensExample

• Part 1: Down the rabbit hole
• Part 2: Using the Figma API
• Part 3: From Figma to our codebase (you are here)
• Part 4: Profits!

Using the API is not the most valuable part. We’ve extracted colors but how do we use them in our numerous projects? We need to export extracted tokens in a way that can be used across all our projects and libraries.

Mapping: from Figma API output to production-ready code

At iAdvize we mostly write our styles using CSS modules and SASS as a preprocessor. Our variables are distributed as “.scss” files we can easily import. We also sometimes need to manipulate our colors via TypeScript and we need an exported “.ts” file as well.

Here’s how we take the output from the Figma API endpoint and turn it into a single stylesheet.

We need to format our Figma names and colors to fit our languages’ needs:

Then comes the templating for each export file types:

We have all we need now to do the last part of the mapping:

Here we just created a string value for our TypeScript color styles but you could also generate a Color class object which could have multiple color formatters such as Hex, HSLA, RGBA, HSBA and so on, or arrange the colors by categories in a tree structure. We could also have written Storybook files in order to showcase our generated values, or even a changelog of our extracted colors etc… That part is now up to you! For now let’s dive into the next part of our journey and make all this automatic generation even more impactful.

Versioning changes and packaging our tokens

As we’ve seen, part of our efforts to automatically use Figma values into our codebase came from our design team changing the value of a color on their end. Now we do have tokens reflecting theirs, but what if they change in Figma? Designers would still have to ask us to manually run the script!

How tedious. To avoid that and to give them as much power as we could, we leveraged our CI to automatically check for updates on Figma and build a new version of our package every time it’s needed.

Of course a new version of the tokens could break the currently implemented one, so we capitalized on this automation step to versionize the output and guarantee our applications’ safety.

Our versioning relies on a comparison system. For it to work, we need to generate a file documenting the current colors state. For each CI run we’ll then be able to compare the changes and this “state” file. The differences will then be translated as versions.

Now we can “write” our state, but we also need to be able to read it:

Now lets rework the global flow:

We are now able to find out which color has been added, updated or deleted. With this we’ll be able to manage version types!

First run outputs:

Second run outputs:

If we modify the json file and rerun, our output is:

(We could have also modified the tokens directly in figma, the result would have been the same)

Everything works just fine!

From this we could generate a changelog file, but we will keep the focus on the version management and leave the rest to you.

How do we know the type of change we just made? The response is simple:

• We have no addition, no update and no deletion: no new version needed
• We have a deletion: this is a breaking change => MAJOR
• We have only updates or additions: no breaking => MINOR

We can now create a VERSION_BUMP_TYPE file with the type of change we just made.

This file will then be used in our CI script. This script is pretty generic. We use CircleCI to execute it and provide the credential it needs but its concepts will apply regardless of your CI of choice. What matters is its role: packaging our tokens in a versionized way.

Let’s dig in:

You can now execute this script in your own CI tool at regular intervals (we do it every 2 hours of working days).