Best ways to deal with unexpected bugs in already published npm packages

Question

I'm working on an npm package, and I'm kind of new to this. I published version 0.1.0, but when I did, I saw that there was a bug that broke the entire package. I do not think that it is right to make a patch (v0.1.1) because that will leave v0.1.0 useless. (Or maybe I'm wrong?)

My question is: What's the best professional way of dealing with it?

I apologize if the answer is obvious but I don't see it. I'm pretty new to production and semantic versioning, and I want to learn this stuff by working on small projects and having them published as a package and make their Git repositories look professional; That is because I can't find a good solid source that I can learn from.

Answer 1

v0.1.0 being useless is far better than v0.1.0 working for some people and not for others depending on when they downloaded it. The whole point of versioning is avoid that confusion.

Once it's published you have an obligation to keep the version number meaning the same thing. Otherwise people have no way to know what they have.

Don't worry about how broken the version is. Worry about communicating clearly the importance of getting onto the next version.

Answer 2

To a package developer, even more so than your average library developer, prior versions don’t exist except insofar as you wish to avoid unnecessary breaking changes.

If version x-1 is broken, that is totally irrelevant to version x.

The current version should be your sole concern, once you have a new version, you should forget prior version as best you can.

Answer 3

Publish a fixed version, and issue a deprecation warning for the old one.

(Deprecation warnings should only be issued for severe issues, but "breaks the entire package" certainly qualifies)

And then, review your testing process and consider making changes to increase the chance to detect issues before release.