Live data from Hacker News

Npm v5.0.0 released

blog.npmjs.org

81–90 of 117 posts

Re: Npm v5.0.0 released

#81
post #4

How does this stack up against yarn now?

I never used yarn, but I just did some research about the changes in comparison to yarn. Well, actually they are more similar now, obviously (saving by default for example). In terms of speed, npm has improved as well ( https://twitter.com/passcod/status/860437637764571140 ). Even though npm still seems to be slower than yarn ( https://docs.google.com/presentation/d/1re-AGrTOf4zmnXXDMTG1... ). At the end, I'd say it'…

Glad to know they addressed the issues why I switched to yarn (speed, save by default and lock file).

Definitely will give this a try once it is moved out from pre-release.

Re: Npm v5.0.0 released

#82
I still want npm-search improved.

I want to be able to search by tag, constrained by license and with packages that use dependencies I already have installed floated to the top. There are so many ways this could be nicer.

Re: Npm v5.0.0 released

#83

> A new, standardised lockfile feature meant for cross-package-manager compatibility (package-lock.json) Surely it would be much better to follow standard lock file naming conventions and name the file package.lock

I'd rather my editor recognize a .json file and treat as such. I don't have a .lock convention

Re: Npm v5.0.0 released

#84
post #47

Earlier quoted context omitted.

Yarn doesn't support all of npm's features. At least not as of a couple months ago when it 1) didn't support one of our needs at all, and 2) broke a couple NPM packages on install. This may or may not be part of why it's faster: it does less.

what are these npm's features that yarn doesn't support?

I do support and these issues come up all the time with yarn:

- native packages are not well-supported by yarn yet, notably node-sass since it's so widely-used

- no private module support

Re: Npm v5.0.0 released

#85

Earlier quoted context omitted.

This is probably a naive question, but the only use case I've come across of needing a flat-install option was to use Polymer.js web components (which is why so much of the polymer project relies on bower). Aside from that, what is the use case that flat installs solve?

Not naive, and that's pretty much the primary reason. But for all web components in general, not just the Polymer flavor.

gotcha, that makes sense. My only expose to web components was polymer. Thanks for the clarification

Re: Npm v5.0.0 released

#86
post #69
post #24

Earlier quoted context omitted.

It's been that way for years, since shrinkwrap was invented.

Shrinkwrap did not use hashes and did not guarantee deterministic installs. Subdependencies could still end up as different versions. Even the shrinkwrap file itself contained a lot of trash and generated massive diff noise. I had a file full of scripts to make the shrinkwrap file usable and even then we had (production!!!) issues due to changing subdeps. We reworked our build processes to zip & deploy the exact code…

Shrink wrap versions subdependencies. Why would they end up as different versions?

Re: Npm v5.0.0 released

#87
post #22

Earlier quoted context omitted.

> Thank you, yarn, for helping the community see the naked emperor. Deterministic builds by default are such an obvious (in retrospect) core requirement. https://docs.npmjs.com/cli/shrinkwrap provides deterministic builds and has been around far longer than yarn. Since Oct 2014 npm v3 started automatically updating shrinkwrap whenever '--save' was used. See https://github.com/npm/npm/pull/4918#issuecomment-61344871 C…

Even with shrinkwrap, npm install is not deterministic, install order still matters. To get a deterministic install, you need to use shrinkwrap and do an `rm -rf node_modules` before every install. And it's still not completely deterministic if any dependency or sub-dependency has optionalDependencies. https://docs.npmjs.com/how-npm-works/npm3-nondet

That, and the fact that it's not the default behavior in npm gives yarn a pretty big advantage in my opinion. Especially for devs who are newer to Node.js.

Re: Npm v5.0.0 released

#88
post #62
post #32

Earlier quoted context omitted.

What replaces the npm registry, though? That's the reason that npm Inc. exists, not just stewardship of the CLI.

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 well, and I'm sure npm@5 works even better.

I still think it makes sense to have a decentralized repository and I guess its nice to have a non-commercial alternative to npm. But for me its not important anymore because npm is working really great now.

Re: Npm v5.0.0 released

#89
post #66
post #53

Earlier quoted context omitted.

so npm has created a huge vendor lock-in and we should live with it?!

"The only reason God could create the world in six days is, He didn't have to worry about backward compatibility."

LOL

Re: Npm v5.0.0 released

#90
post #62
post #32

Earlier quoted context omitted.

What replaces the npm registry, though? That's the reason that npm Inc. exists, not just stewardship of the CLI.

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

Go does something like this, by referencing packages through Git url. Of course, 99% of packages you install are through Github, but that's not Go's fault. It has downsides, but its really a great and extensible system.
Post reply on HN