Mettre à jour une dépendance avec votre assistant, le changelog d'abord

Un assistant sait monter une version et corriger les erreurs de type en une minute. Ce qu'il ne sait pas faire seul, c'est savoir ce qui a changé entre votre version et la suivante : le changement cassant décrit seulement dans un guide de migration, l'option renommée dans une version mineure, l'avis de sécurité que la mise à jour corrige ou laisse ouvert. inlinr lit une fois chaque note de version d'un paquet, et votre assistant part de là plutôt que de ses données d'entraînement.

Lire d'abord ce qui change

Entre deux versions majeures d'un paquet répandu, il y a souvent des dizaines de versions, et les notes qui comptent sont dispersées entre elles. Certains changements cassants figurent dans un guide plutôt que dans une note ; certaines versions n'ont pas de note du tout. Un assistant qui met à jour de mémoire corrige ce que signale le compilateur et manque ce qui a changé de comportement sans changer de type.

L'ordre est donc : ce qui change, puis où votre code utilise le paquet, puis la mise à jour, puis vos vérifications.

La page de mise à jour

Chaque page de paquet npm sur inlinr a un onglet Upgrade, avec une page publique par mise à jour à l'adresse /packages/<nom>/upgrade/<de>-<vers>. Elle rassemble, depuis chaque version intermédiaire, les changements cassants et les dépréciations en une seule liste à cocher, les guides de migration, les avis de sécurité que la mise à jour corrige et ceux qui restent, et ce que la version visée demande à votre projet : ses dépendances pairs, sa version de Node, son format de module. Quand des notes manquent, les décomptes le disent au lieu d'afficher zéro.

Sa colonne de côté copie la commande d'installation pour votre gestionnaire de paquets et un prompt pour un assistant construit à partir de tout cela, à coller dans celui de votre choix.

Dans Claude Code : /inlinr:upgrade

Avec le plugin inlinr pour Claude Code installé, une commande enchaîne toute la séquence :

/inlinr:upgrade next 16.0.0

Claude trouve les package.json qui déclarent le paquet et la version installée, lit ce qui change jusqu'à la version que vous nommez (la dernière si vous n'en nommez pas), et lit les guides de migration. Pour une mise à jour majeure, il vous dit ce qu'il a trouvé et attend votre accord. Il trouve ensuite où votre code importe le paquet, le met à jour avec votre gestionnaire de paquets, modifie ce que touchent les changements cassants, et lance votre vérification de types, votre linter, vos tests et votre build. Seuls le nom du paquet et les deux versions quittent votre machine ; aucun compte n'est nécessaire.

Avec n'importe quel assistant : le serveur MCP

La CLI inlinr contient un serveur MCP, inlinr mcp, que Claude Code, Codex, Cursor ou tout client MCP peut utiliser. Trois de ses outils servent à une mise à jour : upgrade_notes lit ce qui change entre deux versions, find_usages cherche les imports du paquet dans votre code sans rien envoyer, et my_upgrades liste les mises à jour de vos projets suivis, correctifs de sécurité en tête. Demandez à l'assistant de mettre à jour un paquet, et il les appelle dans cet ordre. L'installation est sur la page de l'intégration MCP.

Ce que fait inlinr

Dependafeed suit les dépendances npm des projets que vous choisissez : leurs versions, leurs dépréciations et leurs avis de sécurité, et un onglet Upgrades qui classe ce qu'il y a à faire sur l'ensemble. Trois projets suivis sont gratuits. Un dépôt public sur GitHub est lu sur sa branche par défaut ; un dépôt privé, ou hébergé ailleurs, envoie ses manifestes par inlinr sync-deps, et seulement pour un projet où vous l'avez activé.

Sources

• La commande de mise à jour, dans le plugin inlinr pour Claude Code : chaque étape que suit Claude. Consulté le 29 octobre 2026.
• La CLI inlinr, son README : inlinr mcp et ses outils, inlinr sync-deps. Consulté le 29 octobre 2026.
• Gestion sémantique de version 2.0.0 : ce que promettent une version majeure, mineure et de correctif. Consulté le 29 octobre 2026.