Allow explicit private publish to prevent public publish prompt#497
Conversation
chinesedfan
left a comment
There was a problem hiding this comment.
I don't know whether setting publishConfig.access will prevent the prompt or not. So will keep silent for it and hope we can handle every prompt friendly in future.
About runPublish,
- Glad to see replacing
options.publish && !pkg.privatewithrunPublishas I commented. - But would not like extract it as
shouldRunPublish. The name is not consistent withrunTests,runCleanup. Considering we have no sufficient tests and the redundant logic is short, I prefer the conservative way.
itaisteinherz
left a comment
There was a problem hiding this comment.
LGTM 👍🏻 Thanks for working on this @kylemh!
|
@chinesedfan Have you tested this locally and can verify this works for you? (I haven't tested this out myself, but will hopefully get to it sometime in the next few days.) |
|
@itaisteinherz I didn't have an end-to-end package to test. Here are how I tested,
|
|
FWIW, I exported my own fork of this PR and am using it in a repository already. I know y'all ensure everything's perfect with PRs, but I needed it immediately 😂 |
|
Merging as this is ready IMO. Thanks again for working on this @kylemh 🙏🏻 |
|
Thanks! @itaisteinherz FWIW, I'm a little afraid of the wording with |
I agree it's a bit confusing, but it's also the terminology npm uses. In this case, I think adding a note to the readme would help avoid any confusion. If you're up for doing that and creating another PR, that would be great 😉 |
Fixes #496
This will enable private, Org-scoped packages to easily publish new versions of a package as part of a CI/CD process by preventing the prompt of publically publishing a package when
publishConfig.accessis explicitly set to'restricted'inpackage.json.Also "booleanified"
runPublish->shouldRunPublishand reduced the number of times the same boolean is re-defined.