We made our Design System open source

After two years of talk, meetings, and debates, we’ve finally open-sourced our design system. You can explore the repository here:

https://github.com/Spendesk/grapes

The technical side was straightforward, but aligning everyone, especially our security and legal teams, was the most complexe part.

Remove dependencies

Even before talking with every department, we knew our Design System repository had to run independently of Spendesk’s shared libraries.

It’s fairly common that company have a shared ESLint configuration across multiple projects and repositories. This is the case at Spendesk and Grapes, our design system, used to relied on a private, internal ESlint configuration.

To open-source Grapes, we first had to migrate away from the private configuration and adopt a public ESLint config.

Here are the changes we applied to our ESLint configuration. Note that these updates were made when we were still using ESLint v8.

{
  "extends": [
    "@dev-spendesk", 
    "@dev-spendesk/eslint-config/front"
    "eslint:recommended", 
    "plugin:react/recommended", 
    "plugin:react-hooks/recommended", 
    "plugin:@typescript-eslint/recommended", 
    "plugin:jsx-a11y/recommended"
  ]
}

Security audit

If you have a security team in your company, making a private project public will involve a security audit. Fortunately for us, we got the green light right away.

Clone the repository

Once we had the green light, we got to work. We kicked things off by cloning the repo without its GitHub history, reviewing 3,000+ pull requests for secrets would’ve been too time-consuming. This gave us a fresh, clean slate for our design system.

We then archived the original repository, just in case we needed to reference it. After all, some legacy projects still rely on version 0.x of our design system.

Semantic-release tweak

Our design system repository is using semantic-release to automate the release process. Since we didn’t have the history on the new repository, we had to tell semantic-release the next release version, otherwise, it would default to v1.0.0.

To do this, we manually tagged the initial commit with the previous created release.

git tag v1.43.0 7332b2bb8859cc8d4fea77d88e0ec31af3e876b9
git push origin tag v1.43.0

With this tag in place, any new fix or feature commit will make semantic-release bump the version appropriately, either to v1.43.1 for a fix or v1.44.0 for a new feature.

Below is a preview of the log when semantic-release generated a new version:

[semantic-release] › ℹ Found git tag v1.43.0 associated with version 1.43.0 on branch master
[...]
[semantic-release] › ✔ Completed step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[semantic-release] › ℹ The next release version is 1.44.0

Conclusion

Opening our design system took much longer than expected. Several factors played a part: Spendesk’s leadership team wasn’t initially convinced of its value, legal and security needed to be involved, higher-priority projects had our focus, and after the Spendesk rebranding, we wanted time to clean up the codebase.

But it’s finally done, ready for you to clone, fork, and contribute.