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

91–100 of 117 posts

Re: Npm v5.0.0 released

#91

Post by AgentME »

nailer wrote: post #86
STRML wrote: post #69

Earlier quoted context omitted.

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?

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-check that node_modules really did match the shrinkwrap, and if not it would remove the directory entirely and re-run `npm install`... Thankfully this was fixed in npm v4.

Re: Npm v5.0.0 released

#92

Post by sschueller »

2manyredirects wrote: post #74

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

Re: Npm v5.0.0 released

#93

Post by swsieber »

This seems to be very similar to Gradle vs Buck (or Bazel).

Generally speaking the main tool is slow, or otherwise suboptimal but does a lot. A different tool is built with an emphasis on speed. Eventually, the main stream tools picks up the speed features of the other tool and then "wins" because it does more. (Side note: I have no idea when Gradle came out in comparison to Buck/Bazel) For context, Gradle in the 4.0 version is starting to really support build cache support.

Edit: this comment is a reaction to all the other comments I see here about yarn vs npm.

Re: Npm v5.0.0 released

#94

Post by simonw »

Thomaschaaf wrote: post #12
andyfleming wrote: post #2

How does this stack up against yarn now?

I built a project to compare yarn and npm. See https://github.com/thomaschaaf/npm-vs-yarn The different shows how much better npm@5 is :) It installs two node.js projects (react & ghost) and shows how long it takes to do under multiple scenarios (cold cache, installed and lockfile). It is automatically run each day. It also creates an average if one version is run multiple times.

That's really smart. I love how you're using Travis matrix builds for this, and publishing the results via the Google Sheets API.

Re: Npm v5.0.0 released

#95

Post by tomxor »

"package-lock.json" can someone please define what it is and does, I've heard of shrink wrap, google doesn't reveal anything about this file, I have a vauge idea that it has something to do with shrinkwrap but don't know why it exists or if it's supposed to replace shrinkwrap or whatever. splainit!

Re: Npm v5.0.0 released

#97

Post by addicted »

masterj wrote: post #84
silver-banshee wrote: post #50

Earlier quoted context omitted.

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

I also had a weird issue where for certain packages yarn would pick up a version which was older than what npm would. Not sure if this had anything to do with the fact that we have an internal npm mirror (that being said, yarn claims it picks up the .npmrc information, so even if it did, that would be a yarn bug).

In addition, yarn seems to increasingly be prioritizing its own default configs over what may be saved in my ~/.npmrc. Had several proxy issues after upgrading to a newer version of yarn that I didn't have earlier.

The reason I switched to yarn wholesale was because my existing npm based infrastructure worked seamlessly (at least to the extent that I was using npm features). But I've noticed that newer versions of yarn seem to have regressed in terms of npmrc support, which is a huge problem.

Re: Npm v5.0.0 released

#98

Post by cphoover »

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…

"Deterministic builds by default are such an obvious (in retrospect) core requirement."

I agree... I like the theoretical concept that our dependencies, could be automatically managed/upgraded behind the scenes via a declarative versioning system, like semver. That, in my view, was the paradigm behind not having defaulted to dependency graph snapshot (lock/shrinkwrap) by default. In practice, people don't follow semver correctly and autoupdating patch+minor versions can cause you a lot of pain. It would be cool to make versioning more tied to actual API signature, so that changes to the signature could not actually be published as minor/patch changes... but would be forced to use a major version bump in publish. I don't know how this would work particularly in a language like javacscript w/out a typed interface... but I'm just theorizing...

Re: Npm v5.0.0 released

#99

Post by josh64 »

013a wrote: post #90
diggan wrote: 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.

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.

You can do the same thing with npm and yarn as well by referencing the git+https URL and a tag/branch/commit instead of a version number.
Post reply on HN