Moment.js est-il obsolète ? Ce que cela implique pour les dates que votre entreprise ne peut pas se permettre de se tromper

Principaux enseignements

• Moment et Moment Timezone sont des projets hérités actuellement en mode maintenance ; pour tout nouveau projet, il est recommandé d'utiliser des alternatives.
• Le fait qu'un logiciel soit considéré comme « obsolète » n'implique pas nécessairement qu'il doive être désinstallé rapidement, et cela ne rend pas pour autant toutes les installations vulnérables.
• Les migrations depuis Moment sont bien plus souvent dues à des problèmes de mutabilité et d'analyse syntaxique peu rigoureuse qu'à des problèmes de syntaxe.
• Choisissez une solution de remplacement en fonction du fuseau horaire et du comportement d'analyse dont vous avez besoin, et non en fonction des tests de performance portant sur la taille des paquets.

Moment est l’une des rares bibliothèques à avoir publiquement conseillé à ses utilisateurs de cesser de l’utiliser. Le projet a été déclaré « obsolète » et placé en « mode maintenance » dès 2020 ; sa page npm le signale toujours comme un projet obsolète qui n’intègre plus de nouvelles fonctionnalités, et le fichier README de Moment Timezone va encore plus loin en conseillant à la plupart des utilisateurs de choisir une autre bibliothèque. Sur le papier, cela ne correspond pas à une fin de vie. Pour une équipe bloquée sur la version 2.24.0, cependant, le problème concret y ressemble fort, car les corrections en amont sont intégrées à la version actuelle de Moment et personne en amont ne les rétroporte vers une version aussi ancienne.

La difficulté réside dans le fait que le remplacement de Moment n'est pas un simple exercice de syntaxe. Ses objets sont modifiables et son analyse syntaxique est plus tolérante que celle des alternatives modernes, qui sont délibérément moins indulgentes ; ainsi, une migration mal effectuée se traduit par des dates erronées plutôt que par des erreurs de compilation.

Moment a résolu le problème avant même que la plateforme ne soit prête

Moment.js a fait son apparition à une époque où la gestion des dates en JavaScript était véritablement pénible. L’analyse et le formatage variaient d’un moteur à l’autre, les calculs liés aux fuseaux horaires relevaient du hasard, et formater une date sans bibliothèque d’aide impliquait de manipuler manuellement des chaînes de caractères, une tâche dont personne ne voulait se charger. Moment a résolu ce problème, et l’a fait suffisamment bien pour devenir la référence par défaut pendant près d’une décennie. Considérer son âge comme un échec, c’est voir les choses à l’envers. Elle a résolu un véritable problème avant que la plateforme ne soit à la hauteur.

C'est ce qui rend l'expérience actuelle si étrange. Vous ouvrez la page du paquet pour vérifier une version, et le fichier README s'ouvre avec un avertissement indiquant qu'il s'agit d'un projet obsolète en mode maintenance. Puis vous faites une recherche dans vos propres dépôts et vous constatez que Moment figure dans trois d'entre eux.

On pourrait facilement interpréter l’expression « mode maintenance » comme une légère incitation à adopter une version plus récente. Mais ce n’est pas du tout le sens. Il s’agit d’une indication sur ce qui sera corrigé et ce qui ne le sera pas, et dès lors que vous l’interprétez ainsi, la version épinglée dans votre package.json commence à prendre une autre apparence.

Moment.js est-il obsolète, et que signifie le « mode maintenance » ?

Pas au sens strict du terme. Il n'y a pas eu d'annonce officielle de fin de vie ni de « tombstone commit ». Le projet s'est simplement qualifié de « projet héritage » en mode de maintenance et a découragé toute nouvelle adoption, ce qui constitue une réponse plus précise et plus utile qu'un simple « oui » ou « non ».

Les responsables de la maintenance sont clairs quant aux limites du projet, et ils les ont redéfinies en août 2026 pour la première fois depuis 2020. Moment continuera à traiter les problèmes de sécurité critiques, et les mises à jour des données de fuseaux horaires de Moment suivront toujours les publications de l’IANA. Il n’intégrera toujours pas de nouvelles fonctionnalités destinées aux utilisateurs, et il ne procède pas à une refonte de l’API mutable. Ce qui a changé, c’est le champ d’application. La politique de 2020 excluait tout travail sur la taille des bundles et le « tree shaking », ainsi que toute version 3. La mise à jour de 2026 élargit ce champ d'action, permettant aux responsables de la maintenance de s'occuper du packaging, des déclarations TypeScript, des outils de compilation et de la composition des bundles.

Et ce n'étaient pas que des paroles en l'air. La version 2.31.0 a été publiée le 14 septembre 2026, avec un correctif de sécurité, une longue liste de corrections de bogues et des mises à jour des paramètres régionaux – il s'agissait de la première version depuis la 2.30.1, sortie fin 2023.

Le projet est également revenu sur la promesse faite en 2020 de ne jamais publier de version 3. Il n'y a pas de calendrier prévu pour la version 3.0, et toute version 3.0 resterait une version de maintenance plutôt qu'un retour au développement de nouvelles fonctionnalités, mais la porte qui avait été soudée en 2020 est désormais simplement fermée. Telle est la limite actuelle, et elle est un peu plus large qu'il y a six ans.

Moment relève de la Fondation OpenJS en tant que projet « At-Large »; il bénéficie donc d'un cadre de gouvernance neutre et d'une politique de sécurité publiée. Aucun de ces deux éléments ne finance la rétroportabilité vers d'anciennes branches de version. Tout correctif de sécurité intégré est appliqué au code actuel.

Retour à la réalité : pour une équipe bloquée sur la version 2.24.0, le mode de maintenance engendre un problème de prise en charge lié à la fin de vie (EOL). Les travaux de sécurité en amont ciblent la version actuelle de Moment ; par conséquent, la période de prise en charge effective de votre version a pris fin il y a plusieurs années, même si le projet lui-même est toujours bien vivant.

L'historique du CVE est court et s'affiche là où vous l'utilisez réellement

Le nombre de vulnérabilités recensées dans Moment est faible, ce qui est une bonne nouvelle. Le hic, c’est que chaque entrée se trouve dans du code chargé de traiter les données d’entrée (analyse des dates, analyse des durées et chargement des paramètres régionaux), et ce sont précisément ces chemins que les applications ont tendance à alimenter avec les données des utilisateurs.

La vulnérabilité CVE-2022-31129 se caractérise par un comportement quadratique (N²) dans preprocessRFC2822 lorsqu’il supprime les commentaires hérités d’une chaîne de caractères représentant une date. Si l’on lui fournit une entrée suffisamment longue, l’analyse se bloque, ce qui constitue une technique classique de déni de service. CVE-2022-24785 est une faille de traversée de chemin via une chaîne de paramètres régionaux fournie par l’utilisateur et utilisée pour changer les paramètres régionaux de Moment ; elle a été corrigée dans la version 2.29.2. CVE-2017-18214 est une faille ReDoS antérieure liée à l’analyse des expressions régulières dans les anciennes versions, et CVE-2016-4055 est une faille ReDoS connexe dans duration(), corrigé dans la version 2.11.2.

La question qui détermine le niveau de gravité dans votre application est précise. Une entrée contrôlée par un attaquant peut-elle atteindre le constructeur de Moment, moment.duration(), ou le commutateur de paramètres régionaux, et qui vérifie cela lors de l'entrée ? Si aucun élément non fiable n'atteint ces chemins, votre vulnérabilité réelle est inférieure à ce que le score brut laisse supposer.

Attention : Limitez la longueur de toute chaîne de caractères représentant une date ou une durée avant qu’elle n’atteigne Moment. L’avis publié par les responsables du projet concernant la vulnérabilité CVE-2022-31129 recommande de s’en tenir à 200 caractères, ce qui permet de contourner le bogue RFC2822 et de réduire considérablement l’exposition aux deux autres. Ce même avis indique qu’un tel filtre est également efficace contre la plupart des futurs bogues de type ReDoS. Il n’a toutefois aucun effet sur le bogue lié aux paramètres régionaux. Pour ces derniers, seule une intervention manuelle moment.locale() une chaîne provenant d'une liste blanche des paramètres régionaux que vous fournissez effectivement.

Le support à vie de TuxCare pour Moment.js Cela concerne les versions 2.0.0, 2.10.6 et 2.24.0, qui sont toutes antérieures aux correctifs de la série 2.29.x. La vulnérabilité de type « path traversal » (CVE-2022-24785) affecte chacune d’entre elles. Les CVE liées au ReDoS varient selon les versions. Le ReDoS RFC2822 (CVE-2022-31129) ne concerne que les versions à partir de la 2.18.0 ; il affecte donc la version 2.24.0, mais pas les deux versions antérieures. La vulnérabilité ReDoS liée à l'analyse syntaxique héritée (CVE-2017-18214) a été corrigée avant la sortie de la version 2.24.0 ; ce sont donc les versions 2.0.0 et 2.10.6 qui sont concernées. La vulnérabilité ReDoS liée à la durée (CVE-2016-4055) se limite encore davantage et ne concerne que la version 2.10.6. La version 2.0.0 se situe dans la plage publiée, mais son duration() n'analyse pas du tout les chaînes de caractères ; par conséquent, l'expression régulière vulnérable n'existe tout simplement pas.

TuxCare a déjà publié des correctifs pour chacune de ces vulnérabilités CVE concernées par les versions qu’elle prend en charge. Rendez-vous sur le CVE Tracker pour découvrir toutes les vulnérabilités et les correctifs disponibles pour les logiciels open source pris en charge par TuxCare ainsi que leurs chaînes de dépendances.

Choisir une alternative à Moment.js, c'est la partie la plus facile

Si vous avez décidé de partir, la liste est courte, et faire votre choix ne prendra que quelques instants. La première option est une bibliothèque qui ne modifie jamais les objets sur place. Luxon et Day.js renvoient de nouveaux objets immuables, tandis que date-fns fonctionne sur de simples Date valeurs et en renvoie de nouvelles. La seconde s'appuie sur la fonction intégrée Intl API de mise en forme et de gestion des paramètres régionaux. La troisième est l'API native « Temporal », qui a atteint le niveau 4 du TC39 en mars 2026 et est déjà intégrée à Chrome, Edge et Firefox. Safari ne la propose pour l'instant qu'en « Technology Preview », mais une fois qu'elle sera disponible partout, le recours à une bibliothèque tierce deviendra facultatif pour de nombreux cas d'utilisation.

La question la plus épineuse est de savoir de quelles fonctionnalités de Moment votre application dépend actuellement, car c’est cela qui détermine ce qui ne fonctionnera plus lorsque vous effectuerez la migration. Une bibliothèque objectivement mieux conçue peut tout de même produire des résultats différents pour les mêmes données d’entrée que celles que votre code transmet à Moment depuis des années.

Considérez « Moment Timezone » comme une décision distincte. Il dispose de son propre ensemble de données de fuseaux horaires et de sa propre interface API, et le code tenant compte des fuseaux horaires qui s'appuie dessus représente la partie la plus complexe du travail. Le code qui se contente de formater les dates est facile à transférer. Ce n'est pas le cas du code qui effectue des calculs liés aux fuseaux horaires au moment du passage à l'heure d'été.

Les problèmes de sémantique des dates qui entravent les migrations

C'est là que les migrations Moment échouent réellement. La structure de l'API est facile à transposer. La sémantique sous-jacente, en revanche, ne l'est pas.

Commençons par la mutabilité. Les objets `Moment` sont modifiés in situ, donc .add() et .startOf() modifier l'instance sur laquelle vous les avez appelées. Un code qui transmet une instance Moment partagée et s'attend à ce que chaque appel la modifie dépend de ce comportement, souvent sans que personne ne s'en rende compte. Luxon, Day.js et Temporal renvoient en revanche de nouveaux objets, et les fonctions de date-fns renvoient de nouveaux Date valeurs. Si vous reprenez ce modèle d’appel tel quel, il produira discrètement un résultat erroné au lieu de générer une erreur, car la valeur que vous vouliez modifier n’a jamais été modifiée.

Vient ensuite l'analyse syntaxique. Moment est, par conception, tolérant. Il accepte des données que des bibliothèques plus strictes rejetteraient d'emblée ou interpréteraient différemment, et lorsqu'une chaîne de caractères n'est conforme ni à la norme ISO 8601 ni à la RFC 2822, il se rabat sur le format natif Date le constructeur, une source classique de bogues de type « off-by-one-day ». Si l'on remplace ce dernier par un analyseur syntaxique plus strict, les entrées qui « fonctionnaient » auparavant risquent désormais d'être rejetées ou d'aboutir à un jour différent.

Conseil d'initié : Les jetons de format ne sont pas non plus portables. Moment’s YYYY-MM-DD est yyyy-MM-dd dans date-fns et Luxon. Day.js conserve les jetons de Moment, tandis que date-fns génère au moins une exception sur YYYY par défaut. Luxon ne lance rien du tout. Il ne reconnaît pas YYYY et l'affiche tel quel, et DD signifie une date localisée à cet endroit, donc YYYY-MM-DD donne un résultat du type « YYYY-12-29 décembre 2026 ». Le remplacement automatique de chaînes de caractères est une méthode bien connue qui permet de générer silencieusement des résultats erronés qu'aucun compilateur ne détectera.

Les fuseaux horaires posent encore plus de problèmes. L'heure locale par rapport à l'UTC, les changements d'heure liés à l'heure d'été et les données historiques sur les fuseaux horaires peuvent présenter de légères différences d'une bibliothèque à l'autre, et ces différences n'apparaissent qu'à des dates précises. Les données de paramètres régionaux et les balises de format varient également, mais aucune de ces différences ne se traduit par une erreur flagrante.

C'est le mode de défaillance qui rend cela dangereux. Vos tests sont réussis. La compilation se déroule sans problème. Rien ne pose problème dans l'environnement de CI. Puis, un rapport de fin de mois est publié avec un jour de retard, uniquement pour les utilisateurs d'un fuseau horaire précis, et uniquement à la limite de celui-ci.

Imaginez un produit d'analyse SaaS comportant environ 400 points d'appel Moment répartis entre la configuration des graphiques, l'exportation au format CSV et les résumés envoyés par e-mail de manière programmée. Les graphiques et les exportations sont testés en permanence, ce qui permet de détecter rapidement leurs bugs. Les résumés programmés s'exécutent une fois par mois ; ils formatent une plage de dates selon le fuseau horaire du destinataire et envoient discrètement une période erronée à un sous-ensemble de clients pendant tout un cycle de facturation avant que quiconque ne s'en aperçoive. Voilà à quoi ressemble concrètement une migration Moment qui a échoué.

Un plan de remplacement axé sur le comportement

Une stratégie qui fait ses preuves dans un code de grande envergure s'articule autour du comportement, et non autour d'une recherche globale de la chaîne de caractères. moment. On garde les parties risquées pour la fin, une fois qu'on a la preuve que les parties faciles ont bien tenu.

Commencez par recenser toutes les utilisations de `Moment` et `MomentTimezone`, y compris les dépendances transitives et les copies intégrées dans les paquets fournisseurs ou les bibliothèques de composants. Classez ensuite chaque point d’appel en fonction de son activité réelle : analyse syntaxique, mise en forme, opérations arithmétiques, localisation ou opérations liées au fuseau horaire. Ces catégories présentent des risques de migration très différents, et c’est en les regroupant toutes dans une seule catégorie que les équipes se retrouvent prises au dépourvu.

Ajoutez des tests de régression portant sur des dates réelles et des cas limites connus avant de modifier la moindre ligne de code. Les changements d’heure d’été, les années bissextiles, les passages à la fin du mois et les utilisateurs hors fuseau horaire UTC sont les sources de problèmes les plus courantes. Ensuite, acheminez la gestion des dates via un module interne dédié, afin que la bibliothèque sous-jacente devienne un détail d’implémentation que vous pouvez remplacer derrière une interface stable, plutôt que de devoir gérer 400 appels directs dispersés dans le code. Ce « wrapper » est le modèle qui a réellement fait ses preuves.

Ce n’est qu’ensuite qu’il faudra remplacer les cas d’utilisation restreints et à faible risque, ce qui permettra de gagner en confiance et de développer des outils pour les cas plus complexes. Surtout, évitez d’utiliser deux modèles de données au sein d’un même flux métier sans délimitation explicite entre eux, car le mélange de logique mutable et immuable dans un même flux est une véritable source de bogues.

Prise de décision : faible encombrement, couverture de test solide et absence de logique liée au fuseau horaire ? Migrez dès maintenant. Utilisation intensive des fuseaux horaires ou des paramètres régionaux ? Commencez par encapsuler, puis migrez module par module. Un bundle figé ou un composant fournisseur intégrant Moment ? Mettez à jour ou remplacez la dépendance lorsque le packaging le permet, et cessez de considérer la suppression totale comme une priorité immédiate.

Quand le fait de conserver Moment temporairement est la décision la plus raisonnable

Parfois, la réponse honnête est que vous ne procéderez pas à la migration ce trimestre, et cela peut être la bonne décision. Pensez aux logiques liées à la réglementation ou aux dates financières, où une erreur d’un seul jour constitue un manquement à la conformité ; aux grandes applications internationalisées dont le comportement en fonction des paramètres régionaux n’est pas entièrement documenté ; aux produits embarqués aux cycles de publication longs ; ou encore aux applications ne disposant pas d’une couverture de test suffisante pour valider une migration précipitée. Dans tous ces cas, supprimer Moment sous la pression du temps est la décision la plus risquée.

La mise en garde est claire. Le terme « temporaire » doit être associé à un responsable, à une date et à un bon. Sans ces trois éléments, « temporaire » signifie simplement que lors du prochain contrôle, on constatera que l’objet est toujours là.

C'est précisément pour combler cette lacune que les correctifs pris en charge par les éditeurs ont été conçus. L'ELS de TuxCare couvre moment 2.0.0, 2.10.6 et 2.24.0, ainsi que moment-timezone 0.4.1, dans le cadre de son Couverture des bibliothèques JavaScript. Les correctifs sont diffusés via npm grâce aux données SBOM et VEX, ce qui permet de vérifier la traçabilité. Moment ne présente aucune dépendance d'exécution ; la question de la couverture porte donc sur Moment lui-même, et non sur une chaîne de paquets sous-jacents.

Les correctifs de sécurité continuent d'être appliqués à la version épinglée tandis que vos tests de migration axés sur le comportement se déroulent à un rythme raisonnable, ce qui vous évite d'avoir à réécrire la logique de gestion des dates dans l'urgence d'une échéance fixée par une divulgation sans rapport avec votre projet. Vous pouvez ainsi effectuer la migration selon votre propre calendrier, et non selon celui des divulgations.

La place d'OpenJS dans le développement durable

Moment est hébergé par la Fondation OpenJS, qui gère le programme « Ecosystem Sustainability Program » afin que les versions archivées, en fin de vie et plus anciennes de ses projets puissent bénéficier d’une couverture de sécurité commerciale, une partie des recettes étant reversée aux projets. TuxCare y participe en tant que membre « Gold » et prestataire, et ce programme est non exclusif.

La meilleure alternative, c'est celle qui a fait ses preuves

Les chiffres de référence ne vous sauveront pas en fin de mois. La meilleure alternative à Moment.js est celle dont vous avez vérifié la sémantique par rapport aux dates pour lesquelles votre entreprise ne peut se permettre aucune erreur.

Résumé

Nom de l'article

Moment.js est-il obsolète ? Statut de l'ancienne version, CVE et options d'assistance

Description

Moment.js est un projet hérité en mode de maintenance. Découvrez ce que cela implique en matière de sécurité, pourquoi les migrations échouent lors de l'exécution, et quelles sont vos options.

Auteur

Artem Karasev

Nom de l'éditeur

de TuxCare

Logo de l'éditeur