Open joscha opened 4 years ago
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.
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.
Cleaning up the behavior is a good idea.
I take your point about the permissions stuff, I’ll think on it some more.
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!
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.
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.
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.
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 😢
This rings a bell . Can this be handled with an npmrc by any chance?
On Tue, 21 Jan 2020, 04:59 Mikeal Rogers, notifications@github.com 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 https://github.com/mikeal/merge-release/issues/13?email_source=notifications&email_token=AABN5BTXVULVJSEOQTENJK3Q6XQ67A5CNFSM4KGMPW2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJNNT2Y#issuecomment-576379371, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABN5BTRZJ7KIBXGZECNQ6TQ6XQ67ANCNFSM4KGMPW2A .
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.
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
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
?
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 :/
When trying to publish a package that hasn't been published before, I get a: