
NPM v4.0.0 - Jarlakxen
https://github.com/npm/npm/releases/tag/v4.0.0
======
octref
After using yarn for a week, I can't imagine going back to npm.

I use npm 90% for install, and yarn does this so much better.

Installs are 3-4 times faster. Output is minimal and readable (compared to
npm's wall of text that I never read). Packages are cached so I can work with
slow connections in coffee shops.

Sorry to be blunt, but I feel none of the release features gonna help my daily
usage of npm. How about actually fixing the tab completion, which has been
slow and broken forever?

~~~
scrollaway
I'm super excited to use yarn but, just a heads up, we hit this pretty severe
issue when setting it up for our projects:
[https://github.com/yarnpkg/yarn/issues/761](https://github.com/yarnpkg/yarn/issues/761)

~~~
po1nter
And if you are using npm & bower in the same project then this other issue is
a show stopper
[https://github.com/yarnpkg/yarn/issues/616](https://github.com/yarnpkg/yarn/issues/616)

~~~
ceejayoz
Out of curiosity, why use npm and bower in the same project?

~~~
joshstrange
Not op but I'll chime in. My team uses npm for our build tools and bower for
our frontend libraries (moment, chats, lodash, etc). Our re-write only uses
npm but at the time (and possibly even now) there were frontend libraries that
only provide bower packages and bower seemed like the right tool for the job
anyways.

~~~
gotofritz
It doesn't sound ideal having two tools that do pretty much the same thing,
you are just adding a potential extra point of failure. Migrating from bower
to npm is incredibly easy.

~~~
Sacho
How would you migrate libraries that are only on bower, not npm?

~~~
ceejayoz
How many of those are a) left and b) still maintained?

------
Hurtak
> Keep an eye out for npm@5 in Q1 2017. We're planning a major overhaul of
> shrinkwrap as well as various speed and usability fixes for that release.

So the most interesting part of npm4 release are the announced improvements
that are coming in npm5 :)

------
andrewvijay
Are the NPM guys working on a parallel download feature to speed things up?
Have they even noted it as a feature to be implemented? Speed and pkg locking
are the only two features that make me use yarn. If they were in npm then most
people wont worry about yarn at all I guess.

~~~
rhinoceraptor
I would think they would have to solve the deterministic installation problem
first.

------
Etheryte
> npm's default git branch is no longer `master`. We'll be using `latest` from
> now on.

Is there any reason to do this?

~~~
dictum
It's probably to prevent any association with slavery (i.e. "master" owns
_slaves_ )

(Personally, I think `latest` conveys the intended meaning with more clarity,
but I don't like the way Node/npm deals with language and community conduct)

~~~
Longhanks
Now that's just ridiculous.

This kind of thinking has no place in serious software development.

~~~
ceejayoz
"Spending 30 seconds renaming a branch saves us potential PR issues" is
somehow dangerous thinking?

~~~
joshstrange
They didn't say dangerous, they said ridiculous and it is a ridiculous guess.
I don't really agree with "This kind of thinking has no place in serious
software development." part but the assertion that the change is "probably to
prevent any association with slavery" is ridiculous.

~~~
ceejayoz
It's not a crazy assertion.

[https://github.com/django/django/pull/2692](https://github.com/django/django/pull/2692)

I don't see a reason to get all fussed about a terminology change that hurts
no one and prevents upset, though.

------
mseepgood
NPM is so Oct 10 2016.

~~~
coldtea
That attitude is so Javascript-shallow.

------
Lx1oG-AWb6h_ZG0
I'm glad for the relatively low amount of breaking changes this time. npm
prepare should be a nice addition (using prepublish for, e.g., installing
typings is such a non obvious hack).

That said, I'm still not certain about shrinkwrap excluding dev deps. I mainly
use it to ensure my build agent uses the same dependencies as my dev box, and
at a time when things like babel pull in a ridiculous amount of sub
dependencies, it really does not make sense to not lock down _all_ your
dependencies by default.

~~~
madeofpalk
The difference between regular dependencies and devDependencies is very blurry
with things like Webpack and Babel - they're not required at runtime but
they're responsible for significant amounts of runtime.

Luckily, npm shrinkwrap accepts a --dev option to include devDependencies

~~~
bsimpson
Ask yourself "will authors consuming my module need this dependency?". If not,
it's a development dependency.

If you're including pure-JavaScript artifacts in your npm releases, downstream
authors probably don't care about your Babel/Webpack configuration.

------
gableroux
npm search will at least return results now ahah. I didn't know about
[https://npm.im/npms-cli](https://npm.im/npms-cli) , sounds like a great
alternative. Thanks for sharing this release here :)

------
kolme
> npm scripts no longer prepend the path of the node executable used to run
> npm before running scripts. A --scripts-prepend-node-path option has been
> added to configure this behavior.

Why? That seems like a good default, something most people would need.

~~~
Hurtak
It's explained 2 paragraphs bellow

