nl-design-system/themes

Design Tokens and NL Design System themes for organisations that don't have their own Storybook.

themes's Issues

Migreren van token-transformer naar@tokens-studio/sd-transforms

@tokens-studio/sd-transforms is de nieuwe versie van hetzelfde pakketje.

Documentatie: Tokens Studio for Figma: Transforming design tokens using Style Dictionary

Design tokens addon

• code van Utrecht lostrekken: https://github.com/nl-design-system/utrecht/tree/main/documentation/components
• design tokens components publiceren in theme-toolkit package: themes/packages/theme-toolkit

Utility voor design-token documentatie in storybook

In Utrecht storybook staat een handige functie om de design tokens van een component te tonen.

Bij andere design systems zou dat ook handig zijn zoals bijvoorbeeld in Den Haag Storybook voor MijnZaken componenten

Rotterdam color search is broken

Depends on nl-design-system/rotterdam#174

After migrating the rotterdam design tokens to their own repo, the code search is broken. It has to do with the JSON format that is not as expected.

Theme toolkit package publiceren

Deze package is nu private, zou public moeten zijn zodat Amsterdam/Rotterdam/Den Haag/Rijkshuisstijl Community er ook profijt van hebben.

https://github.com/nl-design-system/themes/blob/main/packages/theme-toolkit/package.json

Generated component pagina's weghalen

Als experiment is er code geschreven om een component story te genereren met een uitgebreide argstable. Deze werkt min-of-meer maar heeft behoorlijk wat extra liefde nodig. Als POC is hij geslaagd omdat het dus kan, maar we kunnen dit jaar opnieuw beginnen.

Omdat hij de Storybook 7 migratie ingewikkeld maakt daarom deze story om de logica uit de themes repo te halen voor de migratie en op een later moment met een nieuwe feature toe te voegen.

CODEOWNERS aanpassen zodat Dependabot niet iedereen mailt

De package.json files moeten excluded zijn voor CODEOWNERS, bijvoorbeeld door !proprietary/groningen-design-tokens/package.json of door de CODEOWNER aan te passen naar het mapje src/. Bijvoorbeeld:

/proprietary/groningen-design-tokens/src/ @nl-design-system/gemeente-groningen

Dat zal een hoop review requests schelen!

Thema voor Rotterdam maken

Amsterdam Design System tokens

Storybook 8 migratie themes repo

Afhankelijk van #516 en #517

• MDX stories naar TSX
• Webpack naar Vite
• ...

Stylelint configuration provided as NPM package

For the The Hague Component Library we're using a stylelint configuration inspired by the NLDS template stylelint.

It would be beneficial for repositories that could potentially contribute to NLDS, if a standard NLDS stylelint configuration was available to extend. This can help staying up to date with changes to the configuration by the NLDS team and make it easier to share code if the linting is identical.

I'm not sure if it's quite as useful for prettier or eslint.

Playroom weghalen

Playroom was een experiment dat gebruikt is om magneten mee te maken voor de eerste NL Design System on the road.

Een goede integratie heeft meer werk nodig, ook omdat we dubbelingen zouden kunnen hebben tussen componenten uit diverse repositories met dezelfde naam.

Playroom zit nu een makkelijkere migratie naar Storybook 7 in de weg, dus door hem voor nu weg te halen en later opnieuw te integreren is het opgelost.

Automatic test on voorbeeld theme

Description

Context

The voorbeeld theme contains a lot of utrecht- and some denhaag- tokens. In the future it might contain tokens from other organisations as well.

Problem

It turns out that some of the utrecht- tokens in the theme, don't actually exist in the code of the relevant Utrecht component. For example, the voorbeeld theme has utrecht-alert-informative-... whereas the actual Utrecht Alert has utrecht-alert-info-....

Why is this a problem?

UX designers might copy the voorbeeld figma library, and use it to design their components and define their organisations theme. When a developer actually tries applying that theme to an application using the components, the tokens won't do anything, because the code doesn't actually use them.

Solutions

Since the voorbeeld theme is manually updated in Figma, we can't change too much there. However, when the voorbeeld theme is pushed to a github branch to be updated, we could use the CI to verify that the tokens that are exported actually exist.

How?

• voorbeeld.tokens.json is read in a test
• Go through all non todo- tokens -> verify that the token exists in the organisations tokens
• example: utrecht-alert-informative-color -> does it exist in the utrecht tokens?
• Fail a test and output a list of non-existing tokens to make it easy to correct in Figma

Not certain:

• Which files can we base the check on? Some organisations might not have ever token in their own theme, even though the code does support it. Is there an all-inclusive "tokens.json" for every organisation?

Acceptance criteria

• voorbeeld.tokens.json is automatically checked to make sure it does not contain non-existing organisation tokens.
• Failed test if non-existing tokens are present
• List of non-existing tokens is visible