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

[FEATURE] Add option to disable integrity check #517

Closed
fuweichin opened this issue Nov 25, 2019 · 3 comments
Closed

[FEATURE] Add option to disable integrity check #517

fuweichin opened this issue Nov 25, 2019 · 3 comments
Labels
Enhancement new feature or improvement

Comments

@fuweichin
Copy link

What / Why

Since npm doesn't support mechanism like Maven SNAPSHOT(does it?), to fix a bug in a shared package and test if the bug is fixed in dependents, I need to do the following:

  1. Fix the bug, increase version number in package.json and publish to my private npm repository server
  2. Update package.json of every dependent, submit and push to git server, use Jenkins to deploy
  3. If some dependent shows the bug is not fully fixed or a new bug appears, then I need to go back to step 1

What a stupid workflow!

When

In the development phase, I want to republish/redeploy a npm package to repository server without updating package.json in each dependent. If I disable package-lock, of course that can be done easily, but I cannot, I need package-lock.json to lock version number of dependencies. with package-lock.json, installing an republished/redeployed dependency may result in error like 'integrity checksum failed'

Where

  • n/a

How

So my proposal is to add an CLI option (like --disable-integrity-check) for npm install and any other npm command which may trigger package integrity check, just like adding env var NODE_TLS_REJECT_UNAUTHORIZED=0 to disable ssl certificate validation.

Current Behavior

  • n/a

Expected Behavior

I want npm install to support an option like --disable-integrity-check, then npm won't check integrity of downloaded packages according to package-lock.json

or more specifically,

if a dependency's pre-relaese tag ends with specific suffix, e.g. .snapshot, then npm will not check integrity of redeployed/republished dependency.

Who

  • n/a

References

  • n/a
@x-yuri
Copy link

x-yuri commented May 29, 2020

My concerns are not about streamlining publishing packages, but rather about dealing with the "integrity checksum failed" error itself. I've found a workaround, but initially I was caught off guard. I wasn't sure what npm wants, and how I'm to deal with it. A more detailed report here.

@darcyclarke darcyclarke added the Enhancement new feature or improvement label Oct 30, 2020
@zanona
Copy link

zanona commented Dec 13, 2020

I agree with the author.
My use case:

  1. I have projects which I develop in parallel that rely all on the same package I maintain.
  2. Since my workflow runs under a docker environment, NPM link it's not a good fit since each project container does not share the same file system paths;
  3. I use mount --bind /path/to/shared project-a/node_modules/@scope/shared and so forth to override that specific package while I develop, so I can see changes reflect straight away on all projects.
  4. The problem arises whenever I need to install a new NPM package to any project as npm i cool-package would return something like:
npm ERR! path /mnt/app/node_modules/@scope/shared
npm ERR! git /mnt/app/node_modules/@scope/shared: Appears to be a git repo or submodule.
npm ERR! git     /mnt/app/node_modules/@scope/shared
npm ERR! git Refusing to remove it. Update manually,
npm ERR! git or move it out of the way first.
npm verb exit [ 1, true ]

And the whole process becomes a nightmare since it's impossible to install a package which is unrelated to @scope/shared due to some issues that happen on that specific one, so npm i --disable-integrity-check cool-package would basically allow me to carry on with developments without having to umount everything, install packages and mount it again.

@darcyclarke
Copy link
Contributor

npm v6 is no longer in active development; We will continue to push security releases to v6 at our team's discretion as-per our Support Policy.

If your bug is preproducible on v7, please re-file this issue using our new issue template.

If your issue was a feature request, please consider opening a new RRFC or RFC. If your issue was a question or other idea that was not CLI-specific, consider opening a discussion on our feedback repo

Closing: This is an automated message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement new feature or improvement
Projects
None yet
Development

No branches or pull requests

5 participants
@zanona @darcyclarke @x-yuri @fuweichin and others