Contracting of version numbers

[JessicaMulein]

https://registry.npmjs.org/esprima-fb/2001.1001.0000-dev-harmony-fb

This specific package/version seems to end up in the toplevel sinopia package.json as

"2001.1001.0-dev-harmony-fb": {
"name": "esprima-fb",
"description": "Facebook-specific fork of the esprima project",
"homepage": "https://github.com/facebook/esprima/tree/fb-harmony",
"main": "esprima.js",
"bin": {
"esparse": "./bin/esparse.js",
"esvalidate": "./bin/esvalidate.js"
},
"version": "2001.1001.0-dev-harmony-fb",

it looks like Sinopia is altering the version number and shortening 0000 to 0

[rlidwka]

it looks like Sinopia is altering the version number and shortening 0000 to 0

It's semver normalization, according to semver, they are equivalent.

Does it cause any issues?

[JessicaMulein]

Well, we're seeing an error trying to get to that version (https://npm.oururl.com/esprima-fb/2001.1001.0000-dev-harmony-fb fails but https://npm.oururl.com/esprima-fb/2001.1001.0-dev-harmony-fb works)

We had someone trying to "npm install -g react-tools" and it was getting a 404 when it hit esprima-fb (which is a dependency) despite it being available upstream.

I'm aware the NPM client doesn't hit the version url normally, but my suspicion was the NPM client balked that the available version was with the 0 instead of the 000 it was looking for?

[rlidwka]

but my suspicion was the NPM client balked that the available version

No, npm is normalizing it as well, look at the random url of a non-existing package:

$ npm install blahblah@0000.000.00
npm http GET http://localhost:4873/blahblah/0.0.0

There is indeed two errors waiting to be fixed:

1. "version" field shouldn't be changed (as opposed to a key that can be changed)
2. we should respond to an original /esprima-fb/2001.1001.0000-... url

But I don't think it's causing any trouble.

[JessicaMulein]

I'll try to diagnose it some more, but we had a definite 404 problem with that particular package and I jumped at the first thing that seemed to make sense. I'll try to replicate it and tear it apart today. Thanks for your time!

update: it seems like this was a flukey failure that lead us to discover the normalized url issue when trying to debug and looking for version specific json blob. Several of us tried to replicate the original failure and were not able to and I think you're right that the version stuff probably isn't at fault.

[rlidwka]

It looks like npm registry is returning normalized versions now. If I look at the original url, it returns "2001.1001.0-dev-harmony-fb" everywhere.

So I don't believe Sinopia is actually changing anything. I might have been true in earlier versions, but I can't reproduce it with the latest one.

we should respond to an original /esprima-fb/2001.1001.0000-... url

This is now fixed in v0.6.2.

[JessicaMulein]

Thanks for always being so proactive and responsive. Enjoy your weekend!