si j'ai un npm 7 workspace comme ceci:
npm i somepackage --scope submodule0
et je navigue vers le répertoire Submodule0 et exécute npm i somepackage Il semble "casser" l'espace de travail en créant un nouveau package-lock.json dans le répertoire Submodule0 et Installation de toutes les dépendances là-bas. En d'autres termes, il fait juste l'ancien comportement qui existait avant de créer l'espace de travail.
J'espérais une commande similaire à Lerna où je peux installer un nouveau Package dans Submodule0 à partir de la root . Quelque chose comme:
root - submodule0 - submodule1 - submodule2
Jusqu'à présent, la seule solution de contournement que je peux trouver est de modifier le package Submodule0.json et d'ajouter le SomePackage manuellement. Ensuite, exécutez npm i à partir de la racine. De toute évidence, ce n'est pas idéal car je dois rechercher la version @latest, accéder au sous-répertoire, ouvrir le package.json, etc. etc. au lieu de taper une ligne dans la racine.
6 Réponses :
Je suis également déconcerté par les raisons pour lesquelles NPM Workspaces a été publiée sans cette fonctionnalité.
Ma solution de contournement actuelle utilise le package d'add-dépendances , qui ajoute des dépendances à un fichier package.json déclaré, tout en sautant le processus d'installation.
npx add-dependencies ./submodule0/package.json somepackage && npm i
Ensuite, du niveau supérieur du monorepo, vous pouvez exécuter:
npm i add-dependencies -g
J'espère qu'un - un argument de travail sera bientôt ajouté à npm i Pour éviter ce FAFF.
C'est une suggestion vraiment utile. Je pense que je pourrais peut-être le faire tomber à un script NPM dans la racine en utilisant cela (bien que je devrais peut-être utiliser JS pour le rendre agnostique). Si je fais cela, je reviendrai et inclurai cela ici.
u peut l'utiliser pour installer le package uniquement dans package.json (vous n'avez pas besoin de dépendances externes)
npm run wsi [workspace name] [dependency name to install] npm run wsi @workspace/test express npm run wsi @workspace/test express --save-prod npm run wsi @workspace/test @types/express --save-dev
suivis par npm i Pour installer la dépendance spécifiée dans le référentiel mono node_modules
peut également utiliser Lerna Pour utiliser le nom de l'espace de travail pour installer la dépendance dans
package.json
{
"version": "1.0.0",
"npmClient": "npm",
"packages": ["packages/**"]
}
Veuillez vous référer à la réponse de Mattwad ci-dessus si vous avez NPM V7.14.0 ou au-dessus
Réponse originale
Je n'étais pas très satisfait des suggestions, mais Les combinés tous pour l'utiliser dans un script NPM sans aucune dépendance:
{
"add": "npm install --package-lock-only --no-package-lock --prefix",
"postadd": "npm install"
}
Ceci peut être utilisé comme suivant: npm run add - submodule0 somepackage
Dans mon cas, qui est similaire au vôtre, j'ai supprimé toutes les dépendances de tous les projets intérieurs, supprimé également le package-block.json et installé tout dans la racine.
/
node_modules
package.json >> all dependencies
package-lock.json >> the only lock file that exists in the repo
/packages
/A
package.json >> no dependencies
-- no package-lock.json
/B
package.json >> no dependencies
-- no package-lock.json
/C
package.json >> no dependencies
-- no package-lock.json
De cette façon, le dossier Node_Modules réside uniquement sur la racine, et le fichier package-lock.json est également dans la racine.
Si j'ai autorisé à avoir chaque projet son propre package-lock.json j'ai commencé à voir Erreurs d'installation et d'exécution (car chaque projet pourrait avoir son propre Node_Modules et sa propre version d'une dépendance).
C'est la meilleure façon que je vois.
Cela vous dérange si je demande ce que vous utilisez des espaces de travail si vous faites cela? Ce que vous avez suggéré fonctionnera, mais à moins que j'aie manqué quelque chose, cela me semble que cela traitait les espaces de travail comme des espaces de travail?
Bien sûr, C est un package commun où j'ai toutes mes classes de service, tandis que A et B sont des API qui ont la configuration du routeur de terminaison KOA qui réutilise les services écrits en C. avant, je devais republier C à chaque fois au NPM privé à installer A et B. Maintenant, je peux référer C sans aucune installation.
Après avoir essayé d'utiliser le npm install avec le - Prefix --Save --Package-Lock-Only - No-Package-Lock Options, NPM Toujours Donnez l'erreur e404 - non trouvé pour mes propres packages du monorepo qui ne sont pas encore publiés dans un registre. Ainsi, même lorsque vous essayez d'installer des packages externes, il échoue en raison de mes dépendances actuelles dans le package.json.
Pour contourner ce problème, je me suis retrouvé avec un mélange des suggestions précédentes:
npm run add --scope=packages/app express npm run add --scope=packages/core eslint jest -D
Ce serait mieux si vous pouviez ajouter une explication de comment et pourquoi cela fonctionne, tandis que d'autres ne l'ont pas fait.
La prise en charge de l'espace de travail pour npm install et npm Uninstall a été ajoutée dans NPM v7.14.0. Vous pouvez maintenant faire:
npm i somepackage --workspace=submodule0
Les modules de désinstallation ont été la plus grande douleur, donc c'est vraiment excitant. L'équipe NPM semble ajouter lentement le support aux commandes une par une. Suivez les mises à jour ici: https://github.com/npm/cli/blob/latest /Changelog.md .
J'ai la même question
Avez-vous essayé d'aller à la racine de l'espace de travail et de faire la mise à jour NPM?