fix: do not update workspaces when applying new version

[KillianHmyd]

In npm@8 the command npm version added a new command workspaces-update which is true by default.
This option cause the following error when we install workspaces using non-released version (in this case the version 0.0.0-semantic-release) :

npm ERR! notarget No matching version found for package@0.0.0-semantic-release.

[travi]

can you provide more context around the situation where you are seeing this? i've never seen this error in projects that do not have workspaces defined. note that semantic-release core does not officially support monorepos. are you using something in addition to semantic-release to enable functionality within a monorepo?

[KillianHmyd]

Hello @travi, in my case we use yarn workspaces.
The issue is from npm@8 by default npm handles workspaces, so when running a npm version npm will tries to update the node_modules of all workspaces and the package-lock.json but because we use semantic-release the version we commit in our package.json is fake one (0.0.0-semantic-release) so when npm tries to update the dependency trees it fails to retrieve the 0.0.0-semantic-release version as it is no longer the version referred in our workspace (so by default it checks on NPM).

Adding the option --no-workspaces-update prevents npm to consider the workspaces

[travi]

in my case we use yarn workspaces

are you managing multiple packages in the same repository through the use of yarn workspaces? assuming so, what else are you using to make this work with semantic-release? semantic-release does not support that type of repository structure by itself

[KillianHmyd]

Yes we manage multiple packages and we use nx to run semantic-release in a mono-repo (cf their example).
But, please note that here, the issue would be the same even if only one workspace were managed by semantic-release. Here the issue is occurs as long as some workspaces are declared in a repository, even if they are not managed via semantic-release.

[KillianHmyd]

Hello @travi,
Will this PR be considered? Or do you plan to refuse?

[travi]

the use case is still being considered, but i do have concerns.

as mentioned above, semantic-release does not officially support monorepos, so this is technically outside of what we would normally consider. we do, however, unofficially want to enable other tools to build on top of semantic-release to enable specific support, but that still has to be balanced with additional maintenance cost the change would add to our workload long term.

it feels out of place to have semantic-release manage this flag that is specific to monorepos when the tool primarily targets non-monorepos. is there a reason why you could not configure this in the .npmrc for your project instead?

[KillianHmyd]

Hello @travi, sorry for the long delay from my side.
I didn't thought about it as I use yarn and not npm, I'll give it a try 😃

[KillianHmyd]

@travi Setting it in the npmrc fix well the issue 👍🏾 Thanks for the suggestion

[mario-jerkovic]

@KillianHmyd can you please share the content of your .npmrc, did you just wrote no-workspaces-update or ?

[hongaar]

@mario-jerkovic I was able to publish a monorepo with semantic-release using this .npmrc committed to the root of the project:

workspaces = true
workspaces-update = false

Make sure the root package doesn't have private: true which is common in monorepos, the plugin will skip the publish step in that case.