FYI: npm publish errors

[semantic-release]

FYI: npm publish errors

[travi]

Seems similar to issues I've seen in the past: #54

[pvdlg]

Duplicate of #658

Duplicate of #54

See npm/npm#19763

[pvdlg]

I'm not sure whether it's appropriate for semantic-release to implement a workaround for this, but ideally it would continue with the release somehow.

semantic-release stop on error and doesn't attempt following publishing on purpose. This design choice has been made:

• To prevent as much as possible to make releases that might have an issue (if a publish step fails it might indicate a problem with the content of the release)
• To limit the number of release to rollback when a problem happens (if a release fails on a given platform, the user will most likely rollback the one that worked to avoid partial/inconsistent releases)
• Because some publish step might depends on previous one

What would be the purpose of proceeding with the publish steps after one fails? What's the point of having a release done on one platform but not the other?

[travi]

I consider unpublishing a bad practice, so I try not to unpublish something that has been published (i actually wish npm would remove even the short unpublish window). My solution when this happens is to manually do the steps on GitHub rather than unpublish from npm. Not ideal since i haven't taken the time to figure out if there is a simpler way to handle this when it happens.

Still comes down to if the effort is worth it, but if it is, i think npm dist-tags ls has been reporting correctly after such a failure. That might be a reasonable sanity check in failure cases to see if the error was because of a real failure or a failure to report success. If it's just a failure to report success, it seems reasonable to me to still continue. This would at least reduce how often this actually impacts the result of what is published by semantic-release.

[pvdlg]

My solution when this happens is to manually do the steps on GitHub rather than unpublish from npm.

That works in that case because the npm package is actually published. But in situation where there is a real failure, I don't think it's a good idea to proceed with other releases.

Still comes down to if the effort is worth it, but if it is, i think npm dist-tags ls has been reporting correctly after such a failure. That might be a reasonable sanity check in failure cases to see if the error was because of a real failure or a failure to report success. If it's just a failure to report success, it seems reasonable to me to still continue. This would at least reduce how often this actually impacts the result of what is published by semantic-release.

Yes, but I'm afraid that if we start doing these type of workaround we'll have to do many more for every other potential bugs in the npm CLI. My experience developing an integration with npm (for semantic-release) is that the CLI and the registry have a lot of instabilities and non-systematic issues. On the other hand the npm repo as more than 2000 issues opened, so those bugs might not be fixed anytime soon. I though about using yarn as a replacement but a lot of those issues seems related to the registry.

If the workaround you describe would be developed it should be in the npm CLI or the registry. I tried to see if I could open a PR for that but I got discouraged by the lack of readability and the difficulty to figure out what does what in the npm source code.

[pvdlg]

Closing as it's an issue in npm and there is nothing we can do.
If we were to do something it would be to implement a mechanism to recover from a partial release. See semantic-release/semantic-release#896