Suppression des dépendances JavaScript obsolètes : CRA, Moment, jQuery et bien d’autres

La plupart des projets JavaScript intègrent quelques dépendances qui représentaient le choix évident au moment de la création du répertoire, mais qui constituent aujourd’hui un fardeau inutile : des bundles volumineux, des vulnérabilités non corrigées, une incompatibilité avec les environnements modernes, ou des fonctionnalités désormais fournies gratuitement par la plateforme. Aucune d’entre elles ne provoque de problème du jour au lendemain, ce qui explique précisément pourquoi elles persistent. Ce guide passe en revue les bibliothèques et outils obsolètes, figés en mode maintenance ou en déclin progressif, explique pourquoi chacun d’eux est resté en arrière, et indique les alternatives à privilégier afin de pouvoir planifier des migrations de manière réfléchie plutôt que sous pression.

Outils de construction et de scaffolding

Create React App

Pendant des années, Create React App (CRA) a été le moyen de lancer un projet React. Au début de 2025, l’équipe React l’a officiellement déprécié en tant que point de départ pour de nouvelles applications, et il ne reçoit plus d’actualisations significatives, ce qui laisse les problèmes de sécurité liés à son écosystème non résolus. Le nombre de téléchargements a fortement diminué à mesure que les équipes ont migré vers d’autres solutions.

Les raisons en sont structurelles : personne ne le maintient activement, ses hypothèses concernant le bundling et les serveurs de développement sont obsolètes, tandis que les alternatives répondent aux exigences modernes telles que le rendu côté serveur, des compilations plus rapides et une meilleure expérience de développement sans configuration supplémentaire. Parmi les bons remplaçants on trouve :

• Vite avec @vitejs/plugin-react pour les applications single-page typiques
• Next.js, Remix / React Router ou un autre framework complet si l’application nécessite un routeur, des conventions de récupération de données ou du code côté serveur

Parcel ou Rsbuild si vous souhaitez quelque chose de plus léger

Puisqu’une application CRA est principalement composée de code React standard ainsi que d’une configuration de compilation cachée, la migration est généralement bien moins importante que ce à quoi s’attendent les équipes : il suffit de remplacer l’outil de compilation, de modifier les conventions relatives au point d’entrée HTML et aux variables d’environnement, tandis que les composants eux-mêmes restent inchangés. Si vous commencez à zéro, le guide pas à pas présenté dans notre guide de configuration React et Vite décrit cette nouvelle base de référence.

Webpack pour les nouveaux projets

Webpack est loin d’être mort. Un grand nombre d’applications en production sont encore développées avec lui, et cela ne changera pas de sitôt. Ce qui diminue, c’est sa part dans les nouveaux projets, principalement en raison de la complexité de sa configuration et de délais de démarrage plus lents par rapport aux outils plus récents. Pour les projets frontend complets, Vite est actuellement la solution par défaut, avec Rspack et des configurations basées sur esbuild comme autres options solides. Webpack reste un choix raisonnable pour des configurations existantes très complexes, mais il est rarement le point de départ idéal pour un nouveau projet. Pour une comparaison plus approfondie des options, consultez choisir un bundler.

Bibliothèques intégrées par la plateforme

Moment.js

Presque tous les développeurs JavaScript ont utilisé Moment.js à un moment donné. Ses propres mainteneurs le décrivent depuis longtemps comme un projet obsolète en mode maintenance. Il est volumineux, ses objets sont modifiables par défaut (ce qui provoque souvent des bugs lorsque une date est modifiée en un endroit et consultée ailleurs), et il ne permet pas une compression efficace.

Le traitement natif des dates s’est amélioré, et de petites bibliothèques immuables accomplissent désormais cette tâche avec de meilleures performances. Voici vos options, approximativement classées par ordre de préférence :

• Intl.DateTimeFormat pour un formatage adapté aux paramètres régionaux
• Temporal, la nouvelle API intégrée pour les dates et les heures attendue depuis des années par les développeurs, qui est progressivement déployée sur différents environnements et navigateurs ; vérifiez son support actuel pour vos cibles avant de vous y fier
• date-fns, Luxon ou Day.js si l’utilisation d’une bibliothèque reste justifiée

Si Moment figure encore dans votre arbre de dépendances, planifiez la migration. La réduction seule de la taille du bundle est souvent considérable.

jQuery

jQuery a résolu de véritables problèmes entre navigateurs dans les années 2010. Pour du code nouveau aujourd’hui, son utilisation n’est presque jamais justifiée, puisque des API DOM standardisées, fetch ainsi que des frameworks de composants couvrent tout ce qu’il était auparavant nécessaire pour pallier les incohérences. Du JavaScript pur avec querySelector, classList, addEventListener et le fetch natif suffit pour la plupart des opérations directes sur le DOM, tandis que React, Vue, Svelte ou Solid prennent le relais lorsque des interfaces basées sur des composants sont nécessaires. Les bases de code anciennes continueront d’utiliser jQuery pendant des années, ce qui est normal, mais l’employer dans un projet entièrement nouveau constitue un signe d’alerte.

Lodash et Underscore

Au préalable à ES2015, Lodash était presque indispensable. Aujourd’hui, la plupart de ses outils disposent d’équivalents natifs : des méthodes d’array telles que map, filter et reduce, Object.entries, la chaînage optionnel, le coalescing nullish et bien d’autres encore. Il est difficile de justifier l’inclusion de toute la bibliothèque, ou même de grandes parties d’elle, uniquement pour utiliser quelques fonctions. Il convient de partir du langage lui-même et d’ajouter des outils ciblés uniquement là où l’API native est réellement insuffisante, par exemple pour la comparaison de profondeur ou le débouncing. Notre article sur les fonctionnalités natives qui remplacent les dépendances d’outils présente des exemples concrets de remplacements.

Tests et réseaux

Enzyme

Pendant longtemps, Enzyme a été le moyen dominant pour tester les composants React, mais il n’a jamais bien adapté à React 18 et ses fonctionnalités concurrentes, ce qui a entraîné une chute drastique de son adoption. Comme Enzyme encourageait le test des éléments internes des composants (état, méthodes d’instance, arbres de rendu superficiels), la migration implique en partie un changement de mentalité. React Testing Library, l’option recommandée à la fois par la communauté et par l’équipe React, teste plutôt ce que voit et fait l’utilisateur. Associez-le à Vitest ou Jest en tant qu’outil d’exécution.

request et node-fetch v2

request a été officiellement déprécié il y a longtemps et ne reçoit plus de correctifs de sécurité, ce qui représente un risque important pour tout usage encore en vigueur. Les téléchargements de node-fetch v2 ont également fortement chuté, car Node.js 18 et versions ultérieures intègrent un fetch global (il était indiqué comme expérimental dans les premières versions, il convient donc de vérifier son comportement selon votre version de Node). Utilisez le fetch natif, qui fonctionne désormais sous les versions modernes de Node ainsi que dans tous les navigateurs actuels. Lorsque vous avez besoin de tentatives répétées, d’intercepteurs ou d’un streaming plus performant, envisagez undici, ky ou got.

Autres éléments à surveiller

Quelques autres changements méritent également d’être ajoutés à votre liste de mises à jour :

• Selon son calendrier de publication, ESLint 9.x atteindra la fin de sa vie utile en août 2026 ; planifiez le passage à la version v10 et vérifiez les dates sur le site d’ESLint.

Le SDK AWS pour JavaScript v2 est désormais hors support. Passez aux clients modulaires v3 situés sous @aws-sdk/*, qui vous permettent également d’importer uniquement les clients que vous utilisez.

Des outils plus anciens tels que vue-cli et Nuxt 2 sont en fait obsolètes.

Node.js continue de déprécier les fonctions intégrées et les API anciennes à mesure que le runtime se modernise ; consultez donc la liste officielle des dépréciations avant chaque mise à niveau majeure.

Des runtimes comme Bun intègrent davantage de fonctionnalités nativement, ce qui réduit encore davantage le besoin de nombreux petits paquets utilitaires.

Une routine pour maintenir les dépendances à jour

Il ne suffit pas de remplacer ces bibliothèques une seule fois ; l’objectif est d’adopter une habitude qui empêche l’accumulation de nouvelles dépendances obsolètes.

1. Faites un audit de package.json régulièrement et exécutez npm outdated ainsi que npm audit afin de détecter d’éventuelles déviations.

Préférez les fonctionnalités natives de la plateforme une fois qu’elles sont stables et largement supportées dans les environnements ciblés.

Faites attention aux annonces de dépréciation publiées par React, Node.js, ESLint ainsi que par les mainteneurs de vos principales bibliothèques.

Considérez le fait que « ça fonctionne encore » comme un état temporaire. Les correctifs de sécurité continus et le soutien de l’écosystème l’emportent sur la facilité d’ignorer les problèmes.

Préférez par défaut des outils modernes pour les nouveaux projets : Vite, la fonction fetch intégrée, Temporal lorsque c’est possible, ainsi que les dernières versions majeures des frameworks.

Un compromis utile à garder à l’esprit : toutes les dépendances anciennes ne méritent pas d’être réécrites immédiatement. Un outil interne stable utilisant jQuery ou Webpack peut coûter plus cher à migrer que ce qu’il permettra d’économiser. Priorisez en fonction du niveau d’exposition. Tout élément non entretenu qui interagit avec le réseau, les entrées utilisateur ou votre pipeline de construction (request, CRA, AWS SDK v2) doit être traité en premier ; les bibliothèques à forte taille telle que Moment et Lodash viennent ensuite ; la modernisation purement stylistique peut attendre.

Points clés

• Les packages obsolètes et non maintenus représentent d’abord un problème de sécurité, puis un problème de performance ; classez donc les migrations en fonction du risque.
• De nombreux outils autrefois essentiels (Moment, Lodash, jQuery, request) ont été intégrés au langage, au DOM ou au runtime, ce qui rend leur remplacement moins volumineux que la dépendance elle-même.

Les migrations d’outils tels que de CRA à Vite concernent généralement la configuration, et non le code de l’application.

Un audit régulier ainsi que l’utilisation par défaut d’outils modernes pour les nouveaux projets permettront de garder cette liste courte à l’avenir.