lrvo-update

lrvo-update met à jour @lrvo/core et tous les modules LRVO du projet en une seule commande, affiche ce qui change, puis enchaîne la synchronisation des manifestes, les migrations de base et le diagnostic.

npx lrvo-update

Commandes et options

Ce que fait la commande

1. Lit le package.json du projet, repère @lrvo/core et tout package marqué lrvo-module.
2. Interroge le registre pour les versions publiées.
3. Choisit d'abord la version cible du core, puis pour chaque module la version la plus haute dont la peerDependency sur @lrvo/core est satisfaite par ce core.
4. Affiche le tableau des montées, puis ce que le registre annonce de chacune : rupture, variable d'environnement ajoutée, gabarit modifié, action à lancer ensuite.
5. Installe tout en un seul npm install.
6. Relit les changelog.json fraîchement posés et affiche le détail exact des versions franchies.
7. Enchaîne npx lrvo-modules sync, npx lrvo-db migrate, npx lrvo-doctor.

L'ordre de résolution du point 3 est ce qui distingue cette commande d'un npm update. Prendre la dernière version de chaque module puis espérer produit exactement le ERESOLVE que la commande existe pour éviter.

Le rapport, avant et après

Deux sources d'information, pour deux moments.

Avant l'installation, la commande lit le champ lrvo du packument, avec un seul appel au registre. Ce champ porte un résumé : y a-t-il une rupture, quelles variables d'environnement bougent, quelles commandes lancer après. Il est écrit à la publication par npm run build:changelog.

Après l'installation, elle lit node_modules/<package>/changelog.json, qui porte le détail complet, hors ligne. C'est là que se trouve la liste exacte des entrées de chaque version franchie.

Une version publiée avant l'introduction de ces fichiers ne porte ni l'un ni l'autre. La commande le signale et met quand même à jour.

Le rappel au démarrage

npm run dev affiche au plus une ligne quand une mise à jour existe :

    · core 1.0.56 → 1.0.61 · npx lrvo-update

Ce rappel est greffé sur lrvo-modules sync, qui tourne déjà en postinstall, en dev et au build. Un projet existant en bénéficie donc sans modifier son package.json.

Il ne retarde jamais un démarrage : il affiche le résultat du contrôle précédent, mis en cache 24 heures dans app/.lrvo/update-check.json, et rafraîchit ce cache dans un processus détaché.

Il se tait dans trois cas : hors terminal interactif, quand CI est définie, et quand LRVO_UPDATE_CHECK=false.

Le cache

--write-cache est le mode qui alimente ce fichier. Il est appelé par le rappel de démarrage, en processus détaché : il écrit et se tait, et son code de sortie n'intéresse personne.

--check écrit les mêmes clés sauf summaries, qui coûte un appel au registre par cible et n'a aucune utilité pour un code de sortie en intégration continue.

L'écriture est volontairement silencieuse : un cache qui ne peut pas être écrit ne doit pas faire échouer la commande qui l'a déclenché. C'est aussi ce qui rend le mode utilisable sur un système de fichiers en lecture seule, où le contrôle aboutit sans laisser de trace.

Le cache et la tuile du tableau de bord

Ce cache n'est pas la source de la tuile « mise à jour » de l'admin. Les trois gardes de shouldNotify incluent process.stdout.isTTY, or un serveur Next ne tourne jamais dans un terminal : depuis l'application, le fichier n'est jamais rafraîchi. S'y fier en production reviendrait à afficher éternellement l'état du dernier build.

La tuile interroge donc le registre en direct, avec son propre cache de 6 heures assuré par le Data Cache de Next, et ne retombe sur app/.lrvo/update-check.json que si l'appel échoue ou si aucun token n'est trouvé. Les deux caches coexistent sans se croiser : 24 heures et sur disque pour la CLI, 6 heures et par processus de rendu pour la tuile. Voir features/admin.

La tuile ne calcule jamais de plan complet : les contraintes de pairs et les modules retenus demandent des dizaines d'appels npm view, qui restent le travail de cette commande.

En intégration continue

npx lrvo-update --check

Aucune écriture, aucune question, code 1 s'il y a du retard. À coupler avec npx lrvo-db status, qui sort en 1 s'il reste des migrations en attente.

Notes

L'installation n'est jamais partielle. Tout part dans un seul npm install : un conflit de peerDependency se manifeste avant que quoi que ce soit ait bougé.

Un module incompatible est laissé en place, pas installé de force. La commande dit lequel, quelle version de core il exige, et poursuit avec le reste.

Après l'installation, un échec n'annule rien. Si une des étapes enchaînées échoue, les paquets sont déjà installés : la commande nomme l'étape à reprendre à la main plutôt que de laisser croire à un retour en arrière.

Le jeton du registre doit être valide. Un refus du registre produit le remède exact, npm login puis lrvo-key.

Les lectures du registre ne passent par aucun shell. npm view et npm outdated reçoivent des noms de paquets lus dans le package.json du projet : les lancer sans shell écarte toute interprétation de ces noms. Sous Windows, où npm est un script npm.cmd que Node ne lance pas sans shell, la commande exécute directement le npm-cli.js de l'installation de Node. Elle le cherche à côté de npm_execpath, que npx et npm run renseignent, puis à côté de node.exe.