7 ms·

Shame about npm5 being significantly broken, taking the wind of the node 8 sails. https://github.com/npm/npm/issues/16991 https://github.com/npm/npm/issues/169

Shame about npm5 being significantly broken, taking the wind of the node 8 sails. https://github.com/npm/npm/issues/16991 https://github.com/npm/npm/issues/16991

gcp 9y ago
How does npm5 compare to yarn? I didn't notice anything, but I'm using yarn everywhere, so...
- 0xptr 9y ago
  Speed wise npm@5 caught up a lot of ground. Iirc it was the same a while ago. However, I always felt like the release was a bit rushed. I sticked to Yarn too tho.
  - X-Istence 9y ago
    This is so completely and utterly wrong, unfortunately... Yarn takes 12 seconds to install all of our node_modules, npm@5 (latest) takes over 12 minutes. This made it completely and utterly untenable for our CI system, so we switched to yarn and shaved 12 minutes off our CI builds. It's been fantastic.
    - orf 9y ago
      That's got to be down to caching. What's the difference if the yarn cache is cleared?
      - X-Istence 9y ago
        25 seconds when the yarn cache is cleared... downloading is not the slow part here. Old results from about a month ago: https://twitter.com/bertjwregeer/status/887450964420055043 https://twitter.com/bertjwregeer/status/887450964420055043 npm 5.3.0: added 1991 packages in 538.289s yarn v0.27.5: Done in 58.42s.
        deleted 9y ago
        [deleted]
true_religion 9y ago
I have simply given up on NPM, after it broke my project multiple times. One of the bugs currently open references NPM deleting your dependencies. Another bug had NPM delete itself just by running `NPM install`.
tannhaeuser 9y ago
I was a bit disappointed about how npm5's new feature to install from a local cache works. You must initially populate the cache from a registry (npmjs.com or whatever) because it caches by HTTP ETags (as I understood by experimenting); merely installing from local .tgz files results in an empty cache. But the reason I wanted the ability to install from a prepopulated cache in the first place was that I had to work at a customer behind corporate firewalls and a private registry (Artifactory), where each and every external package package has to be vetted individually for license and security issues. Which kind of defeats the purpose given the excessive transitive package dependencies in npm-land (300+ packages for a basic webpack/babel/react setup, 500+ packages for building Bootstrap from source; and these figures are still comparatively low). In exchange, you get a new cache directory layout with directories named after autogenerated hashes, and "npm cache list" isn't supported yet :( But I'm not complaining; npm has certainly made progress, though it's still relatively slow.
- acemarke 9y ago
  I'm a big fan of Yarn precisely because it supports an "offline mirror" feature right now. In addition to caching downloaded packages globally, it can be configured to cache them in a local folder that can be committed directly to version control. That way, the local packages will be used when someone else clones the repo and installs things. I gave an example of using Yarn's offline mirror option in one of my "Practical Redux" tutorial blog posts: http://blog.isquaredsoftware.com/2017/07/practical-redux-part-9-managing-dependencies/ http://blog.isquaredsoftware.com/2017/07/practical-redux-par... .
pier25 9y ago
> npm link is weird right now This has been broken for almost 2 years now. https://github.com/npm/npm/issues/10343 https://github.com/npm/npm/issues/10343 It's unacceptable that the NPM team is moving so fast without looking back considering so many projects depend on it.
- littlecranky67 9y ago
  I understand their negligence, the fix for almost all npm link issues is to get a paid corporate npm account with private repositories.
gedy 9y ago
While I wish them success, npm-the-company has been a big disappointment. npm-the-tool is vital to NodeJS, and it's telling that big players in the industry had to bypass npm by releasing yarn.
- calafrax 9y ago
  who is backing yarn?
  - _ar7 9y ago
    facebook
  - grahamperich 9y ago
    Led by Facebook with support from Google, Tilde, and the Expo team.
hitgeek 9y ago
yes, npm5 is the first version I've had to rollback. its strange that the lockfile was supposed to fix problems with un-repeatable installs, but I had several issues fixed by simply deleting the lock file and re-installing.
- pier25 9y ago
  Yeah, at one point I was doing this many times every day. rm -rf node_modules && rm package-lock.json && npm install
- whatever_dude 9y ago
  Yeah I've had that too. My concern with the lock file is that it doesn't seem to be consistent across platforms (OSX and Windows) because of optional dependencies. I have a project with those (freaking fsevents) and every time I do npm install I it changes the lock file back and forth.
Androider 9y ago
NPM 5.x in Node v8.1 consistently only installs 481 out of 493 packages in our node_modules folder. No errors, everything looks absolutely fine, except 12 packages are straight up missing. That was fun to debug! Both NPM 3 and yarn produce the expected result. That was the last straw for me and NPM is now banned in favor of yarn.
- deleted 9y ago
  [deleted]
- Muuuchem 9y ago
  Lol mine has been oddly adding 1000 packages only sometimes when I npm install after a pull when we are using maybe 100 shits weird.
- mAritz 9y ago
  Same thing happened to me in multiple projects on multiple machines. Weird how that seems so common and still made it into v5.
- deleted 9y ago
  [deleted]
- whatever_dude 9y ago
  I actually had the opposite happening: a project was having some real issues with not installing proper dependencies until we started using npm 5.3+. Things work fine now and are a bit more deterministic it seems. It's an odd project with a lot of super strange peer dependencies, many of them in beta or as pre-releases, so I'm sure it's nothing that happens all the time (the joys of using React Native and Relay where everything is at an imaginary release state). But still glad npm 5 made it work consistently.
  - hinkley 9y ago
    Same. One team is running npm@3 installs twice in CI to pick up half a dozen modules that don't install the first time. On another project I managed to massage the package.json to stop it from happening.
bricss 9y ago
npm 5, prior version 5.3.0 was buggy, that's true. But now, it's working great for me and all my projects.
pluma 9y ago
Luckily there's still Yarn: https://yarnpkg.com/en/docs/install https://yarnpkg.com/en/docs/install Honestly it's great that npm 5 seemingly caught up with the speed of yarn but that only addresses one of many reasons I'm happy to have made the switch. Npm has been broken in exciting ways for years (and often in the same way for years -- see the infamous race condition in their tar implementation that broke npm publish at random).
- mercer 9y ago
  So, based on the history of NPM and its issues, is it too harsh to conclude that they don't really know what they're doing, and ditching it for Yarn is probably advisable on general? I mean, I consider myself a relatively novice programmer, so perhaps I'm underestimating the challenge involved, but I'm absolutely baffled that we ended up with 'the standard Node package manager' not being able to produce consistent results when setting things up in different environments. I mean, I've used Gemfile.lock for what feels like ages.
  - kevan 9y ago
    It's not too harsh, vote for better tools with your usage.
  - pluma 9y ago
    Saying NPM is badly designed is a bit simplistic. As much as I prefer yarn over NPM for all kinds of reasons, NPM's problems have more to do with being born out of a solo project that pre-dates most things we take for granted in Node today. There was no CLI argument parser, so Isaac wrote his own. There was no cross-platform tar bundler, so Isaac wrote his own. Not to mention that there just weren't any best practices in Node or JS for any of what NPM was trying to do yet. Yarn has the classic second mover advantage. The yarn devs learned from NPM's mistakes (there were more people involved than you see in the commit logs -- they even talked to some NPM people during development) and built on the vast ecosystem that exists now. I don't like npm Inc and I think there's a serious conflict of interest in having NPM bundled in the Node Foundation's official releases (people using the NPM client is in npm Inc's best interests, whereas Yarn isn't controlled by a single commercial entity). But blaming NPM's problems entirely on developer incompetence is unfair.
ilaksh 9y ago
I haven't run into any issues with the latest npm. I did run into issues with getting yarn to do a basic install.

Shame about npm5 being significantly broken, taking the wind of the node 8 sails. https://github.com/npm/npm/issues/16991 https://github.com/npm/npm/issues/16991

gcp 9y ago

How does npm5 compare to yarn? I didn't notice anything, but I'm using yarn everywhere, so...

0xptr 9y ago
Speed wise npm@5 caught up a lot of ground. Iirc it was the same a while ago. However, I always felt like the release was a bit rushed. I sticked to Yarn too tho.
- X-Istence 9y ago
  This is so completely and utterly wrong, unfortunately... Yarn takes 12 seconds to install all of our node_modules, npm@5 (latest) takes over 12 minutes. This made it completely and utterly untenable for our CI system, so we switched to yarn and shaved 12 minutes off our CI builds. It's been fantastic.
  - orf 9y ago
    That's got to be down to caching. What's the difference if the yarn cache is cleared?
    - X-Istence 9y ago
      25 seconds when the yarn cache is cleared... downloading is not the slow part here. Old results from about a month ago: https://twitter.com/bertjwregeer/status/887450964420055043 https://twitter.com/bertjwregeer/status/887450964420055043 npm 5.3.0: added 1991 packages in 538.289s yarn v0.27.5: Done in 58.42s.
      - deleted 9y ago
        [deleted]

true_religion 9y ago

I have simply given up on NPM, after it broke my project multiple times. One of the bugs currently open references NPM deleting your dependencies. Another bug had NPM delete itself just by running `NPM install`.

tannhaeuser 9y ago

I was a bit disappointed about how npm5's new feature to install from a local cache works. You must initially populate the cache from a registry (npmjs.com or whatever) because it caches by HTTP ETags (as I understood by experimenting); merely installing from local .tgz files results in an empty cache. But the reason I wanted the ability to install from a prepopulated cache in the first place was that I had to work at a customer behind corporate firewalls and a private registry (Artifactory), where each and every external package package has to be vetted individually for license and security issues. Which kind of defeats the purpose given the excessive transitive package dependencies in npm-land (300+ packages for a basic webpack/babel/react setup, 500+ packages for building Bootstrap from source; and these figures are still comparatively low). In exchange, you get a new cache directory layout with directories named after autogenerated hashes, and "npm cache list" isn't supported yet :( But I'm not complaining; npm has certainly made progress, though it's still relatively slow.

acemarke 9y ago
I'm a big fan of Yarn precisely because it supports an "offline mirror" feature right now. In addition to caching downloaded packages globally, it can be configured to cache them in a local folder that can be committed directly to version control. That way, the local packages will be used when someone else clones the repo and installs things. I gave an example of using Yarn's offline mirror option in one of my "Practical Redux" tutorial blog posts: http://blog.isquaredsoftware.com/2017/07/practical-redux-part-9-managing-dependencies/ http://blog.isquaredsoftware.com/2017/07/practical-redux-par... .

pier25 9y ago

> npm link is weird right now This has been broken for almost 2 years now. https://github.com/npm/npm/issues/10343 https://github.com/npm/npm/issues/10343 It's unacceptable that the NPM team is moving so fast without looking back considering so many projects depend on it.

littlecranky67 9y ago
I understand their negligence, the fix for almost all npm link issues is to get a paid corporate npm account with private repositories.

gedy 9y ago

While I wish them success, npm-the-company has been a big disappointment. npm-the-tool is vital to NodeJS, and it's telling that big players in the industry had to bypass npm by releasing yarn.

calafrax 9y ago
who is backing yarn?
- _ar7 9y ago
  facebook
- grahamperich 9y ago
  Led by Facebook with support from Google, Tilde, and the Expo team.

hitgeek 9y ago

yes, npm5 is the first version I've had to rollback. its strange that the lockfile was supposed to fix problems with un-repeatable installs, but I had several issues fixed by simply deleting the lock file and re-installing.

pier25 9y ago
Yeah, at one point I was doing this many times every day. rm -rf node_modules && rm package-lock.json && npm install
whatever_dude 9y ago
Yeah I've had that too. My concern with the lock file is that it doesn't seem to be consistent across platforms (OSX and Windows) because of optional dependencies. I have a project with those (freaking fsevents) and every time I do npm install I it changes the lock file back and forth.

Androider 9y ago

NPM 5.x in Node v8.1 consistently only installs 481 out of 493 packages in our node_modules folder. No errors, everything looks absolutely fine, except 12 packages are straight up missing. That was fun to debug! Both NPM 3 and yarn produce the expected result. That was the last straw for me and NPM is now banned in favor of yarn.

deleted 9y ago
[deleted]
Muuuchem 9y ago
Lol mine has been oddly adding 1000 packages only sometimes when I npm install after a pull when we are using maybe 100 shits weird.
mAritz 9y ago
Same thing happened to me in multiple projects on multiple machines. Weird how that seems so common and still made it into v5.
deleted 9y ago
[deleted]
whatever_dude 9y ago
I actually had the opposite happening: a project was having some real issues with not installing proper dependencies until we started using npm 5.3+. Things work fine now and are a bit more deterministic it seems. It's an odd project with a lot of super strange peer dependencies, many of them in beta or as pre-releases, so I'm sure it's nothing that happens all the time (the joys of using React Native and Relay where everything is at an imaginary release state). But still glad npm 5 made it work consistently.
- hinkley 9y ago
  Same. One team is running npm@3 installs twice in CI to pick up half a dozen modules that don't install the first time. On another project I managed to massage the package.json to stop it from happening.

bricss 9y ago

npm 5, prior version 5.3.0 was buggy, that's true. But now, it's working great for me and all my projects.

pluma 9y ago

Luckily there's still Yarn: https://yarnpkg.com/en/docs/install https://yarnpkg.com/en/docs/install Honestly it's great that npm 5 seemingly caught up with the speed of yarn but that only addresses one of many reasons I'm happy to have made the switch. Npm has been broken in exciting ways for years (and often in the same way for years -- see the infamous race condition in their tar implementation that broke npm publish at random).

mercer 9y ago
So, based on the history of NPM and its issues, is it too harsh to conclude that they don't really know what they're doing, and ditching it for Yarn is probably advisable on general? I mean, I consider myself a relatively novice programmer, so perhaps I'm underestimating the challenge involved, but I'm absolutely baffled that we ended up with 'the standard Node package manager' not being able to produce consistent results when setting things up in different environments. I mean, I've used Gemfile.lock for what feels like ages.
- kevan 9y ago
  It's not too harsh, vote for better tools with your usage.
- pluma 9y ago
  Saying NPM is badly designed is a bit simplistic. As much as I prefer yarn over NPM for all kinds of reasons, NPM's problems have more to do with being born out of a solo project that pre-dates most things we take for granted in Node today. There was no CLI argument parser, so Isaac wrote his own. There was no cross-platform tar bundler, so Isaac wrote his own. Not to mention that there just weren't any best practices in Node or JS for any of what NPM was trying to do yet. Yarn has the classic second mover advantage. The yarn devs learned from NPM's mistakes (there were more people involved than you see in the commit logs -- they even talked to some NPM people during development) and built on the vast ecosystem that exists now. I don't like npm Inc and I think there's a serious conflict of interest in having NPM bundled in the Node Foundation's official releases (people using the NPM client is in npm Inc's best interests, whereas Yarn isn't controlled by a single commercial entity). But blaming NPM's problems entirely on developer incompetence is unfair.

ilaksh 9y ago

I haven't run into any issues with the latest npm. I did run into issues with getting yarn to do a basic install.