feat: css modules

[eirikbacker]

• Try implementing CSS modules to enable multiple versions of the designsystem on the same page #2277
• Since most bundlers do tree shaking very well these days, maybe we should not have @digdir/designsystemet-react and @digdir/designsystemet-css, (...and @digdir/designsystemet-js and @digdir/designsystemet-svelte etc.), but rather just @digdir/designsystemet (or @digdir/designsystemet-components) as CSS and React/JS/* must be kept in sync anyway?
  This makes it easier for us to maintain, and easier for the consumer, as they get one package but can use different flavours:

import `@digdir/designsystemet/styles.module.css` // To load the hashed styles
import Button from `@digdir/designsystemet/react`

or:

import `@digdir/designsystemet/styles.css` // To load un-hashed styles for those who prefer no versioning

or:

import styles from `@digdir/designsystemet/button.module.css` // To extend or use in HTML/other framework

and:

.my-fancy-button {
  composes: button from '@digdir/designsystemet/button.module.css'; // To extend using pure CSS
  …
}

and:

.my-fancy-react-button { … }
+
<Button className="my-fancy-react-button"> // To extend using React

[changeset-bot]

🦋 Changeset detected

Latest commit: 014641a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@digdir/designsystemet-css	Patch
@digdir/designsystemet-react	Patch
@digdir/designsystemet	Patch
@digdir/designsystemet-theme	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

Preview deployments for this pull request:

📖 Storybook 5. Sep 2024 - 10:38 (Norwegian time)

🖥 Storefront 5. Sep 2024 - 10:39 (Norwegian time)

See all deployments at https://dev.designsystemet.no

[Barsnes]

I am not sure if having one package makes it easier for the consumer.

• If they want to import, they have to activley make sure it comes from the right library in a package
  • for example: I start typiong <Alert>, and then I press ctrl+. for it to give me suggestions. Since there are multiple exports of the same name, I have to stop and look to make sure it comes for the right library
• It will just get bigger and bigger, making downloading the package take longer and longer. Especially relevant for people having to download the package on a remote server every time they deploy

Having one package makes it easier to update, but if we keep all packages in sync, this is not a problem.

[Barsnes]

This is relevant for all components, it's the same as doing

* { box-sizing: border-box } 

So I think this is fine to have in this file 🤔

[eirikbacker]

Not if moving to CSS modules or allowing people to extend our classes like:

.my-fancy-button {
  composes: button from '@digdir/designsystemet/button.module.css'; // To extend using pure CSS
  …
}

Also, this targets only if elements class names starts with ds- so class="ds-button my-button" works, but class="my-button ds-button" does not. I think it is safer and more explicit to just add box-sizing: border-box into the relevant classes in the relevant files :)

[Barsnes]

Ah yeah, but this should be [class~="ds-"] 😄

[Barsnes]

Yeah I think this is a better candididate for moving to to their relevant components.
However, it gives us another point of failure

[eirikbacker]

See comment above regarding targeting start of classnames :)
And I suggest forgetting to add styling should be done in reviews, not by an "invisible" dependency relation :)

[Barsnes]

Agreed

[Barsnes]

We would also need to add a script for this, to fix hashes, prefixes and support extracting pure classes without a hash

[eirikbacker]

We would also need to add a script for this, to fix hashes, prefixes and support extracting pure classes without a hash

Unsure what you mean here - Vite does this? :) and the version without hashes is just making a file style.css:

@import url('style.module.css');

... since style.css does not have .module. in its name, it will not be processed :)
Or maybe I misunderstand the comment? :)

[Barsnes]

We would also need to add a script for this, to fix hashes, prefixes and support extracting pure classes without a hash

Unsure what you mean here - Vite does this? :) and the version without hashes is just making a file style.css:

@import url('style.module.css');

... since style.css does not have .module. in its name, it will not be processed :) Or maybe I misunderstand the comment? :)

I'll elaborate on my thoughs:
Our module files should be processed out as normal css files they can use, without hashes - otherwise we would need two files right? one module and one pure.

I am not sure how vite handles hashing, but at the same time we don't know if our consumers use vite.
Some people might use rollup + postcss, like we did before. We probably don't need to do anything with the hashes ourselves, but we need to tell our users how to use this. If the hash does not change., we have not solves anything. I am also guessing that if anyone decides to use the module files, they should know how to set this up 🤔

Edit: If we want to use features like composes, we would need to process the files for our users right?

[mimarz]

To summaries our meeting on 26.08.24 with @Barsnes @Thuneer @eirikbacker:

We decided to introduce css-modules for the CSS package so that our users can choose to use it if needed, be it for versioning different version or composing with their own CSS.

This also has the benefit internally of giving us typesafety for our classes atleast and composing typography to reduce number classNames to get desired result, while keeping themable typography.

• Added a changset.

[mimarz]

One thing, won't this remove the ability for our React components to be headless (since we have an import statement for css files inside components).

[Barsnes]

One thing, won't this remove the ability for our React components to be headless (since we have an import statement for css files inside components).

This would indeed be correct 🤔

[Barsnes]

One thing, won't this remove the ability for our React components to be headless (since we have an import statement for css files inside components).

This would indeed be correct 🤔

It also makes it hard for users that target our css classes without a buildstep for css modules, since it would change for every version

[eirikbacker]

@mimarz regarding headless; as @Barsnes points out; headless it not possible today either. A solution if we want to provide headless in the future is adding a <UnstyledProvider> an outer wrapper. This is a convention used by for instance Storybook, to provide the ability to opt out of the base classes being set.

@Barsnes Targeting our classnames would always be a bad idea, as we can change the classnames regardless. We should encourage people using the React package to always add their own className to extend styling ☺️

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	65.3%	4909 / 7517
🔵	Statements	65.3%	4909 / 7517
🔵	Functions	83.22%	129 / 155
🔵	Branches	75.68%	610 / 806

File Coverage

File	Stmts	% Branch	% Funcs	% Lines	Uncovered Lines
Changed Files
packages/react/src/components/Box/Box.tsx	100%	100%	100%	100%
packages/react/src/components/Breadcrumbs/BreadcrumbsItem.tsx	100%	100%	100%	100%
packages/react/src/components/Breadcrumbs/BreadcrumbsLink.tsx	100%	100%	100%	100%
packages/react/src/components/Breadcrumbs/BreadcrumbsList.tsx	100%	75%	100%	100%
packages/react/src/components/Breadcrumbs/BreadcrumbsNav.tsx	100%	100%	100%	100%
packages/react/src/components/Breadcrumbs/BreadcrumbsRoot.tsx	100%	100%	100%	100%
packages/react/src/components/Typography/Paragraph/Paragraph.tsx	100%	80%	100%	100%

Generated in workflow #80

[github-actions]

Preview deployments

Theme 5. Sep 2024 - 10:39 (Norwegian time)

[mimarz]

This will be done again in #2385