-
Notifications
You must be signed in to change notification settings - Fork 19
npm: recommendation for standalone CLI projects #35
Comments
That is an impractical recommendation, since it requires pruning, and it’s irrelevant since dev deps won’t be installed anyways. It’s not the community’s job to keep things small, it’s npm’s. |
Yeah, I figured it's an unpopular opinion. I think that since npm init -y
npm install -D branch-name-lint it installs more than 500 dependencies that include all dev dependencies that this package uses. (instead of only 70 runtime dependencies). We can argue if this is an npm issue or not, but in practice, having dev dependencies in the shrinkwrap file results in redundant dependencies in your node_modules folder which means it also adds time to your CI/CD pipeline during npm install. |
Ah, right - run |
I remember looking for such a flag when I wanted this behavior, and couldn't find such. AFAIK, if there's a |
Try it. There's also |
Already have. Same result.
|
|
Looks like this is a confirmed bug with the |
Interesting. So maybe we can settle on "best workaround practice" |
Is there any consensus emerging from the discussion? Will the fix in npm/cli#4323 address the concern without the need to update the recommendation? |
I think that a fix to the issue (as they interpret the bug) will only be a partial solution. As long as the shrinkwrap file contains all dev dependencies, it will still depend on npm update adoption by users. I believe that most users will not get the fix, and will still have all dev dependencies installed. |
I think the npm best practices document needs to identify best (workaround) practices, given the mechanisms that currently exist and the limited patience of developers :-). If there's no practical/easy way to do something in a package manager (like npm), or its defaults are "wrong", then I recommend creating a separate little project within this OpenSSF WG to resolve it. Once it's resolved in the tool(s), we can update the guide to match :-). That said: It'd be really helpful if we could clearly state what that problem is, so that a separate little project can work on it. Anyone want to take a crack at it? First attempt (please fix):
|
The recommendation for a standalone CLI project should be that when publishing
npm-shrinkwrap.json
file, it should only contain dependencies and not dev-dependencies.Dev dependencies are best practice for the developer(s) of the CLI, for stability and consistency between environments. However, running
npm shrinkwrap
will only take thepackage-lock.json
file and rename it, resulting in a largenpm-shrinkwrap.json
which contains both dependencies and dev-dependencies. When a consumer installs this CLI it will install all dependencies, and not only those needed for runtime.My recommendation:
package-lock.json
file to the CLI project (never thenpm-shrinkwrap.json
)prepack
script should:npm prune --production
)package-lock.json
filenpm shrinkwrap
pack
will then take the "slim"npm shrinkwrap
postpack
script should revert changes:package-lock.json
npm-shrinkwrap.json
The reason to delete the
package-lock.json
file is thatnpm prune --production
only deletes files from the node_modules folder and does not update thepackage-lock.json
file, and thenpm shrinkwrap
only rename thepackage-lock.json
tonpm-shrinkwrap.json
if it exists. Whenpackage-lock.json
does not exist, thenpm-shrinkwrap.json
file is created from the existing dependencies tree (which after the prune command represents the committedpackage-lock.json
file, without the dev dependencies)There's also the
save the planet
reason. An example for the impact of such a change to a single package in terms of storage:barzik/branch-name-lint#50
The text was updated successfully, but these errors were encountered: