Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] npm does not respect shrinkwrap files when _hasShrinkwrap is undefined #4583

Open
2 tasks done
t1m0thyj opened this issue Mar 17, 2022 · 4 comments
Open
2 tasks done
Labels
Bug thing that needs fixing Priority 1 high priority issue Release 8.x work is associated with a specific npm 8 release

Comments

@t1m0thyj
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

This issue exists in the latest npm version

  • I am using the latest npm

Current Behavior

If I publish a package that contains npm-shrinkwrap.json to an NPM registry that does not define the _hasShrinkwrap property in its package metadata, then npm install ignores the shrinkwrap file when I install that package.

Registries that do not define the _hasShrinkwrap property in their package metadata include Artifactory 7.34.4 and Verdaccio 5.8.0.

Expected Behavior

If _hasShrinkwrap is undefined then npm should fall back to checking for the presence of npm-shrinkwrap.json.

This was the behavior in npm@6, and is the expected behavior according to the npm registry docs:

_hasShrinkwrap: true if this version is known to have a shrinkwrap that must be used to install it; false if this version is known not to have a shrinkwrap. If this field is undefined, the client must determine through other means if a shrinkwrap exists.

Steps To Reproduce

  1. Create an npm project: npm init -y
  2. Install a package that meets the criteria above, for example:
    npm install @zowe/cli@6.37.8 --@zowe:registry=https://zowe.jfrog.io/zowe/api/npm/npm-release/
    (zowe.jfrog.io is a public Artifactory registry and this package uses shrinkwrap)
  3. See evidence that shrinkwrap was ignored:
    • The dependency tree is flattened inside node_modules
    • Installed package versions are not locked down (e.g., flatted@3.2.5 instead of 3.2.4)

Environment

  • npm: 8.5.4 (updated from 8.3.1)
  • Node.js: 16.14.0
  • OS Name: Debian 10 (buster)
  • System Model Name: docker.io/node:lts
@t1m0thyj t1m0thyj added Bug thing that needs fixing Needs Triage needs review for next steps Release 8.x work is associated with a specific npm 8 release labels Mar 17, 2022
@wraithgar wraithgar added Priority 1 high priority issue and removed Needs Triage needs review for next steps labels Mar 17, 2022
@10hendersonm
Copy link

This is biting me from, humorously, both Verdaccio (canary environment) and Artifactory (beta + prod environment) today.

@sarumont
Copy link

You can add Github Packages to the list of registries that don't set _hasShrinkwrap.

@morriswinkler
Copy link

morriswinkler commented Sep 28, 2022

+1 from me and gitlab is also not adding that metadata field:

NPM docs say following about _hasShrinkwrap metadata field:

_hasShrinkwrap: true if this version is known to have a shrinkwrap that must be used to install it; false if this version is known not to have a shrinkwrap. If this field is undefined, the client must determine through other means if a shrinkwrap exists.

So i guess the idea was that npm install would have to check for npm-shrinkwrap.json and update the root package-lock.json regardingly, might be a job for the arborist package (https://github.com/npm/cli/blob/latest/workspaces/arborist/docs/ideal-tree.md).

@chgeo
Copy link

chgeo commented Aug 9, 2023

Any update here? Would love to see this fixed as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug thing that needs fixing Priority 1 high priority issue Release 8.x work is associated with a specific npm 8 release
Projects
None yet
Development

No branches or pull requests

6 participants