6 ms·

NPM v4.0.0

113 points by Jarlakxen 10y ago

Lx1oG-AWb6h_ZG0 10y ago
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 10y ago
  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 10y ago
    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 10y ago
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 :)
octref 10y ago
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 10y ago
  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
  - octref 10y ago
    Yeah I wouldn't use it in production until it becomes more stable. However the team behind it seems to iterate really fast. Look at the issues fixed between public release and 0.16[0], which is only 7 days. [0]: https://github.com/yarnpkg/yarn/releases/tag/v0.16.0 https://github.com/yarnpkg/yarn/releases/tag/v0.16.0
    - amasad 10y ago
      I've been using it in production for a large app for the past week and it's been great. CI is faster, deploying is faster and dev is faster.
  - Etheryte 10y ago
    Likewise, can't wait for yarn to finish its growing pains, until then it's still npm.
  - po1nter 10y ago
    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 10y ago
      Out of curiosity, why use npm and bower in the same project?
      - joshstrange 10y ago
        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.
andrewvijay 10y ago
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 10y ago
  I would think they would have to solve the deterministic installation problem first.
kolme 10y ago
> 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 10y ago
  It's explained 2 paragraphs bellow
Hurtak 10y ago
> 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 :)
Etheryte 10y ago
> npm's default git branch is no longer `master`. We'll be using `latest` from now on. Is there any reason to do this?
- tachion 10y ago
  By quick glance at their repository branches, it doesn't seem like they're using any kind of dev/el/op branch what makes me think that their development might have been happening in master branch (mind, this is me guessing without any knowledge about NPM's development process, so I might be totally and utterly wrong) and this could lead to some issues from people, who would expect master to be always-correct-and-working branch with all the newest and possibly breaking changes happening somewhere else.
- dictum 10y ago
  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 10y ago
    Now that's just ridiculous. This kind of thinking has no place in serious software development.
    - ceejayoz 10y ago
      "Spending 30 seconds renaming a branch saves us potential PR issues" is somehow dangerous thinking?
      - joshstrange 10y ago
        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.
mseepgood 10y ago
NPM is so Oct 10 2016.
- coldtea 10y ago
  That attitude is so Javascript-shallow.

113 points by Jarlakxen 10y ago

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

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

octref 10y ago

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 10y ago
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
- octref 10y ago
  Yeah I wouldn't use it in production until it becomes more stable. However the team behind it seems to iterate really fast. Look at the issues fixed between public release and 0.16[0], which is only 7 days. [0]: https://github.com/yarnpkg/yarn/releases/tag/v0.16.0 https://github.com/yarnpkg/yarn/releases/tag/v0.16.0
  - amasad 10y ago
    I've been using it in production for a large app for the past week and it's been great. CI is faster, deploying is faster and dev is faster.
- Etheryte 10y ago
  Likewise, can't wait for yarn to finish its growing pains, until then it's still npm.
- po1nter 10y ago
  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 10y ago
    Out of curiosity, why use npm and bower in the same project?
    - joshstrange 10y ago
      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.

andrewvijay 10y ago

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 10y ago
I would think they would have to solve the deterministic installation problem first.

kolme 10y ago

> 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 10y ago
It's explained 2 paragraphs bellow

Hurtak 10y ago

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

Etheryte 10y ago

> npm's default git branch is no longer `master`. We'll be using `latest` from now on. Is there any reason to do this?

tachion 10y ago
By quick glance at their repository branches, it doesn't seem like they're using any kind of dev/el/op branch what makes me think that their development might have been happening in master branch (mind, this is me guessing without any knowledge about NPM's development process, so I might be totally and utterly wrong) and this could lead to some issues from people, who would expect master to be always-correct-and-working branch with all the newest and possibly breaking changes happening somewhere else.
dictum 10y ago
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 10y ago
  Now that's just ridiculous. This kind of thinking has no place in serious software development.
  - ceejayoz 10y ago
    "Spending 30 seconds renaming a branch saves us potential PR issues" is somehow dangerous thinking?
    - joshstrange 10y ago
      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.

mseepgood 10y ago

NPM is so Oct 10 2016.

coldtea 10y ago
That attitude is so Javascript-shallow.