search

semantic-release / npm

:ship: semantic-release plugin to publish a npm package
MIT License
244 stars 114 forks source link

fix: add --no-workspaces to npm whoami #529

Open hongaar opened 1 year ago

hongaar commented 1 year ago

I'm using semantic-release with a monorepo which is not officially supported but discussed (e.g. https://github.com/semantic-release/semantic-release/issues/1688).

I've tried various alternative but each of them gave me an uncomfortable feeling and after reading through https://github.com/semantic-release/npm/pull/482 I settled with the seemingly simple option of only using semantic-release together with this .npmrc: 

workspaces = true
workspaces-update = false

There's currently one issue blocking me from using this approach. Executing npm whoami with the above .npmrc yields an error, described in https://github.com/semantic-release/npm/issues/470.

This issue could be resolved by modifying lib/verify-auth.js slightly:

-      const whoamiResult = execa('npm', ['whoami', '--userconfig', npmrc, '--registry', registry], {
+      const whoamiResult = execa('npm', ['whoami', '--userconfig', npmrc, '--registry', registry, '--no-workspaces'], {

The NPM docs mention:

Explicitly setting this to false will cause commands like install to ignore workspaces altogether

I have verified that this flag has no adverse effect, running it on monorepos and non-monorepos both with and without the flag yield the same output.

DerYeger commented 1 year ago

This would be a welcome change, as I'm also blocked by the current behavior.

hongaar commented 1 year ago

Since I use yarn for all my (mono)repos, I created semantic-release-yarn which supports monorepos natively

jedwards1211 commented 1 month ago

@travi @gr2m this seems like a good idea, is there anything I could do to help get this over the line?

travi commented 1 month ago

we are pretty strongly against adding code to core or official plugins that is specifically for projects that are monorepos. if someone would like to send us PRs, we are happy to better document workarounds like using npmrc, publishConfig in the package.json, or npm environment variables that can enable these sorts of things without changes to semantic-release. if someone knows a solution to this issue without adding a flag, please let us know.

adding things like this add extra complexity to the project that we have to maintain and not break over time that are only there for unsupported use cases. we have a hard enough time keeping up with the use cases we do officially support. we do try to avoid doing things specifically to prevent use in monorepos, but we do not support them officially so priority is very low if changes are needed to the official projects to enable that to work beyond what the community provides to extend the official projects.

jedwards1211 commented 1 month ago

@travi I see. As far as this issue goes, it seems like npm behavior is still wrong...waiting to hear confirmation from them that whoami shouldn't be able to work in workspaces.

FWIW, I've been using semantic-release for pnpm monorepos in my work for awhile now, without any special plugins. The only fix I needed to get it working was https://github.com/semantic-release/npm/pull/531, and I think that fix is justified even for single package repo use cases. (I didn't run into this issue because the workspaces npm config option isn't a requirement for working with monorepos.) The only thing that was really difficult was configuring the conventional-changelog tools to distinguish commits by subpackage scope. Their config format isn't as powerful as I'd like so it wasn't pretty, but I at least got it working.