Mettre à jour un projet

Monter @lrvo/core, les modules et les paquets tiers d'un projet existant, et vérifier que rien n'a dérivé.

Cette page couvre la mise à jour d'un projet déjà en service. Pour une installation neuve, voir Installation.

En une commande

npx lrvo-update

Elle repère @lrvo/core et les modules installés, résout un jeu de versions compatibles entre elles, affiche ce qui change, installe, puis enchaîne :

npx lrvo-modules sync    # régénère les manifestes
npx lrvo-db migrate      # applique les migrations en attente
npx lrvo-doctor          # vérifie que rien n'a dérivé

C'est tout. Le reste de cette page explique ce qui se passe, et quoi faire quand quelque chose accroche.

Ce que la commande vous dit

Avant d'installer, elle affiche le tableau des montées et ce que le registre annonce de chacune : rupture, variable d'environnement ajoutée ou retirée, fichier de gabarit modifié, commande à lancer après.

Après avoir installé, elle lit les notes de version livrées dans les paquets et affiche le détail exact des versions franchies. Ces notes vivent dans node_modules/<package>/changelog.json, donc hors ligne, sans accès aux dépôts.

Les trois choses qui dérivent avec le temps

Le .env

Il est copié une seule fois, à la génération du projet. Une variable ajoutée par une version ultérieure du core, ou par un module installé après coup, n'y arrive jamais.

npx lrvo-doctor        # liste ce qui manque
npx lrvo-doctor --fix  # les ajoute, commentées, en fin de fichier

--fix n'écrit que des lignes commentées : il ne peut pas changer le comportement du projet. Il ne modifie aucune valeur existante et ne supprime aucune ligne. Reste à décommenter et à renseigner ce qui concerne le projet.

Les fichiers d'amorçage

Le projet porte une dizaine de fichiers qui ne sont que des réexports du core, comme app/lrvo/api/[...path]/route.js. Ils sont écrits une fois à la génération, et une évolution du core peut les rendre obsolètes.

lrvo-doctor les compare au contrat que le core déclare. --fix réécrit ceux qui sont absents ou restés à une version antérieure, et laisse intact tout fichier au contenu qu'il ne reconnaît pas : si vous l'avez modifié, il est à vous.

instrumentation.js et app/layout.js ne sont jamais réécrits. Ils mêlent contrat d'amorçage et code du projet. Le doctor dit quelles lignes manquent, la correction est manuelle.

Exemple concret, depuis @lrvo/core 1.0.70 : app/lrvo/[...path]/page.js a gagné une ligne d'import du manifeste des pages publiques. Un projet resté au réexport d'une ligne est remonté automatiquement par --fix. Sans cette mise à jour, toute page publique de module qui rend un composant client échoue sur « Could not find the module … in the React Client Manifest ».

Quand un fichier ainsi réécrit référence un manifeste de app/.lrvo/ encore absent, le doctor le signale : enchaîne avec npx lrvo-modules sync.

Le schéma de base

npx lrvo-db status     # appliquées, adoptées, en attente
npx lrvo-db migrate    # applique ce qui manque

Sur une base initialisée avant l'arrivée des migrations, la première exécution pose une ligne de base et ne rejoue rien. Aucune donnée ne bouge. Voir Écrire une migration.

Les paquets tiers

next, react, sharp ne se montent pas à la dernière version disponible mais à la dernière que LRVO supporte.

npx lrvo-update --deps

Les bornes sont publiées par le core, voir Paquets supportés. Un projet sous le plancher est signalé comme bloquant par lrvo-doctor.

Pour les alertes de sécurité, le doctor remonte chaque vulnérabilité jusqu'au paquet de premier niveau qui la tire et propose la montée plutôt qu'un overrides. Un overrides fige une version pour rien quand un correctif amont existe.

En intégration continue

npx lrvo-update --check   # code 1 s'il y a du retard
npx lrvo-doctor           # code 1 si un constat est bloquant
npx lrvo-db status        # code 1 s'il reste des migrations en attente

Aucune de ces trois commandes n'écrit quoi que ce soit.

Sur un serveur de déploiement, la séquence utile après un npm ci est npx lrvo-db migrate seul : le schéma est mis à niveau sans repasser par la création de tables.

Savoir qu'il y a quelque chose à faire

Le rappel au démarrage. Il n'installe rien. npm run dev affiche au plus une ligne quand une mise à jour existe. Il ne retarde jamais le démarrage : il montre le résultat du contrôle précédent et rafraîchit en arrière-plan.

Pour l'éteindre, poser LRVO_UPDATE_CHECK=false dans le .env. Il est déjà muet hors terminal interactif et en intégration continue.

Pour un état complet à la demande, npx lrvo-update liste les montées disponibles et npx lrvo-doctor rapporte les constats du projet. Voir lrvo-update et lrvo-doctor.

Diagnostiquer

SymptômeCause probable
ERESOLVE sur un npm i @lrvo/module-XLe module exige un core plus récent. Passer par npx lrvo-update, qui résout le jeu complet.
Un module n'apparaît plus dans l'adminManifeste périmé. npx lrvo-modules sync.
LRVO: <module> exige @lrvo/core >= X au démarrageCore trop ancien pour un module installé. npx lrvo-update.
Une colonne attendue n'existe pas en baseMigration non appliquée. npx lrvo-db status.
Le registre refuse la requêteJeton absent ou expiré. npm login --registry=https://registry.lrvo.app/ puis npx lrvo-key.

Sur cette page