
Npm v5.0.0 released - pajoda
http://blog.npmjs.org/post/161081169345/v500
======
chrisweekly
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 comprehensive writeups on best practices?Committing
lockfiles is a no-brainer. But what about globals? Per-node-version seems
logical, but there are also semantic problems with "global" packages vs
concept of executable binaries. I'd love to see a strong writeup outlining and
defending a standard approach.

~~~
pluma
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 Inc the company and npm-cli the (then) community-owned open source project unaffiliated with the company.

* Yarn does not share any source code directly with npm-cli, it's a complete reimplementation of a similar feature set. It's currently backed by a mirror of the npm registry but that's the extent of the overlap.

* The Node Foundation already exists and Yarn is already owned by the community. I could see Yarn joining the Node Foundation and the Node Foundation replacing its bundled dependency on the commercially owned npm-cli but even then npm Inc has nothing to contribute to the process.

Personally I would much rather see Yarn join the JavaScript Foundation because
it speaks to the broader appeal of Yarn outside the traditional "Node
community" and the politics involved in the latter and its close ties to npm
Inc.

FWIW I consider the close ties between the Node project and npm Inc nothing
more than a historical accident that has resulted in a conflict of interest
that is overdue to be resolved by dropping npm-cli from the official releases.

Now that yarn is no longer distributed using npm (although it's still possible
to install it that way) that seems more realistic than ever.

~~~
cheapsteak
>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

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

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

~~~
fibo
LOL

------
2manyredirects
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.
    

Having just done a quick test on a random project, I'm pleased to see that all
of those concerns are now taken care of, plus the install (for this project at
least) is ~30% faster than it is with yarn.

~~~
sschueller
Isn't npm shrinkwrap the npm "lockfile"?

~~~
abritinthebay
Kinda. Shrinkwrap has been around for a while.

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

------
eknkc
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 lock file / installation consistency stuff. Yarn has been
great on that too so we have no intention to go back but this is a decent
release.

~~~
gtirloni
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 months and see
what the community thinks of it before switching again.

~~~
farskipper
amen

------
Achshar
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 -_-.

~~~
gear54rus
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?

~~~
Achshar
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.

~~~
codefined
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.

~~~
gear54rus
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.

~~~
cben
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](https://twitter.com/maybekatz/status/859193277894991872)

Docs are lacking, following up on
[https://github.com/npm/npm/issues/5108](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.

------
felixrieseberg
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

------
evolve2k
> 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

~~~
kuschku
Or even package.lock.json

~~~
evolve2k
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](https://github.com/npm/npm/pull/16441#issuecomment-304458746)

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

------
synthecypher
Its still not as fast as yarn FYI.

~~~
ashark
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.

~~~
silver-banshee
what are these npm's features that yarn doesn't support?

~~~
masterj
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

~~~
addicted
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.

------
shadowmint
This might be a totally stupid question, but what does that mean?

    
    
        npm install npm@latest -g
    
        /usr/local/bin/npm -> /usr/local/lib/node_modules/npm/bin/npm-cli.js
        /usr/local/lib
        └── npm@4.6.1
    

How do I install it? Or... it's not quite released yet after all?

Edit: nevermind, I found it -->
[https://github.com/npm/npm/releases](https://github.com/npm/npm/releases)
this is the 'prerelease' release.

~~~
nailer
Right now latest still points to v4. You can install 5 with:

    
    
        npm install -g npm@5 
    

Then see:

    
    
        npm -g ls npm
    

Which returns:

    
    
        +-- npm@5.0.0

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

------
andyfleming
How does this stack up against yarn now?

~~~
Thomaschaaf
I built a project to compare yarn and npm. See
[https://github.com/thomaschaaf/npm-vs-
yarn](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.

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

------
Already__Taken
>All installs will be saved by default

>since npm@3, npm will automatically update npm-shrinkwrap.json when you save

All installs update shrinkwrap then? doesn't that start to make it redundant
to package.json in the first place now. Does this make git tracking package
and shrinkwrap mandatory in-case you want to install, test but then roll back
the version, as shrinkwrap will already have changed.

edit: Oh I'm supposed to --no-save now for that described flow?

------
romanovcode
Seems like their catching up to Yarn, and finally they are there. I'm happy to
ditch Yarn and go back to NPM once it's as good.

~~~
scrollaway
Why go back if you already migrated?

~~~
abritinthebay
A ton of things either don't work or are harder with Yarn.

It's great at what it does, and great for the simple case, but it's only a
subset of functionality.

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

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

~~~
STRML
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.

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

~~~
AgentME
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.

~~~
nailer
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.

~~~
AgentME
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.

------
plexicle
npm desperately needs a flat install option.

~~~
JeuelyFish
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?

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

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

------
floatboth
> A new npm cache verify command that will garbage collect your cache,
> reducing disk usage for things you don’t need (-handwave-), and will do full
> integrity verification on both the index and the content

Nice.

------
assafmo
_> 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! :-)

------
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!

------
mstijak
I'm really excited about links. Links will make things much easier for
monorepos.

------
Achshar
I'm not able to update it to v5. npm install npm@latest -g doesn't update.

~~~
kotojo
npm install npm@5 -g. Latest still points at 4.x currently.

------
ainiriand
It is not NPM, it is npm.

~~~
m_t
This is good point as it's the third element in their "breaking changes"

> npm will now scold you if you capitalize its name. seriously it will fight
> you.

------
mderazon
Can someone explain the git semver thing ? How does it work?

------
vacri
How is the _package manager_ for a language still iterating through major
versions and making breaking changes nearly a decade after launch? Node is
bizarre in that you have to follow its package manager so closely.

~~~
tiles
npm has to deal with scale: it's now the largest programming language package
manager, and most project dependency trees have exploded in size as a result.
Optimizing that led to yarn and to npm@5.

~~~
jbverschoor
npm has to deal with scale because every single npm install goes to npm
instead of a local cache of certain versions.

Bundler led to yarn. The JS community should start looking what other
ecosystems do and have done (right and wrong).

Such a waste of time these past 20 years and it happens over and over.

~~~
eropple
I could be incorrect, but I don't believe Bundler was the first to lock and
manage dependencies? I seem to recall using such tools before 2010. This isn't
to take away from your main point by any stretch; only recently has JavaScript
gone from "downright terrible" to "tolerable" and most of it is through doing
what others already did, better, many years before. It still feels like a lot
of the community doesn't have sufficient exposure to stuff outside their
closure and people who work with that community's stuff are the worse for it.

