not available on npm about chai-immutable

[astorije]

Argh, that is really odd. For publishing both v0.3.0 and v1.0.0, I used the same method, which relies on Travis CI deployment after running npm version 1.0.0 && git push --follow-tags.

And as you can see at the end of https://travis-ci.org/astorije/chai-immutable/jobs/65006776:

Deploying application
+ [email protected]

Also:

$ npm search chai-immutable
NAME           DESCRIPTION                                           AUTHOR    DATE       VERSION KEYWORDS                      
chai-immutable Chai assertions for Facebook's Immutable library for… =astorije 2015-06-02 1.0.0   chai test assertions immutable

This is really odd... Does anyone have an idea of what happened here? I'll investigate, thanks for the report!

[seldo]

Huh. That is strange. Can you try bumping to 1.0.1 and publishing again. If you can, use npm publish -ddd and capture the output so if it happens again we can see what the publish output was.

[astorije]

@seldo I am publishing automatically following this guide. I wish the -ddd flag could be set in Travis CI directly :-/

I'll trigger v1.0.1 manually and hope that I can still using Travis CI to deploy v1.0.2+.

[astorije]

Actually, after looking around, it might be possible. I gave it a shot in my latest commit, we'll see when Travis CI kicks in.

[astorije]

Argh, it failed at the coveralls step as you can see here, for the same reason :-(

Well, nevermind, I published manually and it seems to have worked. Assuming I was right when making sure there is no sensitive information in the output, here it is:

$ npm -ddd publish
npm info it worked if it ends with ok
npm verb cli [ 'node', '/usr/local/bin/npm', '-ddd', 'publish' ]
npm info using [email protected]
npm info using [email protected]
npm verb node symlink /usr/local/bin/node
npm verb publish [ '.' ]
npm sill cache add args [ '.', null ]
npm verb cache add spec .
npm sill cache add parsed spec { raw: '.',
npm sill cache add   scope: null,
npm sill cache add   name: null,
npm sill cache add   rawSpec: '.',
npm sill cache add   spec: '/home/jeremie/perso/chai-immutable',
npm sill cache add   type: 'directory' }
npm verb addLocalDirectory /home/jeremie/.npm/chai-immutable/1.0.1/package.tgz not in flight; packing
npm verb tar pack [ '/home/jeremie/.npm/chai-immutable/1.0.1/package.tgz',
npm verb tar pack   '/home/jeremie/perso/chai-immutable' ]
npm verb tarball /home/jeremie/.npm/chai-immutable/1.0.1/package.tgz
npm verb folder /home/jeremie/perso/chai-immutable
npm info prepublish [email protected]
npm verb addLocalTarball adding from inside cache /home/jeremie/.npm/chai-immutable/1.0.1/package.tgz
npm sill cache afterAdd [email protected]
npm verb afterAdd /home/jeremie/.npm/chai-immutable/1.0.1/package/package.json not in flight; writing
npm verb afterAdd /home/jeremie/.npm/chai-immutable/1.0.1/package/package.json written
npm sill publish { name: 'chai-immutable',
npm sill publish   version: '1.0.1',
npm sill publish   description: 'Chai assertions for Facebook\'s Immutable library for JavaScript collections',
npm sill publish   main: 'chai-immutable.js',
npm sill publish   directories: { test: 'test' },
npm sill publish   scripts: 
npm sill publish    { 'check-style': 'jscs chai-immutable.js test/test.js',
npm sill publish      test: 'npm run check-style && mocha',
npm sill publish      coverage: 'istanbul cover _mocha',
npm sill publish      coveralls: 'npm run coverage && cat ./coverage/lcov.info | coveralls' },
npm sill publish   repository: 
npm sill publish    { type: 'git',
npm sill publish      url: 'https://github.com/astorije/chai-immutable.git' },
npm sill publish   keywords: [ 'chai', 'test', 'assertions', 'immutable' ],
npm sill publish   author: { name: 'Jérémie Astori' },
npm sill publish   license: 'MIT',
npm sill publish   bugs: { url: 'https://github.com/astorije/chai-immutable/issues' },
npm sill publish   homepage: 'https://github.com/astorije/chai-immutable',
npm sill publish   devDependencies: 
npm sill publish    { chai: '^2.3.0',
npm sill publish      coveralls: '^2.11.2',
npm sill publish      immutable: '^3.7.3',
npm sill publish      istanbul: '^0.3.14',
npm sill publish      jscs: '^1.13.1',
npm sill publish      mocha: '^2.2.5' },
npm sill publish   readme: '[![npm version](https://img.shields.io/npm/v/chai-immutable.svg)](https://npmjs.org/package/chai-immutable)\n[...]\n',
npm sill publish   readmeFilename: 'README.md',
npm sill publish   gitHead: '6242e9deb556f7cc587e537b1dbe1b9258468079',
npm sill publish   _id: '[email protected]',
npm sill publish   _shasum: '3f55f31acd3b9656a644aab79729bd97f4eb87e7',
npm sill publish   _from: '.' }
npm sill mapToRegistry name chai-immutable
npm sill mapToRegistry using default registry
npm sill mapToRegistry registry https://registry.npmjs.org/
npm sill mapToRegistry uri https://registry.npmjs.org/chai-immutable
npm verb publish registryBase https://registry.npmjs.org/
npm sill publish uploading /home/jeremie/.npm/chai-immutable/1.0.1/package.tgz
npm verb request uri https://registry.npmjs.org/chai-immutable
npm verb request sending authorization for write operation
npm info attempt registry request try #1 at 10:57:55
npm verb request using bearer token for auth
npm verb request id 263b01971a2fe95c
npm http request PUT https://registry.npmjs.org/chai-immutable
npm http 200 https://registry.npmjs.org/chai-immutable
npm verb request invalidating /home/jeremie/.npm/registry.npmjs.org/chai-immutable on PUT
+ [email protected]
npm info publish [email protected]
npm info postpublish [email protected]
npm verb exit [ 0, true ]
npm info ok 

@seldo , do you have any idea of what happened for version 1.0.0? Do you think it came from npm or Travis CI (the latter will prevent me to publish automatically, but I'd be surprised if such feature is and stays broken)? Finally, is there any way I can re-build the tarball? It would be very unfortunate to have versions that fail every now and then on the list of releases...

[ceejbot]

Hiya, I wanted to thank you for bringing this to our attention! What was happening was a race condition in the registry when identical versions of a package were being published at the same time from two different places. The first would succeed, the second would partly succeed and then fail at the end, and then roll back its work. In this case, it would end up rolling back the tarballs that the first publication had put into place, because they were for the same version.

We're now detecting this situation & not nuking the tarballs from the first, successful publish, so we think this won't bite you again. Thanks again for telling us-- it was staring at the logs from the publications of chai-immutable that helped us figure it out.

[astorije]

Waouh @ceejbot that was nasty!
I am very happy my tiny contribution to the Node/npm world could be useful to you in its way.

Last question before I close this ticket: Is there any way to regenerate the v1.0.0 ([from the according tag], for example)? If so, I'll be glad to follow your instructions if there is something I can do on my end. If not, please advise me of the procedure to follow (unpublish v1.0.0?) to avoid confusing potential users.

Thanks!!

[ceejbot]

I would suggest that you unpublish the version and just move forward by bumping the patch number. Versions are immutable in the registry, so there's no way to replace an existing published version with new data. Instead, just let semver help you here: if you have published 1.0.1, then anybody trying to install chai-immutable at ^1.0.0 will get 1.0.1, and that should have the result they want.

[astorije]

Aaarrrrggghhh! What an unfortunate outcome:

$ npm unpublish @1.0.0
- [email protected]

Well, I guess [email protected] is the new cool then...

[ceejbot]

My apologies for the inconvenience! It was definitely our bug :(

[astorije]

Oh no @ceejbot I wasn't grumping at you, I was grumping at me :-)
As you can see, here, I just unpublished v1.01 instead of v1.0.0 by running npm unpublish @1.0.0 instead of npm unpublish [email protected].

Just my two cents though, this seems like a behavior you would not expect (cf my terminal paste above)...

[astorije]

@ceejbot, do you mind taking a look at #17? It's so close to this issue and I'd like to know if it's a coincidence that I got bitten twice... Thanks!

[astorije]

Nevermind.