chore(deps): Update @gouvfr/dsfr

[Mintoo200]

No description provided.

[kevbarns]

@Mintoo200 Thanks for splitting the bump into its own PR, it reads far better this way. Handling the license gate with a workflow level env: DSFR_ACCEPT_LICENSE: 1 is the right move, it covers all three jobs that install.

Verified on the branch: yarn install passes, yarn build passes, tsc -p src and tsc -p src/bin pass. yarn test fails.

Blocking

yarn test fails on dsfrComponentDetectionClassPrefixes: "fr-display never opens a selector in display.css". The guard is right, the single rule in that file is .fr-display .fr-fieldset__element:last-child, where the class is only an ancestor. Use "display": [], the key has to stay since the record is total.

The display section is added to the cascade order with no module mapping to it, so the Display CSS is now dropped. src/Display/Display.tsx:45 renders className={"fr-display"}, and Header mounts <Display /> unless disableDisplay is set. Ran optimize-css on a throwaway project importing only Display: 5 components out of 46, and .fr-display .fr-fieldset__element appears 0 times in the output. Same through Header. Adding "display" to the Display and Header entries brings it to 6 and 10 components with the rule present, and the suite green.

To discuss

The position of display in the cascade order is correct, checked rather than assumed: 1.15.2's dsfr.main.css.map contains component/display/main.scss, and re-deriving the order yields 46 entries with display at index 41, right after password. Nothing to change there.

The ColorVariant change does not belong in this PR. fr-table--sm, --lg and --multiline already exist in 1.14.2, the version on main, so ColorVariant wrongly exposes them as colours today, independently of any bump. That is a standalone fix and would be better landing on main directly.

Gitignoring .dsfr.yml rather than committing it: I agree with you. Committing it would accept the DSFR terms on behalf of every contributor, which is not the repository's call. A line in CONTRIBUTING.md would help though: without the file, a first yarn install dies on [NO_YML] Le DSFR n'est pas installé dans ce projet, a message that does not say it comes from a dependency. The escape hatches worth documenting are yarn create @gouvfr/dsfr and DSFR_ACCEPT_LICENSE=1.

Open question for @garronej and @revolunet: is 1.15.2 wanted right now? What #510 actually needs stops at 1.14.3, which fixes the sort button selector while carrying neither the license gate, added in 1.15.0, nor the display section. Bumping to 1.14.3 would reduce this PR to one line and unblock #510 on its own. 1.15.2 is still worth having eventually, but then it is a decision to take on its own merits.

Optional

.gitignore is normalised to CRLF end to end, so a 3 line change shows up as 9 added and 6 removed.

Nothing on security: the env sits at workflow level, no secret is exposed, and bahmutov/npm-install@v1 was already in use.

[Mintoo200]

Blocking

yarn test fails on dsfrComponentDetectionClassPrefixes: "fr-display never opens a selector in display.css". The guard is right, the single rule in that file is .fr-display .fr-fieldset__element:last-child, where the class is only an ancestor. Use "display": [], the key has to stay since the record is total.

✅ Fixed

The display section is added to the cascade order with no module mapping to it, so the Display CSS is now dropped. src/Display/Display.tsx:45 renders className={"fr-display"}, and Header mounts <Display /> unless disableDisplay is set. Ran optimize-css on a throwaway project importing only Display: 5 components out of 46, and .fr-display .fr-fieldset__element appears 0 times in the output. Same through Header. Adding "display" to the Display and Header entries brings it to 6 and 10 components with the rule present, and the suite green.

Not sure I understand what you're saying, but I changed className={"fr-display"} into className={fr.cx("fr-display")} at src/Display/Display.tsx:45, and added "display" to REACT_DSFR_MODULE_TO_DSFR_COMPONENTS["Display"] and REACT_DSFR_MODULE_TO_DSFR_COMPONENTS["Header"]

To discuss

The position of display in the cascade order is correct, checked rather than assumed: 1.15.2's dsfr.main.css.map contains component/display/main.scss, and re-deriving the order yields 46 entries with display at index 41, right after password. Nothing to change there.

👌

The ColorVariant change does not belong in this PR. fr-table--sm, --lg and --multiline already exist in 1.14.2, the version on main, so ColorVariant wrongly exposes them as colours today, independently of any bump. That is a standalone fix and would be better landing on main directly.

Moved to #518 and removed from this pull request

Gitignoring .dsfr.yml rather than committing it: I agree with you. Committing it would accept the DSFR terms on behalf of every contributor, which is not the repository's call. A line in CONTRIBUTING.md would help though: without the file, a first yarn install dies on [NO_YML] Le DSFR n'est pas installé dans ce projet, a message that does not say it comes from a dependency. The escape hatches worth documenting are yarn create @gouvfr/dsfr and DSFR_ACCEPT_LICENSE=1.

yarn create @gouvfr/dsfr always updates the package and un-fixes the dependency. DSFR_ACCEPT_LICENSE=1 completely skips the license. As a workaround, I documented yarn create directly followed by a git restore on the lockfile and package.json. This is far from ideal, so if you have a better idea, I'm all ears.

Optional

.gitignore is normalised to CRLF end to end, so a 3 line change shows up as 9 added and 6 removed.

I believe this pull request actually re-normalise these lines. cat -e displays only CRLF on this branch and LF on main.