12 ms·

Npm v5.0.0 released

271 points by pajoda 9y ago

ainiriand 9y ago
It is not NPM, it is npm.
- m_t 9y ago
  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.
- pajoda 9y ago
  It should be npm, totally. I noticed it too late to edit, unfortunately.
vacri 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.
    - ceejbot 9y ago
      This statement is false and has been since the very first work done on the npm cli. npm has, in every version of it that has ever existed, since before there was even a package registry, installed preferentially from its local cache of packages where possible.
k__ 9y ago
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 9y ago
  It's been that way for years, since shrinkwrap was invented.
  - k__ 9y ago
    Really? Does shrinkwrap work for transitive deps?
    - samtho 9y ago
      Yes, this is a huge selling point to the usefulness of npm-shrinkwrap.
      - k__ 9y ago
        Interesting. I thought yarn and ied were created because this didn't work with npm. -- edit -- Seems that npm shrikwrap -> npm i -> npm shrikwrap is not guaranteed to produce the same output.
  - STRML 9y ago
    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.
andyfleming 9y ago
How does this stack up against yarn now?
- pajoda 9y ago
  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 https://twitter.com/passcod/status/860437637764571140). Even though npm still seems to be slower than yarn (https://docs.google.com/presentation/d/1re-AGrTOf4zmnXXDMTG1UIuce8gVClkoq0HyN0IhCyQ/edit#slide=id.p https://docs.google.com/presentation/d/1re-AGrTOf4zmnXXDMTG1...). At the end, I'd say it's about personal preference, they both get the job done.
  - max23_ 9y ago
    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.
- Thomaschaaf 9y ago
  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 9y ago
    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 9y ago
>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 9y ago
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 9y ago
  Why go back if you already migrated?
  - romanovcode 9y ago
    - Global dependencies do not work on Yarn if you install node with brew. - NPM comes pre-installed with Node.
  - cwmma 9y ago
    last I check certain features like bundledDeps didn't work on yarn
  - abritinthebay 9y ago
    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.
eknkc 9y ago
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 9y ago
  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 9y ago
    amen
- ryanar 9y ago
  If I recall correctly, npm5 with an existing node_modules folder still goes out to the internet and checks some data whereas yarn does not.
  - abritinthebay 9y ago
    Yup, tho it's configurable and you can set --prefer-offline to true to avoid it
- KayL 9y ago
  my test: npm@5 28.274s vs 11.60s Yarn @Windows10, SSD, warn cache
- 9y ago
Achshar 9y ago
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 -_-.
- Thomaschaaf 9y ago
  You should implement basic ci with travis et al. That commit should never be able to make it into master. If you are using Github you can force green tests before a pull request is mergeable.
  - btown 9y ago
    Even if you don't have good test coverage, even having your CI just do a webpack build would likely catch that problem. Well worth it.
    - kukabynd 9y ago
      Considering it’s free it’s a non-brainer.
- gear54rus 9y ago
  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?
  - vmasto 9y ago
    It is perfectly reasonable and avoids mistakes. It's better to have a module that's unused than to break your whole build. If you want to try something install it and then remove it. That's the more conscious decision. I don't want to have to remember to save the module if I end up liking it, but I will remember to remove it when tearing it down from the codebase, and if I don't, nothing bad happens.
chrisweekly 9y ago
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 9y ago
  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.
  - ultim8k 9y ago
floatboth 9y ago
> 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.
Achshar 9y ago
I'm not able to update it to v5. npm install npm@latest -g doesn't update.
- kotojo 9y ago
  npm install npm@5 -g. Latest still points at 4.x currently.
- deleted 9y ago
  [deleted]
shadowmint 9y ago
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.
- Thomaschaaf 9y ago
  npm install npm@next -g works :)
- nailer 9y ago
  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
synthecypher 9y ago
Its still not as fast as yarn FYI.
- ashark 9y ago
  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 9y ago
    what are these npm's features that yarn doesn't support?
    - ashark 9y ago
      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/3433 https://github.com/yarnpkg/yarn/issues/3507 https://github.com/yarnpkg/yarn/issues/3507 https://github.com/yarnpkg/yarn/issues/2090 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.
evolve2k 9y ago
> 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 9y ago
  Or even package.lock.json
  - evolve2k 9y ago
    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
- deleted 9y ago
  [deleted]
- mstade 9y ago
  It bothers me somewhat that they say this is standardized, but not by whom. Is the idea that Yarn should fall in line or is it a case of https://xkcd.com/927/ https://xkcd.com/927/ ?
- qntmfred 9y ago
  I'd rather my editor recognize a .json file and treat as such. I don't have a .lock convention
plexicle 9y ago
npm desperately needs a flat install option.
- JeuelyFish 9y ago
  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 9y ago
    Not naive, and that's pretty much the primary reason. But for all web components in general, not just the Polymer flavor.
    - JeuelyFish 9y ago
      gotcha, that makes sense. My only expose to web components was polymer. Thanks for the clarification
- bluetech 9y ago
  What does "flat install" mean?
mstijak 9y ago
I'm really excited about links. Links will make things much easier for monorepos.
felixrieseberg 9y ago
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
2manyredirects 9y ago
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 9y ago
  Isn't npm shrinkwrap the npm "lockfile"?
  - abritinthebay 9y ago
    Kinda. Shrinkwrap has been around for a while. The new lockfile is basically shrinkwrap 2.0 using what's been learned since
blitmap 9y ago
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.
swsieber 9y ago
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.
tomxor 9y ago
"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!
mderazon 9y ago
Can someone explain the git semver thing ? How does it work?
assafmo 9y ago
> 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! :-)

Npm v5.0.0 released

271 points by pajoda 9y ago

ainiriand 9y ago

It is not NPM, it is npm.

m_t 9y ago
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.
pajoda 9y ago
It should be npm, totally. I noticed it too late to edit, unfortunately.

vacri 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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.
  - ceejbot 9y ago
    This statement is false and has been since the very first work done on the npm cli. npm has, in every version of it that has ever existed, since before there was even a package registry, installed preferentially from its local cache of packages where possible.

k__ 9y ago

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 9y ago
It's been that way for years, since shrinkwrap was invented.
- k__ 9y ago
  Really? Does shrinkwrap work for transitive deps?
  - samtho 9y ago
    Yes, this is a huge selling point to the usefulness of npm-shrinkwrap.
    - k__ 9y ago
      Interesting. I thought yarn and ied were created because this didn't work with npm. -- edit -- Seems that npm shrikwrap -> npm i -> npm shrikwrap is not guaranteed to produce the same output.
- STRML 9y ago
  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.

andyfleming 9y ago

How does this stack up against yarn now?

pajoda 9y ago
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 https://twitter.com/passcod/status/860437637764571140). Even though npm still seems to be slower than yarn (https://docs.google.com/presentation/d/1re-AGrTOf4zmnXXDMTG1UIuce8gVClkoq0HyN0IhCyQ/edit#slide=id.p https://docs.google.com/presentation/d/1re-AGrTOf4zmnXXDMTG1...). At the end, I'd say it's about personal preference, they both get the job done.
- max23_ 9y ago
  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.
Thomaschaaf 9y ago
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 9y ago
  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 9y ago

>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 9y ago

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 9y ago
Why go back if you already migrated?
- romanovcode 9y ago
  - Global dependencies do not work on Yarn if you install node with brew. - NPM comes pre-installed with Node.
- cwmma 9y ago
  last I check certain features like bundledDeps didn't work on yarn
- abritinthebay 9y ago
  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.

eknkc 9y ago

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 9y ago
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 9y ago
  amen
ryanar 9y ago
If I recall correctly, npm5 with an existing node_modules folder still goes out to the internet and checks some data whereas yarn does not.
- abritinthebay 9y ago
  Yup, tho it's configurable and you can set --prefer-offline to true to avoid it
KayL 9y ago
my test: npm@5 28.274s vs 11.60s Yarn @Windows10, SSD, warn cache
9y ago

Achshar 9y ago

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

Thomaschaaf 9y ago
You should implement basic ci with travis et al. That commit should never be able to make it into master. If you are using Github you can force green tests before a pull request is mergeable.
- btown 9y ago
  Even if you don't have good test coverage, even having your CI just do a webpack build would likely catch that problem. Well worth it.
  - kukabynd 9y ago
    Considering it’s free it’s a non-brainer.
gear54rus 9y ago
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?
- vmasto 9y ago
  It is perfectly reasonable and avoids mistakes. It's better to have a module that's unused than to break your whole build. If you want to try something install it and then remove it. That's the more conscious decision. I don't want to have to remember to save the module if I end up liking it, but I will remember to remove it when tearing it down from the codebase, and if I don't, nothing bad happens.

chrisweekly 9y ago

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 9y ago
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.
- ultim8k 9y ago

floatboth 9y ago

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

Achshar 9y ago

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

kotojo 9y ago
npm install npm@5 -g. Latest still points at 4.x currently.
deleted 9y ago
[deleted]

shadowmint 9y ago

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.

Thomaschaaf 9y ago
npm install npm@next -g works :)
nailer 9y ago
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

synthecypher 9y ago

Its still not as fast as yarn FYI.

ashark 9y ago
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 9y ago
  what are these npm's features that yarn doesn't support?
  - ashark 9y ago
    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/3433 https://github.com/yarnpkg/yarn/issues/3507 https://github.com/yarnpkg/yarn/issues/3507 https://github.com/yarnpkg/yarn/issues/2090 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.

evolve2k 9y ago

> 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 9y ago
Or even package.lock.json
- evolve2k 9y ago
  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
deleted 9y ago
[deleted]
mstade 9y ago
It bothers me somewhat that they say this is standardized, but not by whom. Is the idea that Yarn should fall in line or is it a case of https://xkcd.com/927/ https://xkcd.com/927/ ?
qntmfred 9y ago
I'd rather my editor recognize a .json file and treat as such. I don't have a .lock convention

plexicle 9y ago

npm desperately needs a flat install option.

JeuelyFish 9y ago
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 9y ago
  Not naive, and that's pretty much the primary reason. But for all web components in general, not just the Polymer flavor.
  - JeuelyFish 9y ago
    gotcha, that makes sense. My only expose to web components was polymer. Thanks for the clarification
bluetech 9y ago
What does "flat install" mean?

mstijak 9y ago

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

felixrieseberg 9y ago

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

2manyredirects 9y ago

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 9y ago
Isn't npm shrinkwrap the npm "lockfile"?
- abritinthebay 9y ago
  Kinda. Shrinkwrap has been around for a while. The new lockfile is basically shrinkwrap 2.0 using what's been learned since

blitmap 9y ago

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.

swsieber 9y ago

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.

tomxor 9y ago

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

mderazon 9y ago

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

assafmo 9y ago

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