Join GitHub today
release: email@example.com #16244
NOTE: This PR is a WIP. npm@5 beta is currently underway. See #16510 for deets.
This release marks months of hard work for the young, scrappy, and hungry CLI team, and includes some changes we've been hoping to do for literally years. npm@5 takes npm a pretty big step forward, significantly improving its performance in almost all common situations, fixing a bunch of old errors due to the architecture, and just generally making it more robust and fault-tolerant. It comes with changes to make life easier for people doing monorepos, for users who want consistency/security guarantees, and brings semver support to git dependencies. See below for all the deets!
There's a bunch of exciting stuff going in here! You can track all the changes planned for
We've been talking about rewriting the cache for a loooong time. So here it is. Lots of exciting stuff ahead. The rewrite will also enable some exciting future features, but we'll talk about those when they're actually in the works. #15666 is the main PR for all these changes. Additional PRs/commits are linked inline.
For release task list
@zkat Will any of these flags become default?
Some folks bump into addition flags but it doesn't reach everyone (example:
I understand that it breaks expectations on how people think npm works right now (which is
@siddharthkp There's no significant speed difference between
I see you mentioned that you think users would expect
Now, if you're looking for a speedup, the biggest one you can get with
So, no, I probably won't use npm@5 to make
I had a conversation with @iarna a while back (npm 3) where she educated me about the network requests to the registry even when using cache + the effect of latency on it. (Significant for emerging nations - prominently 2G and latency heavy nations - Australia and such)
Are you saying pacote nullifies that effect? (or at least makes it not noticeable) because that would be
Ouch! My bad, I meant
This is another interesting part
I'm on a Bay Area network, which is admittedly absurdly good. If the difference is so small now, though, I imagine it wouldn't be so big: even at 1/10th the speed, that would still be barely 10 seconds added (to a 60-second installation).
I really can't say that for sure right now. tbh, the difference is so surprisingly small that I think I'm gonna have to spend some time crawling through tests and making sure I don't have some bug. That code definitely has tests attached, though...
Ah. As far as this one goes, pacote obeys cache age settings from a given registry. This is generally happy news for all involved (if we hit the registry less without degrading user experience, that's a win!), and those settings tend to be fairly low: the main npm registry sets
I would care more if it weren't for shrinkwrap being the main target of optimization, which brings me to...
Pretty much this. If we don't have the exact hashes for the tarballs we want to end up installing, npm needs to repeat the process of
Not quite yet. There's a github project for npm@5 and one of my TODOs is to write a proposal for how shrinkwrap-by-default would work. From what I've talked with @iarna, though, we need to fix other stuff (like
@Kuroljov This release addresses a lot of performance issues. Right now, npm@5 installs are running anywhere between 2x-5x faster than
Some sample benchmarks:
@siddharthkp expect a beta release of npm@5 in the coming weeks. I can't give you the exact date, but I'm currently in the process of reviving npm's massive test suite after such a big change and fixing all my little messups along the way.
What I can tell you is that if you make https://npm.im/make-fetch-happen and https://npm.im/cacache faster and better, it'll be directly reflected on the performance of npm@5. Once https://npm.im/pacote gets its
I'll make an announcement somewhere dev-oriented once
@siddharthkp coming back to this: what are the network conditions where you're at? (since you asked). I'd like to get a better, more realistic perspective on how npm5 handles slow and/or unstable networks and special configurations like proxies, which is all fairly hard to simulate unless you've been deep in that situation, imo. There's now a (semi-closed) beta of npm5 that you can install with
Previously we were doing this so we could load relationships, but now we can simply request no fake children. This forces a fetch-metadata phase for the lockfile, but does not actually install all the modules.
This can happen when, for example, removing a module from your project that isn't actually in your node_modules at the moment.
It used to be that we did this check in `is-extraneous` but it turns out to be much cleaner to keep that pure. It let's us use `is-extraneous` for things like pruning.
@iarna thank you for taking care of this!! I was struggling for a bit to get my PR working properly... one question though - it appears that this would never calculate the tree if you run npm with "--ignore-scripts". Is that the case?
Anyway - it's great to see how you approached this and I'll definitely learn from it. Cheers.