Skip to content
This repository has been archived by the owner on Aug 11, 2022. It is now read-only.

shrinkwrap "extraneous" error should be a warning #11040

Closed
fresheneesz opened this issue Jan 5, 2016 · 5 comments
Closed

shrinkwrap "extraneous" error should be a warning #11040

fresheneesz opened this issue Jan 5, 2016 · 5 comments

Comments

@fresheneesz
Copy link

Npm should not be erroring shrinkwrap because it believes you have extraneous modules. Especially when npm is bugging out in a few different ways #11039 #4435 #6298 #10073 #2679 #5135 . This should just be a warning and shouldn't block creation of the shrinkwrap. The shrinkwrap should be created with all the modules (extraneous or not) tho.

@othiym23
Copy link
Contributor

While this would be useful in some cases, it undermines the primary goal of shrinkwrapping, which is producing reproducible builds. If we were to relax that to a warning, it would be a footgun that would be very easy to ignore. Thanks for writing this up and pulling together those other issues!

@fresheneesz
Copy link
Author

@othiym23 Would it really undermine the goal of producing reproducible builds? I don't think it would if the allegedly extraneous modules were included in the shrinkwrap, right?

@othiym23
Copy link
Contributor

I believe that it would, for the simple reason that it's very easy to brush off warnings and assume that you know that none of them are going to affect your app when you deploy it, and then later find out that you actually needed one of those "extraneous" dependencies to produce a working deploy.

npm shrinkwrap is meant to be used as part of the deployment process, and as such is a preflight / finalization check. When you're running it, you really shouldn't have your packages in an undefined state.

@fresheneesz
Copy link
Author

"later find out that you actually needed one of those "extraneous" dependencies to produce a working deploy"

How would you find that out if that "extraneous" dependency is added into your shrinkwrap, and therefore in your deployment?

The way I use shrinkwrap is to ensure that all the devs are using the same versions of libraries. Npm isn't in any way involved in the deployment, and shouldn't be. It ensures that we don't have he-said she-said issues where a bug is reproducible on one dev's machine and not on others. As such, we shrinkwrap every module change.

While I'm sure we're doing things a bit differently than most people, I can't think of a case where including extraneous libraries with a warning would cause problems. That said, if npm fixes its bugs and becomes stable enough where I stop seeing bugs, I'm fine with that too ; )

@idautocfator
Copy link

This is annoying. I have some transient dependencies in another project that is shrinkwrapped and am stuck with extraneous errors due to dependencies in the subprojects not being listed in the package.json of the top level project.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants