0.1.1-alpha.2

This commit is contained in:
2026-09-27 10:18:43 +02:00
parent 7b7565d5d4
commit dc63b543ac
13 changed files with 691 additions and 11 deletions

View File

@@ -0,0 +1,46 @@
<!-- file: docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md -->
<!-- version: 1 -->
# Profil écosystème de packages JavaScript
## Rôle et applicabilité
Ce profil possède le contrat réutilisable d'un package JavaScript/TypeScript utilisant un manifest `package.json` et un package manager compatible avec cet écosystème.
Il complète [`500-LANGUAGES.md`](500-LANGUAGES.md) et reste indépendant du choix entre JavaScript et TypeScript, du bundler, du framework frontend, de Sass et du host.
## Package manager
PGR MUST NOT imposer npm uniquement parce qu'il est utilisé par un corpus source.
Le projet MUST sélectionner explicitement le package manager qu'il utilise lorsque plusieurs outils sont possibles. npm, pnpm, yarn, Bun ou une autre solution compatible MAY être retenus si le besoin et la toolchain du projet le justifient.
Les commandes opérateur et CI doivent utiliser le package manager réellement sélectionné par le projet ; un exemple PGR ne doit pas transformer sa propre syntaxe en obligation universelle.
## Manifest et scripts
`package.json` appartient à cet owner lorsqu'il décrit le package frontend ou JavaScript/TypeScript concerné.
Les scripts du manifest doivent représenter des responsabilités utiles du package. Un script MAY orchestrer plusieurs outils, mais sa présence ne transfère pas l'ownership de TypeScript, Vite, Sass, WASM ou Tauri vers le package manager.
Les champs de version restent classifiés selon la gouvernance PGR et le rôle du package ; un package privé appartenant au même release train et un package publié indépendamment n'ont pas nécessairement la même politique.
## Dépendances et sorties téléchargées
Les dépendances téléchargées telles que `node_modules/` sont des artefacts reproductibles et SHOULD rester hors du source control.
Un package tiers peut exposer des entrypoints JavaScript, CSS, Sass ou d'autres assets. Leur utilisation active les owners correspondants selon le besoin réel du projet ; elle ne fait pas du package manager le propriétaire de leur configuration.
## Lockfile
La politique du lockfile MUST être explicitement décidée selon le rôle du package, la reproductibilité recherchée, les contraintes de publication et le package manager sélectionné.
`0.1.1-alpha.2` fixe cette responsabilité mais ne choisit pas encore une règle universelle de versionnement/ignorance. La politique détaillée est traitée par `alpha.3`.
L'absence de lockfile dans Games reste donc une décision locale à classifier, pas une règle PGR générale.
## Validation
Le parsing du manifest, l'installation/résolution de dépendances et les scripts du package manager sont des preuves distinctes. Leur sélection reste proportionnée au scope conformément à [`400-VALIDATION.md`](400-VALIDATION.md).
`alpha.3` précisera les artefacts/templates et la gate générique sans imposer un package manager particulier.