Photo by Emily Morter on Unsplash
Let’s have an open floor to vent about things we don’t quite get about npm when using it in our daily lives (as well as alternatives like yarn).
Are you not sure why we need lockfiles? Do peerDependency warnings scare you? We don’t judge here. Do note that the purpose is not to bash the tool—I’m doing independent research to identify gaps and opportunities for better education.
Anything goes, but one scenario I’m particularly interested in is application developers trying to create their first reusable libraries, which seems to be a common source of confusion. Whether that’s you or not though, I’m grateful for any and all responses 🙇♂️
Top comments (9)
I'm curious what happens when two libraries require different versions of the same library. Does that result in the final bundle having both versions?
Ooo this is a big one. On the front end, where a bundler is involved, there's an additional layer of complexity that makes things worse. I find that it helps to first get a baseline understanding of how npm works in its original purpose (i.e. node apps) before laying over the bundling aspect.
Ultimately though, IMO the good old npmjs.com/package/webpack-bundle-a... helps remove any uncertainty (where webpack is involved).
Didn't answer the question and link doesn't work.
Ah, thanks for the heads-up, fixed.
As far as the question, honestly it's not something that can be properly answered in a comment—and it wasn't the intention of the post, I'm sorry if that wasn't clear. I hate to sound so vague, but I literally had to make an 1.5-hr long internal presentation to gradually build up the understanding of this exact situation. Part of the reason I'm doing this research is to understand if I can put together a larger-format thing that'd be publicly available and help answer those questions in something more than a "yes/no" manner.
In this particular case, the package manager may be able to deduplicate two versions of the dependency if their ranges are compatible, in which case only one copy of the library will be included into the bundle. The overall interplay between what a package manager does, and what a bundler does, is more interesting though IMO, and is a much broader subject.
Great points - I think that is where a lot of confusion originates for me. Where the responsibility of npm ends and the bundler begins.
Lets factor out the bundler portion. How would node handle this? Are all shared transient dependencies listed in the top level node_modules?
Generally yes, however it's not guaranteed.
The way I see it, the contract between node and npm (and other package managers) is the resolution algorithm. Whereby the code may contain require statements like
require('foo'). Then npm allows you to say, I depend onfooat version^1.2.3. The guarantee npm provides then, is that a copy offoocompatible with the^1.2.3range will be found in some location where the resolution algorithm will find it. That location may differ between versions of npm, yarn, and will definitely be something totally out of this world under pnpm 😀I believe all but the earliest versions of npm have tried to flatten the tree as much as possible, so deep dependencies are hoisted to the top as much as possible. However I never recommend relying on that because of the above and because it leads to other bad practices like failing to specify your dependencies in your package.json.
This is a great overview! Related talk: youtube.com/watch?v=4lUzKhq3C-M
Some comments may only be visible to logged-in visitors. Sign in to view all comments.