Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Npm v5.0.0 released

blog.npmjs.org

Post reply on HN
Print view View original

111–117 of 117 posts

Re: Npm v5.0.0 released

#111

Post by nailer »

AgentME wrote: post #91
nailer wrote: post #86

Earlier quoted context omitted.

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

npm used to have issues that if you had a shrinkwrap and a pre-existing node_modules directory and ran `npm install`, then npm would often report success but silently fail to make the node_modules directory actually match the shrinkwrap. ... After our build system ran into this issue once and built and deployed code to production with fatally mismatched dependencies, I wrote a hacky wrapper script which would double-…

OK that's a bug, but it's fixed for more than a year. Nobody in this entire thread has given a reason why a captured versions of the entire tree wouldn't produce deterministic output.

Re: Npm v5.0.0 released

#112

Post by evolve2k »

kuschku wrote: post #55
evolve2k wrote: post #54

> 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

Or even package.lock.json

I had originally been for package.lock, but after reading right through the issue I now agree with your excellent suggestion of package.lock.json.

Rather than just talk here, I've posted against the issue suggesting this approach basically asking for up/down votes. https://github.com/npm/npm/pull/16441#issuecomment-304458746

Re: Npm v5.0.0 released

#113

Post by chrisweekly »

IsaacSchlueter wrote: post #102
chrisweekly wrote: post #10

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. (…

Thanks Isaac! Both for this insight and - more so - for your massive contributions to the community. Slainte! :)

Re: Npm v5.0.0 released

#114

Post by pluma »

josteink wrote: post #26
cheapsteak wrote: post #20

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

Not to mention quite a few CI build pipelines.

FWIW it's trivial to install yarn already: https://yarnpkg.com/en/docs/install

NPM currently doesn't provide a standalone distribution as far as I can tell, but presumably they would offer one if they no longer had the luxury of being bundled with Node.

Since changes generally don't happen overnight I would expect a transitional period where Node still bundles npm-cli but npm Inc has the time to prepare a standalone distribution before yarn replaces npm-cli. Additionally downstream channels could decide to provide legacy packages containing both.

Re: Npm v5.0.0 released

#115

Post by farskipper »

gtirloni wrote: post #7
eknkc wrote: 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…

Also ran some numbers here (with warm cache. node 6.10.3). * yarn: 25s * npm@5: 28s * npm@4: 63s * npm@3: 68s So performance is now comparable, which is awesome, but I'd still stick to yarn because we have been burned too many times by npm v2/v3 with call stack issues and other errors. I don't have the energy (or the time/faith) to go through that again. Competition is wonderful though. I'll check npm again in 6-12 m…

amen

Re: Npm v5.0.0 released

#116

Post by AgentME »

nailer wrote: post #111
AgentME wrote: post #91

Earlier quoted context omitted.

npm used to have issues that if you had a shrinkwrap and a pre-existing node_modules directory and ran `npm install`, then npm would often report success but silently fail to make the node_modules directory actually match the shrinkwrap. ... After our build system ran into this issue once and built and deployed code to production with fatally mismatched dependencies, I wrote a hacky wrapper script which would double-…

OK that's a bug, but it's fixed for more than a year. Nobody in this entire thread has given a reason why a captured versions of the entire tree wouldn't produce deterministic output.

Yeah, it should only be bugs that cause subdependency versions to not match the shrinkwrap. Your question seemed valid. I can only guess others have run into similar issues as me and hadn't known if they were fixed.

Re: Npm v5.0.0 released

#117

Post by cben »

gear54rus wrote: post #110
codefined wrote: post #52

Earlier quoted context omitted.

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.

When you commit your changes, it's similarly easy to inspect package.json changes, and only commit the lines you want [1].

This change increases the chance that what you have working locally is reproducible from "source". IMHO that's a very important goal, while debate over convenience of omitting --save vs --no-save is superficial. Obviously there are 2 groups and one will be unhappy either way, but does that justify calling it "beyond stupid"? (I could maybe see that if you had actual data that 90% people want --no-save...)

Also, seems you can config old default by `npm config set save false` (with the risk one day you'll work on another machine and be surprised by uncustomized defaults). https://twitter.com/maybekatz/status/859193277894991872

Docs are lacking, following up on https://github.com/npm/npm/issues/5108

[1] If your commit flow doesn't make this a pleasant experience — e.g. command-line git IMHO doesn't — you deserve better tools. I can recommend `git citool` for start — old and ugly UI, but fast, portable, has keyboard shortcuts, also very convenient for amending.

Post reply on HN