✨ [#1910] Add first NL-DesignSystem components

[jiromaykin]

• add our designtokens-package submodule
• add Utrecht CSS NPM package + Utrecht Components NPM package
• add actions for submodules to CI yml's
• add Utrecht classes in some heading templates
• let Utrecht design variable Keys point to OIP variable Values

issue: https://taiga.maykinmedia.nl/project/open-inwoner/task/1910

[jiromaykin]

Note to self: De design-tokens git-submodule genereert lokaal CSS die nu niet gevonden wordt; ci kan het bestand niet vinden omdat de git submodule niet automatisch geïnstalleerd wordt.
Extra ToDo om uit te zoeken: ervoor zorgen dat @import 'design-tokens/open-inwoner-design-tokens/dist/css/index.css'; werkt door het package te symlinken, vanuit de root te NPM installeren, en er een lokale NPM module van te maken die vanuit de node-modules makkelijk door alle SCSS geimporteerd kan worden (zonder naar NPM te publiceren) en deze dan later toe te voegen bij .github/workflows/ci.yml

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (0574504) 94.66% compared to head (1d2dee6) 94.66%.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop     #909   +/-   ##
========================================
  Coverage    94.66%   94.66%           
========================================
  Files          830      830           
  Lines        29236    29236           
========================================
  Hits         27676    27676           
  Misses        1560     1560           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jiromaykin]

Before reviewing, please read why we are using 'utrecht' here:
https://taiga.maykinmedia.nl/project/open-inwoner/wiki/design-tokens-nl-design-system
Also this explains how in future we can add new properties and other CSS properly in the design-tokens.
In future we may even use classes with the name 'denhaag' in it, so don't be alarmed.

[pi-sigma]

Looking good! You should update the installation instruction for Open Inwoner itself (INSTALL.rst under "Get the code") to make sure the submodules are also cloned. Otherwise the folder for the design tokens is there but empty. There are two ways:

git clone --recursive [email protected]:maykinmedia/open-inwoner.git
cd open-inwoner

git clone [email protected]:maykinmedia/open-inwoner.git
cd open-inwoner

# initialize submodules
git submodule update --init --recursive

These are equivalent, the difference is a matter of style. I kind of prefer the second, as it's more explicit (it's not like you have to type this again and again). Perhaps include a comment below to explain what those submodules are.

While you're at it, you could remove the $ signs from the code blocks in INSTALL.rst so that people can actually copy/paste the code snippets.

[stevenbal]

I'm not sure how often this repo will be updated, but I think it would be a good idea to pin this to a specific tag. Otherwise every pipeline of Open Inwoner will always pull in the master branch of the package's repo.

We could probably do something like this: https://stackoverflow.com/a/21699307 (also makes us skip any history, since we're not going to use that in the image anyway)

[jiromaykin]

I've just created a Tag (v0.0.1) but I wonder: if this will actually still be updated a lot, isn't it better to keep on pulling the Main branch - in these beginning stages? Every commit means a new Tag since they are big changes every time (I think).
In a far(?) future that repo could become the single source of truth (when they will also be used by the designers).

[jiromaykin]

I already had to update it to version 0.0.2... :-D

[stevenbal]

We could let it point to the main branch if it will be modified a lot, though I am generally wary of not pinning these kinds of dependencies, because I like to know what versions of dependencies I have for a specific image and not have potential unwanted changes be included automatically. If @alextreme approves to use master then it's fine by me.

You could add --depth 1 to git clone to avoid pulling in the history (https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---depthltdepthgt)

[jiromaykin]

I already turned it into this "RUN git clone --depth 1 --branch 0.0.2 https://github.com/maykinmedia/open-inwoner-design-tokens.git" with the tag, but how will we remember the Tag needs to be updated too? Add to both repo's documentations?

[alextreme]

It's indeed quite a chore to keep these kinds of relations in-sync between repositories, this is why for maykin-deployment I also avoid pinning to a specific branch (and why I'd prefer to go for a single combined repo, this would avoid the problem altogether).

For now I approve and prefer pulling from main/master instead of a release-branch. I'll set a reminder to re-evaluate this in half a year, if changes have become incidental then we'll pin this again to a release-branch

[jiromaykin]

@stevenbal @alextreme So should I remove the clone-from-Tag thing and revert to what it was?

[alextreme]

yes

[stevenbal]

Looks good overall, just some remarks regarding docker setup/submodules