Live data from Hacker News

Npm v5.0.0 released

blog.npmjs.org

61–70 of 117 posts

Re: Npm v5.0.0 released

#61
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?

A look through their issues on Github will reveal quite a few "npm supports this feature, yarn doesn't, plz add" entries. There are even more "this works in npm but not yarn, and I'm not sure why", many of which are also effectively a result of features/cases that npm supports and yarn doesn't. I don't have an exhaustive list or anything, but it's right there to see if you're interested enough to dig for a minute or two. It's pretty clearly not a drop-in replacement for npm—at least not yet.

My experience a couple months ago was that almost anything slightly off the path of the most basic use case rapidly entered "here be dragons" territory, such that every problem became "are we doing something wrong, or is yarn broken again?", which wasn't worth any benefits it provided. If you're just installing packages from NPM, and those packages don't do anything even slightly weird, it's probably fine.

[EDIT] a running theme of the issues is that a lot of correctness-checking and edge-case handling is missing or incomplete, in addition to some "strange" npm features not being supported. Anyway, here are a couple examples of what I'm talking about:

https://github.com/yarnpkg/yarn/issues/3433

https://github.com/yarnpkg/yarn/issues/3507

https://github.com/yarnpkg/yarn/issues/2090

(last one has a lovely "why are you doing this?" as its first response, from the repo owner for bonus LULZ)

FAR from the only ones. IIRC one of our issues had something to do with Yarn totally rewriting the package.json of a package installed from a local directory, removing the "main" entry entirely, which broke it (obviously). Maybe it'll be something I use later, but right now I don't really want to have to wonder whether any given problem is due to some obscure breakage in my package manager when I can... just use npm and not worry about it.

Re: Npm v5.0.0 released

#62
post #32
post #16

Earlier quoted context omitted.

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…

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.

Re: Npm v5.0.0 released

#63
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.

I think you have that backwards. npm doesn't support all of Yarn's features.

That may also be true, but so was what I wrote.

Re: Npm v5.0.0 released

#64

> 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

[deleted]

Re: Npm v5.0.0 released

#66
post #53

Earlier quoted context omitted.

>resolved by dropping npm-cli from the official releases. But that would break 7 years of documentation and tutorials, likely bad for newcomers and thus the ecosystem

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."

Re: Npm v5.0.0 released

#67

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 generally add a "scripts" entry to package.json for common tasks, which automatically adds "./node_modules/.bin" to the PATH. For one-off tasks I just run "./node_modules/.bin/executable"

Re: Npm v5.0.0 released

#68
post #9

So happy with the --save by default. Someone at work kept installing new dependencies without save (they didn't knew about it, somehow). We then had an unusable package.json. I had to manually find directories in node_modules and install them on production -_-.

And I think this is a complete bs. I have to try the module and then make a conscious decision to use (save) it, not kind of save it first and then hope that it actually does what I want. Like wtf, who thought that saving something you download maybe for the first time as a dependency is a good idea?

Is it that hard to `npm uninstall` if you decide you don't want it?

Re: Npm v5.0.0 released

#69
post #24
post #15

Someone told they now use hashes for versioning, like Nix, is this true? Is it finally save to install 2 times and get 100% the same packages?

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 that passed the tests to work around that, but it was still a massive pain that installs at different points in time would yield different trees.

When yarn came out, I deleted a folder full of hacky scripts, cut my install time by 60% and finally got deterministic installs. Needless to say, I was ecstatic.

Re: Npm v5.0.0 released

#70
If you're on Windows and want to give this thing a test drive, use `npm-windows-upgrade`:

Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force

npm i -g npm-windows-upgrade

npm-windows-upgrade --npm-version latest

Post reply on HN