fix: add --no-workspaces to npm whoami

[hongaar]

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

I've tried various alternative but each of them gave me an uncomfortable feeling and after reading through #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 #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]

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

[hongaar]

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

[jedwards1211]

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

[travi]

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]

@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 #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.