Live data from Hacker News

Npm v5.0.0 released

blog.npmjs.org

101–110 of 117 posts

Re: Npm v5.0.0 released

#101

First of all: Thank you, yarn, for helping the community see the naked emperor. Deterministic builds by default are such an obvious (in retrospect) core requirement. Couple questions: Question 1: Does anyone else who's been around more than a couple years share my view that Yarn : NPM :: IO.JS : Node? IOW: healthy competition, catalyst for necessary change, ultimately a bridge or stopgap. Question 2: Any good compreh…

Answer 1: Yes but they're not exactly analogous and I don't see them merging. Yarn is a complete rewrite, and the compatibility "surface area" is much lower than Node itself so there's not much pressure for them to merge. Yarn has been working essentially flawlessly for me, so npm-cli is really going to have to surpass yarn in some way for me to switch back. Answer 2: I don't use global packages often. For binaries I…

Git dependencies with semver support seems to pretty much leapfrog yarn. One of the few reasons for a private npm package is removed with this feature.

Re: Npm v5.0.0 released

#102

First of all: Thank you, yarn, for helping the community see the naked emperor. Deterministic builds by default are such an obvious (in retrospect) core requirement. Couple questions: Question 1: Does anyone else who's been around more than a couple years share my view that Yarn : NPM :: IO.JS : Node? IOW: healthy competition, catalyst for necessary change, ultimately a bridge or stopgap. Question 2: Any good compreh…

It's more accurate to say that npm v5 : npm :: io.js : node.

Same team, performing a big refactoring and significant improvement and modernization of some bits that were outdated and difficult to improve without a controlled demolition and rebuild.

The analogy breaks down, of course, because the governance didn't change, the project's relationship to its corporate backer wasn't standing in the way of progress, etc. (Except, I guess, that it might have gone faster if we'd had more money to hire more devs? But some of this was just a slog through a very old codebase with a lot of scar tissue, and it's hard to speed that up by putting more hands on it.)

Everything in npm 5 was literally planned years in advance. When we have this many people depending on a thing, we have to be careful about how we make drastic changes. Yarn was a strong signal from the community that we were on the right track, but it only seems like a "catalyst" when seen from the outside. Correlation is not causation, even when it lands first.

Re: Npm v5.0.0 released

#103
post #16

First of all: Thank you, yarn, for helping the community see the naked emperor. Deterministic builds by default are such an obvious (in retrospect) core requirement. Couple questions: Question 1: Does anyone else who's been around more than a couple years share my view that Yarn : NPM :: IO.JS : Node? IOW: healthy competition, catalyst for necessary change, ultimately a bridge or stopgap. Question 2: Any good compreh…

When io.js merged back into node.js the following happened: 1. Node.js was abandoned and replaced with io.js. 2. Io.js was relabelled as node.js. 3. The node.js project was put under open governance via the creation of the Node Foundation. This doesn't really compare to npm: * The npm-cli's name is using npm Inc's trademark: giving it away would leave the company with no name or create unwanted ambiguity between npm…

Yarn does not run a mirror of the registry. registry.yarnpkg.com is a pass-through domain to the npm registry. It allows them to collect stats about yarn usage but is not a mirror.

Re: Npm v5.0.0 released

#104
post #57

Earlier quoted context omitted.

You should implement basic ci with travis et al. That commit should never be able to make it into master. If you are using Github you can force green tests before a pull request is mergeable.

Even if you don't have good test coverage, even having your CI just do a webpack build would likely catch that problem. Well worth it.

Considering it’s free it’s a non-brainer.

Re: Npm v5.0.0 released

#105

We dropped npm in favour of yarn a while back, but I imagine we'll switch back once the stable release is out. Our needs are perhaps simpler than most, but the key issues we were having with npm at the time were directly solved by yarn: 1. Dependency install was taking too long. 2. Inconsistent builds between devs because of no lock file. 3. Could not search the registry from the command line in a timely manner. Havi…

Isn't npm shrinkwrap the npm "lockfile"?

Kinda. Shrinkwrap has been around for a while.

The new lockfile is basically shrinkwrap 2.0 using what's been learned since

Re: Npm v5.0.0 released

#106
post #6

Just tried on a couple of projects with a lot of dependencies, we moved to yarn a while ago due to performance issues and it seems to be resolved. On cold cache: Yarn: 20.94 seconds NPM5: 21.11 seconds With cache: Yarn: 10.35 seconds NPM5: 15.20 seconds For some reason, when node_modules folder is still there, yarn exits in a couple hundres milliseconds but npm5 does something for around 5 seconds. Haven't checked lo…

I'd be curious to see the warmed cache with --prefer-offline as I'm betting that's probably the time suck there.

Re: Npm v5.0.0 released

#107
post #13
post #6

Just tried on a couple of projects with a lot of dependencies, we moved to yarn a while ago due to performance issues and it seems to be resolved. On cold cache: Yarn: 20.94 seconds NPM5: 21.11 seconds With cache: Yarn: 10.35 seconds NPM5: 15.20 seconds For some reason, when node_modules folder is still there, yarn exits in a couple hundres milliseconds but npm5 does something for around 5 seconds. Haven't checked lo…

If I recall correctly, npm5 with an existing node_modules folder still goes out to the internet and checks some data whereas yarn does not.

Yup, tho it's configurable and you can set --prefer-offline to true to avoid it

Re: Npm v5.0.0 released

#108
> Running npm while offline will no longer insist on retrying network requests. npm will now immediately fall back to cache if possible, or fail. (#15666)

Finally! :-)

Re: Npm v5.0.0 released

#109
post #88
post #62

Earlier quoted context omitted.

A decentralized repository of packages that anyone can help out maintain. Not entirely sure how, but I think that would be the ideal scenario.

Back when the npm registry was really struggling with reliability (I believe because it was secondary to profit for Joyent) I was saying we needed a decentralized registry solution. But right when that got some upvotes on r/node, within a few days isaacs had npm inc. going. And within a few weeks or months, the npm registry was pretty rock solid. And I have not had a single registry issue in forever. And npm 4 works…

That's great to hear!

Reliability sure was tough in those days. npm wasn't secondary or tertiary or any-ary to Joyent. It was my nights and weekends project the whole time I was there, and IrisCouch generously donated infrastructure, which we pushed to its very limit once Nodejitsu acquired them.

Re: Npm v5.0.0 released

#110
post #45

Earlier quoted context omitted.

Most of the time when I do npm install it's for stuff I know I will need. If you want to check something out you can always just --no-save it.

Does uninstall default to --save too? Because if so, then your workflow doesn't even have to change gear. You just install it to check it out, you like it then do nothing, you don't like it then you can just `npm uninstall`, something you'd hopefully do anyway.

First time I hear about '--save' for uninstall, but it doesn't make a difference in my case because I always install many things, test them all at once, then '--save' what I need and 'rm -rf' the 'node_modules'. After that, 'npm i' gives me everything I need.

I still think this change is beyond stupid.

Post reply on HN