404 error when the package has not been released

[dagda1]

I was having a quick look on my monorepo and I got a 404 error when running npm covector publish because it came across a package that had not been published yet.

npm view returns a 404 in that case

Checking if @cutting/[email protected] is already published with: npm view @cutting/tsconfig version
npm ERR! code E404
npm
ERR! 404 Not Found - GET https://registry.npmjs.org/@cutting%2ftsconfig - Not found
npm ERR! 404
npm ERR! 404 '@cutting/tsconfig@latest' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404
npm ERR! 404 Note that you can also install from a

[jbolda]

Ah! Thanks for this. I was just chatting with someone what the error was if it hadn't been published yet. The workflow I have been recommending is publishing a 0.0.0 if it is a completely new package and setting your version to that. Then apply the appropriate patch / minor to your first release.

Looking at your error though, that version number seems to imply is has been published before?

[dagda1]

No, that was actually a dodgy copy and paste. That package has not been published.

Would the workflow not be to just publish it if it does not exist or why would you need 0.0.0 to be there?

[jbolda]

(If you have the non-dodgy version, would be nice for future reference.)

We are checking if it has been published and if it hasn't then run the publish for it. I believe with npm it fails and exits if the package does not exist yet, but doesn't exit if the package exists but that specific version number does not. (Working off of memory here.)

I think there is probably room for better DX here, but I have been careful to address it as accidentally publishing something that the user doesn't want to be published is a pretty bad first use outcome. I think we would need to figure out how to circumvent or have a separate logic path just for the first publish. So the easy answer thus far was 0.0.0 and no special cases.

[dagda1]

been careful to address it as accidentally publishing something that the user doesn't want to be published is a pretty bad first use outcome

That is actually a very good point and I had not thought of that. Maybe just some warning or error message is the right thing here. Publishing 4.2.0 here would definitely not be the right thing to do

[cowboyd]

What if you published to a target and the "dry-run" target was the default?

That way, when you ran publish in your CI script you might say --target npm, but if you ran without, it would just tell you what it would have done.

[jbolda]

What if you published to a target and the "dry-run" target was the default?

That way, when you ran publish in your CI script you might say --target npm, but if you ran without, it would just tell you what it would have done.

Hmm, I think we need to expand upon the idea of publish targets. @taras and I were chatting about this yesterday. We can abstract over the config for all of the standard situations, and rely on the config for the advanced use cases.

Side note that this is a duplicate of #152, but keeping them both open since they have good information.