6 ms·

In the past few weeks: * NPM 6 stopped working with Node 4. Rather than actually fix it, they just left it broken for several days because it was already fixe

In the past few weeks: * NPM 6 stopped working with Node 4. Rather than actually fix it, they just left it broken for several days because it was already fixed in the upcoming release, and I guess they didn't want to do an emergency release: https://github.com/npm/npm/issues/20716 https://github.com/npm/npm/issues/20716 * There was a several hour period where you could publish packages, but then they would 404 when you tried to download the new version. * They switched to using Cloudflare on Friday, and broke Yarn in the process: https://mobile.twitter.com/jamiebuilds/status/1000198463269699584 https://mobile.twitter.com/jamiebuilds/status/10001984632696... * Somehow while switching to Cloudflare they blew away a bunch of the packages that had been published during the previously mentioned window. They also blew away all the versions of some packages. Last Friday night you couldn't 'npm install gulp'. Never gave any explanation for this: https://github.com/npm/npm/issues/20766 https://github.com/npm/npm/issues/20766 About a month ago there was a bug where npm would change permissions on a bunch of system files and render you entire system unusable in you ran it as root. But that was OK because the bug was on the "next" version of npm, not the one you'd get by installing 'npm install -g npm'... Except there was also a bug in the current version of npm that installed the next version of any package by default, so it did in fact blow up a bunch of machines. Now, apparently, they are a teapot.

tedivm 8y ago
I don't think it's fair to blame them for breaking yarn. The way yarn setup their "mirror" url and the way Cloudflare handles account security conflicted and broke down yarn. I really don't see how any team could have seen that coming, or how they should be responsible for people making creative use of their infrastructure. Everything else is legit though.
- mort96 8y ago
  Well, they could have though, "Will this large infrastructure change affect any of the tools which depend on our infrastructure?", set up a small test system using cloudflare, and then test a few tools (like Yarn) against the new system.
bartread 8y ago
And the real problem with all of this is that npm has become so ubiquitous that you can't get away from it if you're doing client side development (not even by switching to yarn). You simply have to endure it, and accept that every now and again, for reasons entirely beyond your control (and at a quite possibly very inconvenient moment) it's going to break. This really annoys me, but what can one do? At least it's fixed now.
- Arnavion 8y ago
  Vendor your dependencies, or host clones on infrastructure that you're responsible for.
  - bartread 8y ago
    Vendoring isn't ideal: it makes, for example, code-reviews a PITA, and you still have the problem of what to do when you upgrade or add a dependency. Then you're back to npm (or yarn). Granted, at much reduced frequency, but it's still there. Maybe we'll go down the clone route if the cost of npm issues becomes too high relative to the hassle and expense of maintaining our own.
    - numbsafari 8y ago
      One way to keep vendoring from causing nightmare code reviews is to keep updates to vendored components in their own release/branch/PR. Yes, there will be changes to your code to accommodate the updated packages, but it keeps it very focused so that the code review isn’t also trying to evaluate updates to business rules or functionality. If you are updating components along with business rule updates, then, yes, it’s going to complicate code review, regardless of vendoring.
    - acemarke 8y ago
      That's why I really like Yarn's "offline mirror" feature. It lets you cache the tarballs themselves locally. There's also a tool called `shrinkpack` that lets you do the same when working with NPM itself, but I'm not sure if it works right with NPM5/6. I wrote a post a while back about using Yarn's offline mirror: http://blog.isquaredsoftware.com/2017/07/practical-redux-part-9-managing-dependencies/ http://blog.isquaredsoftware.com/2017/07/practical-redux-par...

tedivm 8y ago

I don't think it's fair to blame them for breaking yarn. The way yarn setup their "mirror" url and the way Cloudflare handles account security conflicted and broke down yarn. I really don't see how any team could have seen that coming, or how they should be responsible for people making creative use of their infrastructure. Everything else is legit though.

mort96 8y ago
Well, they could have though, "Will this large infrastructure change affect any of the tools which depend on our infrastructure?", set up a small test system using cloudflare, and then test a few tools (like Yarn) against the new system.

bartread 8y ago

And the real problem with all of this is that npm has become so ubiquitous that you can't get away from it if you're doing client side development (not even by switching to yarn). You simply have to endure it, and accept that every now and again, for reasons entirely beyond your control (and at a quite possibly very inconvenient moment) it's going to break. This really annoys me, but what can one do? At least it's fixed now.

Arnavion 8y ago
Vendor your dependencies, or host clones on infrastructure that you're responsible for.
- bartread 8y ago
  Vendoring isn't ideal: it makes, for example, code-reviews a PITA, and you still have the problem of what to do when you upgrade or add a dependency. Then you're back to npm (or yarn). Granted, at much reduced frequency, but it's still there. Maybe we'll go down the clone route if the cost of npm issues becomes too high relative to the hassle and expense of maintaining our own.
  - numbsafari 8y ago
    One way to keep vendoring from causing nightmare code reviews is to keep updates to vendored components in their own release/branch/PR. Yes, there will be changes to your code to accommodate the updated packages, but it keeps it very focused so that the code review isn’t also trying to evaluate updates to business rules or functionality. If you are updating components along with business rule updates, then, yes, it’s going to complicate code review, regardless of vendoring.
  - acemarke 8y ago
    That's why I really like Yarn's "offline mirror" feature. It lets you cache the tarballs themselves locally. There's also a tool called `shrinkpack` that lets you do the same when working with NPM itself, but I'm not sure if it works right with NPM5/6. I wrote a post a while back about using Yarn's offline mirror: http://blog.isquaredsoftware.com/2017/07/practical-redux-part-9-managing-dependencies/ http://blog.isquaredsoftware.com/2017/07/practical-redux-par...