Ajouter @lightweight-sdk/service-registry (packages/common) #2
4 changed files with 30 additions and 0 deletions
|
|
@ -19,5 +19,10 @@
|
||||||
"src/index.ts"
|
"src/index.ts"
|
||||||
],
|
],
|
||||||
"readme": "README.md"
|
"readme": "README.md"
|
||||||
|
},
|
||||||
|
"devDependencies": {
|
||||||
|
"@types/node": "catalog:",
|
||||||
|
"typescript": "catalog:",
|
||||||
|
"vitest": "catalog:"
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
|
||||||
|
|
@ -211,6 +211,18 @@ importers:
|
||||||
|
|
||||||
packages/client/web-component: {}
|
packages/client/web-component: {}
|
||||||
|
|
||||||
|
packages/common/service-registry:
|
||||||
|
devDependencies:
|
||||||
|
'@types/node':
|
||||||
|
specifier: 'catalog:'
|
||||||
|
version: 22.20.3
|
||||||
|
typescript:
|
||||||
|
specifier: 'catalog:'
|
||||||
|
version: 5.9.3
|
||||||
|
vitest:
|
||||||
|
specifier: 'catalog:'
|
||||||
|
version: 2.1.9(@types/node@22.20.3)
|
||||||
|
|
||||||
packages:
|
packages:
|
||||||
|
|
||||||
'@babel/runtime@7.29.7':
|
'@babel/runtime@7.29.7':
|
||||||
|
|
|
||||||
|
|
@ -53,6 +53,15 @@ const packageJson = {
|
||||||
entryPoints: ['src/index.ts'],
|
entryPoints: ['src/index.ts'],
|
||||||
readme: 'README.md',
|
readme: 'README.md',
|
||||||
},
|
},
|
||||||
|
// Déclarées explicitement (même si déjà présentes à la racine, où elles
|
||||||
|
// seraient hoistées) : un package workspace sans aucune dépendance propre
|
||||||
|
// peut se retrouver sans entrée dans pnpm-lock.yaml, ce qui casse
|
||||||
|
// `pnpm install --frozen-lockfile` en CI (voir spec/ci-cd.md).
|
||||||
|
devDependencies: {
|
||||||
|
'@types/node': 'catalog:',
|
||||||
|
typescript: 'catalog:',
|
||||||
|
vitest: 'catalog:',
|
||||||
|
},
|
||||||
};
|
};
|
||||||
writeFileSync(join(packageDir, 'package.json'), `${JSON.stringify(packageJson, null, '\t')}\n`);
|
writeFileSync(join(packageDir, 'package.json'), `${JSON.stringify(packageJson, null, '\t')}\n`);
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -35,6 +35,10 @@ Pas de bot automatique type `changesets/action` (spécifique GitHub, incertain s
|
||||||
1. Forgejo → Settings → Applications → générer un token avec les scopes `write:package` + `read:package`.
|
1. Forgejo → Settings → Applications → générer un token avec les scopes `write:package` + `read:package`.
|
||||||
2. L'ajouter comme secret de repo nommé `REGISTRY_TOKEN` sur **ce** repo (`lightweight-sdk`) — les secrets de repo ne sont pas partagés entre repos sur cette instance ; celui de `watchparty` ne peut pas être réutilisé tel quel.
|
2. L'ajouter comme secret de repo nommé `REGISTRY_TOKEN` sur **ce** repo (`lightweight-sdk`) — les secrets de repo ne sont pas partagés entre repos sur cette instance ; celui de `watchparty` ne peut pas être réutilisé tel quel.
|
||||||
|
|
||||||
|
### Troubleshooting : `pnpm-lock.yaml` sans entrée pour un nouveau package
|
||||||
|
|
||||||
|
Si `pnpm install --frozen-lockfile` échoue en CI avec `pnpm-lock.yaml has no importers["packages/<catégorie>/<nom>"] entry` alors que `pnpm install` (sans `--frozen-lockfile`) fonctionne en local sans se plaindre : un package workspace **sans aucune `dependencies`/`devDependencies` propre** peut ne pas obtenir d'entrée dans le lockfile généré par pnpm 12.4.2, même après suppression complète du lockfile et réinstallation. Constaté en ajoutant `@lightweight-sdk/service-registry` (package.json sans champ de dépendances du tout). Remède : déclarer explicitement quelques `devDependencies` (ex. `typescript`, `vitest` via `catalog:`) même si elles seraient de toute façon hoistées depuis la racine — `create-package.mjs` le fait automatiquement pour tout nouveau package. Vérifier avant de pousser : `pnpm install --frozen-lockfile` en local doit passer, pas seulement `pnpm install`.
|
||||||
|
|
||||||
### Troubleshooting : 404 sur un package scopé
|
### Troubleshooting : 404 sur un package scopé
|
||||||
|
|
||||||
Si `pnpm changeset:publish` échoue avec une 404 sur un nom de package scopé (`@lightweight-sdk/...`), la cause probable est le reverse proxy devant l'instance : npm encode le `/` d'un nom scopé en `%2F`, ce qu'Apache refuse par défaut. Vérifier `AllowEncodedSlashes NoDecode` dans le VirtualHost et `nocanon` sur la directive `ProxyPass`. Ce point n'a pas pu être vérifié depuis l'agent (config réseau propre à l'instance).
|
Si `pnpm changeset:publish` échoue avec une 404 sur un nom de package scopé (`@lightweight-sdk/...`), la cause probable est le reverse proxy devant l'instance : npm encode le `/` d'un nom scopé en `%2F`, ce qu'Apache refuse par défaut. Vérifier `AllowEncodedSlashes NoDecode` dans le VirtualHost et `nocanon` sur la directive `ProxyPass`. Ce point n'a pas pu être vérifié depuis l'agent (config réseau propre à l'instance).
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue