Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.1.1-alpha.3

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-27 10:56:05 +02:00
parent e351f57be4
commit 5033547534
10 changed files with 650 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
docs/rules/530-TYPESCRIPT.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/530-TYPESCRIPT.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Profil TypeScript
@@ -31,9 +31,40 @@ Cette recommandation ne transforme pas TS-RS en dépendance générale de TypeSc
`tsconfig.json`, les options de compilation/type-check, les fichiers inclus/exclus et la commande TypeScript canonique appartiennent à ce profil.
`0.1.1-alpha.2` fixe uniquement cette frontière d'ownership. Les defaults réutilisables, templates éventuels et gates TypeScript détaillés sont traités par `alpha.3` après validation du présent découpage.
Pour un nouveau package TypeScript contrôlé, la baseline PGR `SHOULD` activer au minimum :
Un build Vite, Tauri ou autre ne remplace pas automatiquement une preuve TypeScript ciblée lorsqu'une propriété de typage doit être validée indépendamment.
```text
strict = true
noEmit = true
```
`strict` exprime la volonté d'utiliser le contrôle de types renforcé de TypeScript. `noEmit` sépare le type-check de la production des artefacts JavaScript lorsque cette production appartient à un bundler ou à un autre outil.
Pour une baseline stricte, PGR `SHOULD` également activer les contrôles simples suivants sauf incompatibilité documentée :
```text
noUnusedLocals = true
noUnusedParameters = true
noFallthroughCasesInSwitch = true
```
Les choix `target`, `module`, `moduleResolution`, `lib`, `types`, `jsx`, chemins/aliases, `include` et `exclude` dépendent du runtime, du bundler, du framework et du layout réel. PGR MUST NOT les figer dans le profil TypeScript générique uniquement parce qu'ils apparaissent dans Games.
Le package `SHOULD` exposer une validation TypeScript indépendante sous un script canonique :
```text
typecheck
```
Lorsque le compilateur local est installé dans le package, le pattern recommandé est :
```text
tsc --noEmit
```
Un build Vite, Tauri ou autre ne remplace pas automatiquement cette preuve ciblée lorsqu'une propriété de typage doit être validée indépendamment.
Le modèle minimal [`../../templates/web-typescript/tsconfig.json`](../../templates/web-typescript/tsconfig.json) active uniquement les options génériques ci-dessus. Le guide [`../templates/008-WEB_TYPESCRIPT_PACKAGE.md`](../templates/008-WEB_TYPESCRIPT_PACKAGE.md) liste les décisions à compléter avant adoption réelle.
## Ce que le profil n'impose pas

26
docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Profil écosystème de packages JavaScript
@@ -21,8 +21,14 @@ Les commandes opérateur et CI doivent utiliser le package manager réellement s
`package.json` appartient à cet owner lorsqu'il décrit le package frontend ou JavaScript/TypeScript concerné.
Pour une application locale/non publiée, `private: true` **SHOULD** être utilisé afin d'exprimer explicitement que le package n'est pas destiné à être publié par erreur. Un package destiné à un registry doit au contraire définir les métadonnées et versions nécessaires à sa publication réelle.
Le projet MUST sélectionner explicitement son package manager. Cette sélection peut être rendue machine-readable dans le manifest lorsque la toolchain retenue le permet, ou être possédée par la configuration/CI/documentation locale. PGR ne fixe ni le nom ni la version du package manager dans son template générique.
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.
Pour un package TypeScript, le nom `typecheck` **SHOULD** désigner la vérification TypeScript indépendante. `dev`, `build` et `preview` restent disponibles pour les owners qui possèdent réellement ces comportements ; leur simple présence dans un exemple ne les rend pas obligatoires.
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
@@ -35,12 +41,22 @@ Un package tiers peut exposer des entrypoints JavaScript, CSS, Sass ou d'autres
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`.
Pour une application privée, un frontend déployable ou un outil livré comme unité exécutable, le lockfile produit par le package manager sélectionné **SHOULD** être versionné afin de conserver l'arbre effectivement résolu entre développeurs, CI et livraisons.
L'absence de lockfile dans Games reste donc une décision locale à classifier, pas une règle PGR générale.
Pour une bibliothèque publiée, un lockfile **MAY** être versionné afin de stabiliser l'environnement de développement et de CI. Il ne remplace toutefois pas les contraintes du manifest qui pilotent la résolution chez les consommateurs.
Un exemple, un template ou une fixture qui ne résout aucune dépendance réelle **MAY** ne pas embarquer de lockfile.
Un package **SHOULD NOT** conserver simultanément plusieurs lockfiles concurrents (`package-lock.json`, `pnpm-lock.yaml`, `yarn.lock` ou équivalent), sauf migration explicitement temporaire entre package managers.
Lorsqu'un lockfile est versionné, la CI **SHOULD** utiliser le mode de résolution gelé, immutable ou clean-install fourni par le package manager sélectionné. Le nom exact de cette commande reste local à l'outil ; PGR MUST NOT transformer `npm ci` en commande universelle.
L'absence actuelle de lockfiles dans Games reste historique. Lors de l'adoption `0.1.5`, chaque package concerné devra soit `ADOPT` cette recommandation, soit documenter un `OVERRIDE` si une autre politique reste préférable.
## 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).
Le parsing du manifest, l'installation/résolution de dépendances, le respect du lockfile 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.
Une validation statique PGR peut vérifier qu'un `package.json` template est du JSON valide et que les champs génériques attendus sont présents. Elle ne remplace pas l'installation/résolution réalisée par le package manager sélectionné.
Le modèle minimal [`../../templates/web-typescript/package.json`](../../templates/web-typescript/package.json) représente une application TypeScript privée sans choisir de package manager ni de versions de dépendances. Son adaptation est documentée par [`../templates/008-WEB_TYPESCRIPT_PACKAGE.md`](../templates/008-WEB_TYPESCRIPT_PACKAGE.md).