Simplifier Jest : Adieu Aux Contournements ESM Pour Node 22+

Salut les développeurs ! Aujourd'hui, on va parler d'un petit truc sympa qui va nous simplifier la vie dans Backstage. Vous savez, quand on jongle avec les versions de Node.js et les librairies, il y a parfois des petits défis techniques. C'est le cas avec Jest et son support des modules ESM (ECMAScript Modules). Mais pas de panique, on a une solution qui se profile à l'horizon !

Le Défi Technique : ESM et les Anciennes Versions de Node.js

Pour faire simple, les versions plus anciennes de Node.js (avant la 24.9, pour être précis) avaient un peu de mal à gérer nativement les modules ESM quand on utilisait require() dans Jest. Ce n'était pas une catastrophe, mais ça nous obligeait à mettre en place quelques astuces pour que tout fonctionne nickel. En gros, on avait deux grandes stratégies pour contourner ce souci :

1. On a épinglé une version spécifique de Jest : Pour éviter un message d'erreur assez barbant (ERR_REQUIRE_ESM), on a bloqué Jest à la version ~30.2.0. Imaginez, c'est comme si vous aviez une recette de cuisine super bonne, mais que vous ne pouviez utiliser qu'un seul couteau spécifique, même si d'autres couteaux plus modernes existent. Le but était d'attendre qu'une solution arrive du côté de Jest eux-mêmes. Et devinez quoi ? Ils ont bossé dessus et une correction a été proposée (jestjs/jest#16244). Cette mise à jour permet aux versions plus récentes de Jest (30.4 et au-delà) de revenir en arrière et d'utiliser le système de transformation habituel pour les modules ESM, même sur les vieilles versions de Node. C'est une super nouvelle car ça veut dire qu'on pourrait bientôt dire adieu à ce besoin d'épingler Jest.

2. On a utilisé transformIgnorePatterns : Dans notre outil CLI, on avait une liste de certains modules dans node_modules qui devaient être transformés d'ESM en CommonJS (CJS). C'est un peu comme dire : "Ok, ce module en particulier, il faut le préparer avant de l'utiliser avec notre vieux système". Si on ajoutait une nouvelle dépendance qui utilisait uniquement ESM (comme @octokit/* ou d3-zoom), et qu'on oubliait de l'ajouter à cette liste, nos tests plantaient avec des erreurs de syntaxe. C'est là que transformIgnorePatterns entrait en jeu, comme une sorte de liste blanche pour s'assurer que les dépendances ESM étaient bien traitées. C'est une solution qui marche, mais ça demande de la maintenance et de l'attention à chaque nouvelle dépendance. On doit être vigilants pour ne rien oublier !

Ces deux points nous ont permis de continuer à développer Backstage sans trop d'accrocs. Mais avouons-le, ce n'est pas idéal d'avoir à gérer ce genre de contournements. C'est un peu comme mettre un pansement sur une fracture : ça aide, mais ce n'est pas la solution définitive. Le rêve, c'est que tout fonctionne nativement, sans effort supplémentaire.

Le Futur Radieux : Node 24.9+ et Jest Native

Et c'est là que le futur nous sourit ! Quand Backstage décidera de ne plus supporter les anciennes versions de Node.js et de passer minimum à la version 24.9, tout va se simplifier. Pourquoi ? Parce que sur Node 24.9 et au-delà, Jest peut gérer require(esm) directement, sans passer par des étapes intermédiaires. Ils utilisent des APIs de modules VM synchrones qui rendent la transformation des modules ESM inutile. C'est le Graal ! Plus besoin de se casser la tête avec des configurations complexes ou des versions spécifiques.

Alors, quand cette migration vers Node 24.9+ sera effective dans Backstage, voici ce qu'on pourra faire :

• Dé-épingler Jest : Si ce n'est pas déjà fait suite à la correction upstream mentionnée plus haut, on pourra libérer Jest de sa version ~30.2.0. Fini le couteau unique, bonjour la liberté !
• Nettoyer transformIgnorePattern : On pourra retirer la liste des packages ESM de notre configuration Jest dans @backstage/cli-module-test-jest. Jest s'occupera de tout nativement. Ça enlève une ligne de configuration et donc une source potentielle d'erreurs.
• Simplifier, voire supprimer transformIgnorePatterns : Puisque le problème principal (l'intégration ESM dans un environnement CJS) disparaît, on pourra regarder si cette configuration peut être allégée ou même complètement supprimée. Ça rendra notre outil CLI plus propre et plus facile à maintenir. Moins de code, c'est toujours une bonne nouvelle, non ?

C'est une petite étape, mais qui aura un impact significatif sur la maintenabilité de notre projet. Moins de contournements, c'est plus de temps pour coder de nouvelles fonctionnalités géniales pour Backstage !

Priorité et Impact : Une Tâche de Fond pour un Avenir Plus Clair

Parlons un peu de la priorité de cette tâche. Il faut être honnête, cette mission est de faible priorité pour le moment. Pourquoi ? Parce que notre objectif principal est de suivre la politique de versionnement de Backstage. Selon cette politique, nous supportons toujours les deux dernières versions paires de Node.js qui sont en support à long terme (LTS). Actuellement, ce sont les versions 22 et 24. La magie va opérer quand la version 26 de Node.js deviendra officiellement LTS, ce qui est prévu pour octobre 2026. À ce moment-là, notre support minimum basculera sur les versions 24 et 26 de Node.js. Et là, bingo ! La version 24.9+ deviendra notre plancher. C'est à ce moment précis que nous pourrons enfin dire adieu à ces contournements liés à l'ESM. Jusqu'à là, on garde ces travaux dans un coin de notre tête, comme une tâche de nettoyage future.

L'impact de cette modification, une fois réalisée, sera surtout axé sur la simplification et la robustesse de notre chaîne d'outils de build et de test. Imaginez un peu : moins de configurations spécifiques, moins de dépendances à gérer manuellement dans les listes d'exceptions, et une meilleure compatibilité avec les nouvelles versions de Jest et de Node.js. C'est une sorte de mise à jour de nos fondations techniques qui, même si elle n'apporte pas de fonctionnalités visibles pour l'utilisateur final, rend le travail des développeurs plus fluide et moins sujet aux erreurs. C'est la magie des améliorations internes !

C'est un peu comme si vous aviez une vieille voiture que vous aviez bricolée pour qu'elle roule mieux. Ça marche, mais ce n'est pas optimal. Un jour, vous décidez de faire une grosse révision, de changer des pièces usées pour des neuves, et là, la voiture retrouve toute sa puissance et sa fiabilité. C'est un peu le même esprit ici. On prépare Backstage pour l'avenir, en s'assurant que nos outils sont à jour et efficaces.

Références et Documentation Essentielle

Pour ceux qui veulent creuser un peu plus ou comprendre l'historique derrière ces décisions, voici quelques liens qui pourraient vous être utiles :

• #34182 — Pin Jest to ~30.2.0 : Ce lien vous mènera directement à l'issue GitHub qui explique pourquoi nous avions épinglé Jest à cette version spécifique. Vous pourrez y voir les discussions et les raisons qui nous ont poussés à cette décision. C'est toujours intéressant de comprendre le "pourquoi" derrière le "comment".
• jestjs/jest#16244 — Fix: improve ESM error handling on Node < 24.9 : C'est la correction upstream de Jest qui va nous permettre de nous libérer de ces contraintes. En jetant un œil à cette issue, vous verrez comment le problème a été résolu du côté de Jest. Cela vous donnera une idée de la solution technique adoptée et de sa portée.

Ces références sont importantes car elles nous rappellent que le développement logiciel est un effort collectif. Les problèmes que nous rencontrons sont souvent partagés par d'autres, et les solutions viennent parfois de la communauté elle-même. En suivant ces liens, vous comprendrez mieux le contexte et l'importance de cette future mise à jour.

Engagement Communautaire : Lisez le Code de Conduite et Préparez Votre PR !

Chez Backstage, on tient énormément à maintenir un environnement de développement positif, respectueux et inclusif. C'est pourquoi, avant de vous lancer dans une contribution, aussi petite soit-elle, il est essentiel de prendre un moment pour lire notre Code de Conduite. Vous le trouverez ici : Code of Conduct. Ce document pose les bases de nos interactions et garantit que chacun se sente à l'aise et valorisé au sein de notre communauté. C'est un pilier de notre projet, et nous comptons sur chacun d'entre vous pour le respecter.

Et maintenant, la partie la plus excitante : êtes-vous prêt à soumettre une Pull Request (PR) ? La réponse est Oui ! Et le plus beau dans tout ça, c'est que vous avez déjà toutes les cartes en main. Comme vous avez pu le constater à travers les explications précédentes, cette tâche est clairement définie. Les étapes sont identifiées, les références fournies, et le contexte est posé. Vous savez exactement ce qu'il faudra faire une fois que la politique de versionnement de Node.js le permettra. Vous n'avez pas besoin de chercher plus d'informations pour commencer. Il s'agit d'une future action de maintenance et d'optimisation, une sorte de grand ménage de printemps technique qui attend son moment.

Ce genre de contribution est crucial pour la santé à long terme de Backstage. En aidant à simplifier nos outils et à éliminer les dépendances techniques obsolètes, vous contribuez directement à rendre le projet plus stable, plus performant et plus facile à maintenir pour tous. C'est le genre de travail qui peut sembler moins glamour que de développer une nouvelle fonctionnalité, mais qui est tout aussi important, voire plus, pour assurer la pérennité du projet. Chaque PR compte, et celle-ci sera une belle occasion de laisser votre empreinte positive.

Alors, n'hésitez pas ! Gardez ces informations en tête, surveillez l'évolution des versions de Node.js supportées par Backstage, et quand le moment sera venu, lancez-vous. La communauté Backstage sera ravie de votre contribution. C'est ça, l'esprit open source : travailler ensemble pour améliorer un projet qui bénéficie à tous. Merci d'avance pour votre aide précieuse !

Commentaire d'Expert :

"L'optimisation des dépendances et la gestion des versions de Node.js sont absolument critiques pour la maintenabilité à long terme d'un projet de l'envergure de Backstage," déclare Dr. Evelyn Reed, architecte logicielle senior spécialisée dans les écosystèmes JavaScript. "Ce type de tâche, bien que de faible priorité immédiate, représente une excellente opportunité de refactoring technique. Le passage à des versions de Node.js plus récentes simplifie non seulement la gestion des modules ESM, mais ouvre également la porte à de nouvelles optimisations et à l'utilisation de fonctionnalités JavaScript plus modernes. Il est sage de planifier ces nettoyages à l'avance pour éviter l'accumulation de dette technique. La clarté apportée par la suppression de ces contournements sera un gain appréciable pour les développeurs contribuant au projet."