Publication

@fraza/core est publié sur le registre npm https://registry.fraza.ca/. Sa lecture est libre, sa publication demande un compte. Le dépôt source est hébergé sur Gitea, en dépôt privé.

Authentification, une seule foisCopier le lien de la section

npm config set "@fraza:registry" https://registry.fraza.ca/
npm config set "@fraza-pro:registry" https://registry.fraza.ca/
npm login --registry=https://registry.fraza.ca/

La connexion reste obligatoire pour publier, sur les deux scopes.

ChecklistCopier le lien de la section

• 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 @fraza/start : npm run check:contract passe, templates/ suit le contrat déclaré par le core.
• Pour un module Fraza Pro, toute contribution extérieure à HYKO est couverte par une cession de droits écrite.
• 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é.

VersionnerCopier le lien de la section

On suit semver. Tant que l'API peut encore changer, les paquets restent en 0.x, et semver y décale les niveaux d'un cran : c'est la version mineure qui signale un changement cassant.

À partir de 1.0.0, la règle redevient la règle habituelle : patch pour une correction, minor pour une fonctionnalité rétrocompatible, major pour un changement cassant.

npm version patch   # ou minor

Le retrait d'un sous-chemin de package.json#exports, le renommage d'un export, et tout changement de signature sont des changements cassants : un projet consommateur casse au build. En 0.x, ils montent la version mineure.

Les modules déclarent le core dans peerDependencies avec une plage bornée à la mineure, par exemple ">=0.3.0 <0.4.0" : npm ne laisse ainsi pas un core cassant s'installer sous un module qui ne le connaît pas.

PublierCopier le lien de la section

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éCopier le lien de la section

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, donc cassante en 0.x, demande de passer par npm version explicitement.

Modules externesCopier le lien de la section

Un @fraza/module-* suit la même procédure et le même registre. Un module Pro aussi, sous le scope @fraza-pro : son nom est @fraza-pro/module-*, et son publishConfig.registry pointe déjà vers le registre. 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 registreCopier le lien de la section

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