Np: ENEEDAUTH leaves repo in inconsistent state
I used np for the first time today on a new laptop where I (apparently) hadn't logged in to npm yet. The error message was :ok_hand:
dwade foss/gulp-snyk ‹master› » np
Publish a new version of gulp-snyk (0.0.2)
? Select semver increment or specify new version patch (0.0.3)
? Will bump from 0.0.2 to 0.0.3. Continue? Yes
✔ Prerequisite check
✔ Git
✔ Cleanup
✔ Installing dependencies
✔ Running tests
✔ Bumping version
✖ Publishing package
Pushing tags
Command failed: npm publish
npm ERR! Linux 4.4.0-47-generic
npm ERR! argv "/home/dwade/n/bin/node" "/home/dwade/n/bin/npm" "publish"
npm ERR! node v4.6.2
npm ERR! npm v2.15.11
npm ERR! code ENEEDAUTH
npm ERR! need auth auth required for publishing
npm ERR! need auth You need to authorize this machine using `npm adduser`
npm ERR! Please include the following file with any support request:
npm ERR! /home/dwade/foss/gulp-snyk/npm-debug.log
so I immediately knew to run npm login. But, to my surprise, np doesn't pick up where it left off, or roll back its changes on error
dwade foss/gulp-snyk ‹master› » np
Publish a new version of gulp-snyk (0.0.3)
? Select semver increment or specify new version patch (0.0.4)
? Will bump from 0.0.3 to 0.0.4. Continue? No
I finished the publish locally by hand (npm publish && git push origin --follow-tags) instead of using np.
doug-wade
All 5 comments
Imo, there are two approaches we could consider here:
1) Drop a file with the current state to disk on failure, and check for it on start up. For instance, in this case we might drop a .np.swp file that contains the target version, the created tag and the fact that "Publishing package" was the step that failed so that we can validate that package.json is still correct, git hasn't been overly tampered with, and then we can publish and continue.
2) Rollback the commit and delete the tag. In this case, a git reset --hard HEAD^1 && git tag -d v0.0.3 should do it.
In my humble opinion, while 1 is faster, 2 is the better option. In particular, if we were to implement option 1, then I'd still want to re-run the tests before publishing to make sure the user didn't tamper with anything else after the error was encountered that might break the module. The downside, though, is that you're deleting and re-installing node modules, which is not fast.
doug-wade
on 30 Nov 2016
I also think the second option is better, even having to install everything again.
I'd still want to re-run the tests before publishing to make sure the user didn't tamper with anything else
Exactly. Saving state in a .np.swp file only would make sense if the user just logs into npm and publishes right ahead.
gillchristian
on 29 Mar 2017
Btw this is related to #99
gillchristian
on 29 Mar 2017
201 fixes this, and is included in latest release of np
NeekSandhu
on 15 Dec 2017
Thanks for fixing this @NeekSandhu!
doug-wade
on 8 Apr 2018
Related issues
koppor
·
5Comments
gillesdemey
·
3Comments
sindresorhus
·
7Comments
dotconnor
·
4Comments
ProfessorManhattan
·
4Comments
Most helpful comment
Imo, there are two approaches we could consider here:
1) Drop a file with the current state to disk on failure, and check for it on start up. For instance, in this case we might drop a
.np.swpfile that contains the target version, the created tag and the fact that "Publishing package" was the step that failed so that we can validate that package.json is still correct, git hasn't been overly tampered with, and then we can publish and continue.2) Rollback the commit and delete the tag. In this case, a
git reset --hard HEAD^1 && git tag -d v0.0.3should do it.In my humble opinion, while 1 is faster, 2 is the better option. In particular, if we were to implement option 1, then I'd still want to re-run the tests before publishing to make sure the user didn't tamper with anything else after the error was encountered that might break the module. The downside, though, is that you're deleting and re-installing node modules, which is not fast.