4

Lately I have been experiencing that an jspm install more often then not results in a status 500 being returned by the server whenever @angular packages are being downloaded via NPM. I have tried everything:

  • Authenticate npm
  • try new registries
  • checked the npm status page

However, none of these could give me any clue why the angular packages sometimes fail, sometimes it's the one, next time it's the other... but always @angular packages... are these perhaps hosted on a google server that is behaving odd? Things seem to be OK before june 9...

JSPM doesn't seem to have a verbose mode, so its guessing if the server exposed some more information as to why it fails...

Also, not sure if this is the correct forum for this since it's the infrastructure for programming and not exactly programming questions...

Kind regards

Xabre
  • 1,292
  • 1
  • 11
  • 17
  • Are you including any **@angular2-material** packages? I ask cause I noticed the same this morning when adding their `2.0.0-alpha.5-2` packages (sometimes **@angular** would fail, other times **@angular2-material**). Just changed to `^2.0.0-alpha.5` and all seems fine (not sure why lol) – cesar Jun 13 '16 at 13:53
  • nope! Still occurs: [issue](https://github.com/jspm/jspm-cli/issues/1910) :( – cesar Jun 13 '16 at 14:00
  • Hi, I am not including the angular2 material packages, I even tried to minimize the amount of packages to just the bare minimal, but to no avail – Xabre Jun 13 '16 at 14:55
  • Yeah, I am getting it with simple `jspm install @angular...`. Waiting to see what becomes of the github issue. What a bummer – cesar Jun 13 '16 at 14:57

2 Answers2

1

For anyone who may happen upon this in the future; I will quote my answer from this issue :

Everything seems to work more often if you login to npm using npm login. I can now run jspm install. jspm needs some cli messages warning users about rate limiting on users who are not logged in to npmjs.

Login to npm and you will receive less 500 errors. The problem is seemingly on their side.

jake
  • 488
  • 10
  • 19
0

Well, as mentioned in the issue linked by jakeniemiec, it apparently was "npm making changes to their API, and breaking an API that the npm CLI tool does not itself directly rely on but that we do."

Although this answer probably doesn't hold much value for our children and grandchildren, I wish to inform that this specific case was due to that.

I think we indeed can learn from this to don't put too much trust on these kind of things, and always consider it falling away from under our feet so make sure the required libraries are also stored in your repository.

Xabre
  • 1,292
  • 1
  • 11
  • 17