Publication

@lrvo/core est publié sur le registre npm privé https://registry.lrvo.app/. Le dépôt source est hébergé sur Gitea, en dépôt privé.

Authentification, une seule fois

npm config set "@lrvo:registry" https://registry.lrvo.app/
npm login --registry=https://registry.lrvo.app/

Checklist

• npm run audit ne remonte aucune vulnérabilité high ou critical.
• npm run build passe sans erreur ni avertissement.
• La documentation impactée est à jour dans docs/.
• La section docs/06-modules/ décrit la dernière version publiée de chaque module documenté.
• Toute variable d'environnement ajoutée est dans le catalogue src/core/doctor/env.js et dans Variables d'environnement. npm run build le vérifie.
• Tout point d'entrée ajouté est dans package.json#exports et dans Points d'entrée.
• THIRD-PARTY-NOTICES.md est régénéré et commité si les dépendances ont bougé.
• node scripts/sync-version.js --check passe : le module de version suit le package.json.
• Toute évolution de schéma est une migration versionnée, pas un correctif ajouté à createTables().
• Un module dont la version minimale de core change met à jour manifest.requiresCore et son peerDependencies.
• Pour @lrvo/start : npm run check:contract passe, templates/ suit le contrat déclaré par le core.
• Toute contribution extérieure à ACARY est couverte par une cession de droits signée.
• La version est à jour dans package.json.

npm run audit lance npm audit --omit=dev --omit=peer : il ne regarde que ce que le package livre réellement. Un npm audit nu remonte aussi l'outillage de build et les peer dependencies installées localement, qui ne sortent jamais du dépôt. Ne pas publier pour faire taire ces alertes.

Une vulnérabilité se corrige à la racine, pas par un override de confort. Un overrides déclaré ici serait de toute façon ignoré par npm au moment où un site installe le package : il ne vaut que depuis le package.json racine du site. Voir Sécurité.

Versionner

On suit semver.

npm version patch   # ou minor, ou major

Le retrait d'un sous-chemin de package.json#exports, le renommage d'un export, et tout changement de signature sont des changements majeurs : un projet consommateur casse au build.

Publier

npm publish

prepublishOnly lance le build automatiquement. Si le build échoue, la publication est annulée, ce qui empêche de publier un dist/ périmé.

Le build produit aussi dist/docs/, donc la documentation publiée correspond exactement à la version du code. Voir Build et exports.

Script de commodité

Le dépôt expose un script release qui enchaîne la montée de version patch, la réinstallation, le commit, le push et la publication :

npm run release

À n'utiliser que pour un patch. Une version mineure ou majeure demande de passer par npm version explicitement.

Modules externes

Un @lrvo/module-* suit la même procédure et le même registre. Deux points spécifiques :

• Le champ files ne publie que dist, LICENSE et THIRD-PARTY-NOTICES.md — README.md est ajouté par npm quel que soit le champ, et le core y ajoute .env.example. Chaque module porte son propre exemplaire des deux fichiers légaux : voir Licence et propriété.
• Avant publication, vérifier que dist/ ne contient aucune syntaxe JSX brute. Voir Créer un module.
• La documentation d'usage du module vit dans docs/06-modules/ du core, pas dans le dépôt du module. La mettre à jour et la publier avant de publier le module : sinon un projet installe un module dont la documentation décrit la version précédente.
• Mettre à jour la version indiquée en tête de docs/06-modules/<module>/index.md.

Administration du registre

Créer un utilisateur, déprécier une version, gérer les tags ou les droits : voir Registre Verdaccio.