Skip to content

Conversation

@GuillaumeKESTEMAN
Copy link
Contributor

This PR improves Node.js version management by making the CI automatically use the latest declared Node.js LTS from the engines field in package.json, instead of relying on volta.
It also removes npm version setup from the workflow for simplicity.

Main changes:

  • CI now extracts the Node.js version from engines.node in package.json, always tracking the latest LTS.
  • npm version is no longer set up in the workflow.
  • engines.node in package.json clearly lists supported Node.js versions.
  • volta.node and volta.npm are updated for local development consistency.

@GuillaumeKESTEMAN GuillaumeKESTEMAN self-assigned this Oct 30, 2025
@GuillaumeKESTEMAN GuillaumeKESTEMAN added chore Issue link to publishing, etc ci Updating the CI pipelines labels Oct 30, 2025
@GuillaumeKESTEMAN GuillaumeKESTEMAN marked this pull request as draft October 30, 2025 09:00
@GuillaumeKESTEMAN GuillaumeKESTEMAN marked this pull request as ready for review October 30, 2025 09:02
@GuillaumeKESTEMAN GuillaumeKESTEMAN force-pushed the chore/define-node-and-npm-engines branch from e6d59f0 to a033bb4 Compare October 30, 2025 09:02
Comment on lines -26 to -29
- name: Setup npm version
if: ${{ env.NPM_VERSION }}
shell: bash
run: npm install -g npm@${{ env.NPM_VERSION }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pourquoi supprimer cette parti car c'est le point essentiel pour que la step de check package lock fonction le fait d'avoir toujours la même version de npm pour tous, node étant plus secondaire.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Car j'utilise la version npm que node apporte.
Le soucis qu'on a eu était qu'on est passé de node 22 à node 24 ce qui a provoqué des breaking change sur la nouvelle version majeure npm apportée.
Là comme on gère correctement la version de node, pas besoin de s'embêter avec la version npm selon moi.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

il faut fixer la bonne version de npm pour les user de volta du coup

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ca c'est fait, j'ai passé la version volta en :

  • node : 24.11.0
  • npm : 11.6.1 (version par défaut livrée avec cette version de node)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

du coup au niveau engine cela veux dire qu'on l'on ne peux plus utiliser node 22.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pas de range pour la version de npm, il faut fixer un numéro de version, car sinon on prend le risque d'avoir une version de fix de npm qui change la génération du package lock comme ce fu le cas entre la version 11.6.0 et 11.6.1
https://github.com/npm/cli/releases/tag/v11.6.1
npm/cli#8579

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

je suis plutôt pour les ranges, au final, c'est peut-être l'outil de vérification du lock qui faudrait revoir. il faudrait regarder comment c'est fait sur d'autres projets Open Source mais figer une version de npm, je ne suis pas fan

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

l'outil de vérification du lock ne fait rien de plus que prend un snap du package-lock d'exécuter la commande npm i [--ignore-script --package-lock-only et de comparer le package-lock avec le snap précédent.
S'il n'y a pas de diff alors le package.json et package-lock son synchro sinon il fail et indique de mettre à jours le package lock via un npm i.

sauf que celons la version de npm utiliser il peux y avoir des différences dans la génération du package-lock comme ce fu le cas entre la version 11.6.0 et 11.6.1 ou il au fix un truc qui a pour conséquence que package-lock générer en 11.6.0 et n'est plus le que même que si on le génère en 11.6.1

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ailleurs ils ne s'amusent à définir de version de npm tout court 😅 https://github.com/facebook/react/blob/main/packages/react/package.json#L49 https://github.com/react-hook-form/react-hook-form/blob/master/package.json#L137 https://github.com/mui/material-ui/blob/master/package.json#L178

pour par que la clé engine sert à définir pour qu'elle version de node la lib et compatible, alors pour nos lib front cela na aucun intérêt mais pour des lib back la par contre sa change tous

@sonarqubecloud
Copy link

sonarqubecloud bot commented Nov 4, 2025

Quality Gate Failed Quality Gate failed

Failed conditions
6.9% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

chore Issue link to publishing, etc ci Updating the CI pipelines

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants