Not working with node higher than 0.10.23 with npm

[leftieFriele]

When running reggie-server on node versions higher than 0.10.23 which uses npm 1.3.21 it just fails silently.

npm http PUT http://localhost:8082/delegator/-/delegator-0.0.6.tgz/-rev/1-0
npm http 201 http://localhost:8082/delegator/-/delegator-0.0.6.tgz/-rev/1-0
npm http PUT http://localhost:8082/delegator/0.0.6/-tag/latest
npm http 201 http://localhost:8082/delegator/0.0.6/-tag/latest

When running node-reggie with version>0.10.23 I get this output, but the artifact isn't published:

npm http PUT http://localhost:8082/delegator
npm http 200 http://localhost:8082/delegator
+ delegator@0.0.7

When publish with reggie, everything works perfectly. I will look more into it, but this is definitely a bug.

[leftieFriele]

When running npm publish it runs a put request to /name: When using the reggie-client it sends the put request to /package/:name/:version

In the function handling /name: there is only an update in meta-data and nothing being uploaded, so that accounts for the file not being uploaded.

[leftieFriele]

@bajtos would it be a good solution to refactor the function handling /package/:name/:version and have the function handling /name: use that new function to store artifacts? I am not sure what the intentions were for the /name endpoint was to begin with, so I am curious if this would be a good solution or if it would break something else?

[bajtos]

Originally server.put('/:name') just updated the in-memory package metadata and waited for server.put('/:name/-/:filename/-rev/:rev') to upload the archive.

The npm client is sending the archive as part of the first request, probably via a multipart form. Rather that refactoring /package/:name/:version, which is handling the reggie protocol, I would refactor server.put('/:name/-/:filename/-rev/:rev'), which is handling the npm protocol. Or even better - refactor both of them to share the code dealing with tarball upload.

[leftieFriele]

Got it, thanks for reminding me there are two protocols at play. I will look at refactoring the npm protocol functions to use the same code for dealing with the tar-ball. I'll submit a pr once I figure out a way to test this in the server-api-test.

[leftieFriele]

@bajtos I have refactored the feature, but I am having a hard time trying to get the tests to pass. The change works perfectly when executing from the command line using npm or reggie. However when running the tests npm sends first a /:name request and then the request with the file... I can't seem to figure out why. https://github.com/leftieFriele/node-reggie/blob/npmprotocolbug/server.js

[bajtos]

Well, reggie comes with it's own copy of npm - see package.json: "npm": "~1.1.71"

I hate to say it, but neither me nor Mike has enough time to maintain reggie properly. You may want to try out Sinopia. It should work with the new npm versions and provides a partial mirror of the public npmjs registry, which means you can npm install both private and public modules from the same registry.

[q2dg]

I know it's hard, but maybe putting a note on README.md saying something like "Reggie's developers have'nt enough time to maintain it properly. You may want to try out Sinopia" could be a honest step, don't you think? Until things change...

[bajtos]

@q2dg yeah, that's reasonable. Would you mind submitting a pull request?

[talkingtab]

For those who might be interested in using reggie, I found that it works well with v0.12.3 with one small change. Install as usual, but edit package.json and remove the dependency for npm as well as the npm folder in node_modules. Then npm install npm --save, which adds back a dependency on the current version of npm. The point being that the version of npm used by reggie must match the version of npm being used to access reggie. +1 for reggie. I haven't used sinopia so I have no comparision, but reggie is an easy to use and simple tool.