Publish unpublished packages

[joscha]

When trying to publish a package that hasn't been published before, I get a:

npm ERR! 404 
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.
npm ERR! 404 
npm ERR! 404  '@org/my-package@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
npm ERR! 404 tarball, folder, http url, or git url.

npm ERR! A complete log of this run can be found in:
npm ERR!     /github/home/.npm/_logs/2020-01-14T03_44_14_143Z-debug.log

    at checkExecSyncError (child_process.js:629:11)
    at execSync (child_process.js:666:13)
    at run (/github/home/.npm/_npx/11/lib/node_modules/merge-release/merge-release-run.js:55:17)
    at process._tickCallback (internal/process/next_tick.js:68:7)
(node:11) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:11) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

[mikeal]

Ya, i’m wondering if this is something that should work OOTB or if it’s just something that should be well documented. I’m a little apprehensive toward publishing to a brand new name without explicit user interaction but that apprehension may be unwarranted.

[joscha]

Fair. To me it was a bit surprising but I get your point. If the action wouldn't fail but print a warning/error instead it would be obvious. Also in a bigger org sometimes you set up actions for someone with less rights than yourself, in that case it means that in addition to setting up the npm token secret you also have to do the first build and publish of the package for them which is suboptimal.

[mikeal]

Cleaning up the behavior is a good idea.

I take your point about the permissions stuff, I’ll think on it some more.

[derryl]

I also ran into this error today – but it occurred while attempting to publish an existing package to a private registry. (It seems that I'm hitting the same catch block as @joscha, but for a different reason.)

Is it your intention only to support the official NPM registry? Or perhaps we could modify this line to read from pkg.publishConfig.registry if it has been defined in the project?

Cheers!

[mikeal]

Is it your intention only to support the official NPM registry?

Definitely not, and if that is the case it’s a bug for sure. However, it may still be the case that we don’t want to support initial publication to a any registry, still mulling this over though.

[mikeal]

Ok, this PR makes me think we definitely should not handle initial publishing since the public/private settings are then set and persisted in the registry and aren’t configurable by package.json.

[joscha]

I don't completely understand how these two things relate to each other - e.g. why the package visibility has any effect on whether we should publish an initial package via this plugin or not.

[mikeal]

The initial publish sets the default public/private setting for all subsequent publishes to that name in that registry. The “default” is different for scope and unscoped packages, that was why i had —public set to begin with (i personally have several public scoped packages), but that breaks private packages 😢

[joscha]

This rings a bell . Can this be handled with an npmrc by any chance?

…

On Tue, 21 Jan 2020, 04:59 Mikeal Rogers, ***@***.***> wrote: The initial publish sets the default public/private setting for all subsequent publishes to that name in that registry. The “default” is different for scope and unscoped packages, that was why i had —public set to begin with (i personally have several public scoped packages), but that breaks private packages 😢 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13?email_source=notifications&email_token=AABN5BTXVULVJSEOQTENJK3Q6XQ67A5CNFSM4KGMPW2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJNNT2Y#issuecomment-576379371>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABN5BTRZJ7KIBXGZECNQ6TQ6XQ67ANCNFSM4KGMPW2A> .

[mikeal]

I had expected it to be possible to set this somewhere in package.json but found that it’s not there and appears to be a setting in the registry and not local.

[joscha]

I think npm config set access public is all you need; that will create an .npmrc and any subsequent publish should respect it.
See https://docs.npmjs.com/configuring-your-npm-client-with-your-org-settings#setting-package-visibility-to-public-for-a-single-package

[vincerubinetti]

What is the prefered/cleanest way to handle this situation? Do we manually npm publish a version of our package -- say with a pre-release version like 0.0.1 -- then make an empty BREAKING CHANGE commit to publish 1.0.0?

[schalkneethling]

Ya, i’m wondering if this is something that should work OOTB or if it’s just something that should be well documented.

I definitely agree that it should be well documented and mentioned up front. It caught me by surprise as well, especially because the action actually completed successfully :/