npm outdated pour prioriser les mises à jour d’un thème avant l’accumulation

Un projet front dont personne ne surveille plus les versions depuis des mois finit toujours par accumuler un écart silencieux entre ce qui est installé et ce qui existe réellement. Avant de se lancer dans une mise à jour générale, souvent risquée sans visibilité préalable, la commande npm outdated donne une photographie précise de cet écart, dépendance par dépendance, sans rien modifier.

Lire les trois colonnes qui comptent

Exécutée sans argument à la racine d’un projet contenant un package.json, npm outdated affiche un tableau dont trois colonnes concentrent l’essentiel de l’information :

npm outdated

Package                  Current   Wanted   Latest  Location
@wordpress/scripts         26.4.0   26.19.0   30.2.0  node_modules/@wordpress/scripts
sass                        1.62.0    1.77.6    1.79.4  node_modules/sass
webpack                      5.75.0    5.94.0    5.94.0  node_modules/webpack

Current indique la version effectivement installée dans node_modules au moment de l’exécution. Wanted indique la meilleure version disponible qui reste compatible avec la contrainte semver déclarée dans package.json, celle qu’une simple commande npm update installerait sans toucher au fichier package.json lui-même. Latest indique la toute dernière version publiée sur le registre npm, sans tenir compte de la contrainte de version déclarée, qu’elle soit compatible ou non avec le projet en l’état.

Ce que révèle l’écart entre Wanted et Latest

L’écart entre ces trois colonnes raconte une histoire différente selon les paquets. Quand Current et Wanted sont identiques mais que Latest est plus élevé, comme pour webpack dans l’exemple ci-dessus, le projet est à jour dans les limites de sa propre contrainte de version : une montée vers Latest nécessiterait de modifier explicitement la contrainte dans package.json, pas seulement de relancer une commande d’installation.

Quand Current est inférieur à Wanted, comme pour sass dans l’exemple, une simple commande npm update suffit à combler l’écart, sans risque de rupture de compatibilité puisque la nouvelle version reste dans la plage déclarée par le semver du projet. C’est le cas le plus simple à traiter, et souvent celui qui a le meilleur rapport entre l’effort de mise à jour et le risque de régression.

Le cas le plus révélateur d’un projet réellement laissé à l’abandon apparaît quand Wanted et Latest sont eux-mêmes très éloignés, comme pour @wordpress/scripts dans l’exemple : la contrainte de version du projet a été fixée il y a longtemps sur une plage qui n’a jamais suivi les versions majeures publiées depuis. Combler cet écart demande de modifier explicitement la contrainte de version, de lire le changelog des versions intermédiaires, et de tester en profondeur, puisque plusieurs versions majeures séparent l’installé du disponible.

Chez WP Moderne, un npm outdated est systématiquement relancé avant toute reprise d’un thème front laissé de côté plus de six mois, avant même d’ouvrir la moindre ligne de code.

Prioriser plutôt que tout mettre à jour d’un bloc

Face à une longue liste de paquets obsolètes, la tentation de lancer un npm update global puis de forcer chaque contrainte à sa dernière version disponible mène souvent à une cascade de ruptures difficiles à diagnostiquer collectivement. Une priorisation plus sûre distingue trois catégories dans la sortie de npm outdated :

• Les paquets où Current et Wanted diffèrent : mise à jour immédiate et à faible risque via npm update, sans modification de package.json.
• Les paquets d’outillage de build (bundler, compilateur Sass, outils WordPress officiels) dont l’écart avec Latest est important : traités un par un, changelog en main, en isolant chaque montée de version dans un commit distinct pour pouvoir identifier facilement laquelle a introduit une régression.
• Les paquets applicatifs qui touchent directement au rendu ou au comportement visible du thème : testés visuellement après chaque montée de version, jamais groupés avec les autres mises à jour.

Cette approche transforme une dette technique qui semble décourageante en une série de mises à jour ciblées, chacune vérifiable indépendamment, plutôt qu’un unique commit massif dont la moindre régression devient très difficile à isoler après coup.

Une limite à connaître : outdated ne dit rien des vulnérabilités

Il est important de ne pas confondre npm outdated, qui compare uniquement des numéros de version, avec npm audit, qui interroge une base de vulnérabilités connues. Un paquet peut apparaître parfaitement à jour dans npm outdated tout en étant concerné par une faille de sécurité récemment publiée sur sa version actuelle, si aucune version corrigée n’est encore sortie. Les deux commandes répondent à des questions différentes et se complètent, sans que l’une ne puisse remplacer l’autre dans une routine de maintenance sérieuse.

Ce qu’il faut retenir

npm outdated transforme une question vague, « ce projet a-t-il besoin d’être mis à jour », en une liste précise, dépendance par dépendance, avec trois repères chiffrés qui permettent de distinguer un rattrapage sans risque d’une montée de version majeure qui demandera du temps et des tests. C’est la première commande à relancer avant toute reprise d’un projet front laissé sans surveillance, bien avant d’envisager le moindre changement de code.