Installing a dependency from git attempts to install all transitive dependencies even those that aren't in the lock file #150416
Replies: 2 comments 2 replies
-
|
Hi @SayakMukhopadhyay, thanks for being a part of the GitHub Community! Have you tested this with different npm versions to see if it’s a recent change?
|
Beta Was this translation helpful? Give feedback.
-
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This is a very particular issue that I am facing and I will have to go into the details to explain so please bear with me.
Background
I am working on a Hugo project with the Docsy theme and Docsy has a dev dependency on the npm library hugo-extended. This library has a post install scripts which downloads the Hugo binary pertaining to the current platform and attempts to execute it once to check if the correct version was downloaded.
If I install Docsy with
npm install github:google/docsy#semver:0.11.0, the resultingpackage-lock.jsondoesn't includehugo-extendedat all, which is what I want (we install Hugo ourselves and don't want the transitive dependency of Hugo Docsy brings). Installing Docsy like this works just fine (at least on the surface) on my Windows system and on most Linux based containers.The Issue
But the issue crops up when trying to install Docsy in an Alpine linux based container. The error that crops up is due to the downloaded binary not being compatible with musl based systems like Alpine.
But, that is not the issue. The issue here is that running
npm install github:google/docsy#semver:0.11.0results in an attempt to installhugo-extended. Sincehugo-extendedis not in mypackage-lock.json, there should be no attempt to installhugo-extended. In fact using yarn instead, I don't face this issue as (seemingly) yarn doesn't try to installhugo-extended.The diagnosis
Initially, I spent a lot of time trying to get the hugo binary working with alpine but as I mentioned before, I kept thinking that npm shouldn't even be attempting to install
hugo-extendedin the first place and I found the yarn actually doesn't. Which led me to try and find if the issue is with npm itself. Runningnpm install github:google/docsy#semver:0.11.0gives a particular error message among othersSearching around this issue led me to
https://github.com/npm/pacote/blob/bf1f60f58bb61f053262f54724edcacaadb221ce/lib/git.js#L152-L191
Here, I can see that npm tries to run
npm installon any git based dependencies which results in attempting to install everything in thepackage.jsonof that git based dependency, *even if it isn't present in our package-lock.json`.To me, this is an unpredictable behaviour. npm shouldn't be attempting to install the whole
package.jsonof this dependency, even if it is doing that in a temp folder.Note
We have workarounds for this but the fact that this issue doesn't happen with yarn is indicative that it's npm's implementation that is leading to this issue. I am not raising this issue as
npm/cliornpm/pacoteHere's the related issue and discussion which led to this post: kubernetes/website#49460 (comment)
Beta Was this translation helpful? Give feedback.
All reactions