bcoe / bcoe/optional-dev-dependency
Native optional devDependencies trick with npm workspaces
- Langage dominant
- JavaScript
- Étoiles
- 5
- Forks
- 8
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
Since `npm install` automatically uses your `package.json`'s `workspaces: [ ... ]` value to install all workspaces at once, you can take advantage of this with a subfolder that has a `package.json` like:
```jsonc
// optionalDevDependencies/package.json
{
"optionalDependencies": {
"my-optional-dev-dependency": "^1.2.3"
}
}
```
and then the root package.json like:
```jsonc
{
"name": "my-awesome-package-with-optional-dev-dependencies",
"version": "4.5.6",
"optionalDependencies": {
"my-optional-production-dependency": "^10.11.12"
},
"devDependencies": {
"my-required-dev-dependency": "^7.8.9"
}
"workspaces": ["optionalDevDependencies"]
}
```
That way when you run `npm install` it will install the stuff from `./optionalDevDependencies/package.json`'s `optionalDependencies`, BUT when you `npm publish` it the workspace gets completely ignored and the only things left in the manifest are the required devDependencies and the production optionalDependencies.
I think this is a pretty cool trick! I used it to add all the esbuild targets as optional devDependency items for some testing of raw esbuild binary stuff. I needed some optional devDependency items so that npm would choose the right package for the os/cpu combo
```jsonc
// optionalDevDependencies/package.json
{
"optionalDependencies": {
"@esbuild/aix-ppc64": "0.19.11",
"@esbuild/android-arm": "0.19.11",
"@esbuild/android-arm64": "0.19.11",
"@esbuild/android-x64": "0.19.11",
"@esbuild/darwin-arm64": "0.19.11",
"@esbuild/darwin-x64": "0.19.11",
"@esbuild/freebsd-arm64": "0.19.11",
"@esbuild/freebsd-x64": "0.19.11",
"@esbuild/linux-arm": "0.19.11",
"@esbuild/linux-arm64": "0.19.11",
"@esbuild/linux-ia32": "0.19.11",
"@esbuild/linux-loong64": "0.19.11",
"@esbuild/linux-mips64el": "0.19.11",
"@esbuild/linux-ppc64": "0.19.11",
"@esbuild/linux-riscv64": "0.19.11",
"@esbuild/linux-s390x": "0.19.11",
"@esbuild/linux-x64": "0.19.11",
"@esbuild/netbsd-x64": "0.19.11",
"@esbuild/openbsd-x64": "0.19.11",
"@esbuild/sunos-x64": "0.19.11",
"@esbuild/win32-arm64": "0.19.11",
"@esbuild/win32-ia32": "0.19.11",
"@esbuild/win32-x64": "0.19.11"
}
}
```
This isn't really an issue. This is me trying to share this trick that I found that I thought was cool with anyone else who comes across the https://www.npmjs.com/package/optional-dev-dependency package (which is deprecated) or this github repository looking for a way to do optional dev dependencies. 😊
Feel free to close this if this is the wrong place for such stuff. ❤️
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Piste de recherche
Commencez par les exemples de root package.json et de optionalDevDependencies/package.json, puis examinez le comportement décrit de npm install et npm publish si les maintainers décident de documenter l’astuce. Pour considérer le travail comme terminé, il faudrait une demande explicite de documentation ou de code ; ce rapport n’en fournit actuellement aucune des deux.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- javascript, node.js
- Domaine
- tooling
- Type d'issue
- Documentation
- Difficulté
- 1/5
- Temps estimé
- Moins d'une heure
- Activité
- À l'abandon
- Clarté
- À clarifier
- Accessibilité débutants
- 15/100