Define registry and tag into plugin config?

[FezVrasta]

I'm using semantic-release-monorepo and I'd like to share the same publishConfig across all my packages.

Right now I have to define:

"publishConfig": {
  "registry": "my custom registry",
  "tag": "latest"
}

on each package.
It would be useful to have the ability to define the registry and tag properties in the plugin config so that they will be shared by all the packages.

Example:

  "release": {
    "publish": [
      {
        "path": "@semantic-release/npm",
        "registry": "registry here",
        "tag": "latest"
      }
    ],
  }

[pvdlg]

semantic-release-monorepo is not our project and we can't help with it.
At that point monorepo are not supported by semantic-release. See semantic-release/semantic-release#193 (comment). As explained over there semantic-release-monorepo doesn't support all monorepo scenario (namely commits triggering a release on one of the repo that is out of range for another repo) and therefore is not a solution we intend to support.

If you want to configure the tag or registry properties for multiple repo then you should use an .npmrc file in the parent directory.

This plugin rely on the npm CLI and the standard npm mechanism to retrieve configuration properties. All the npm properties should be handled via the standard npm configuration (.npmrc or package.json). The plugin options are reserved for things related to semantic-release or the release process.

I'm going to close this issue as the .npmrc is the recommended approach and there is no plans to accommodate to semantic-release-monorepo. If monorepo are eventually supported by semantic-release it would most likely be via an integration with Lerna as discussed in semantic-release/semantic-release/issues/193.

[FezVrasta]

Thanks for the reply, from my tests, your suggestion doesn't work.

My npmrc file defines the registry for the scope of my packages (@mycompany), and when I try to publish, it tries to use the public npm registry.
Maybe what you say could work if I defined the top level registry registry = xxx rather than @mycompany:registry = xxx, but this is not what I'm looking for.

I don't see why you should take actions to go against semantic-release-monorepo. I understand you don't want to actively support it, but if people are willing to contribute to your projects to improve its support what's wrong with it?

[FezVrasta]

After further tests, it seems to work only if the .npmrc file is in the same directory of the package that is being published. So I can't have a single .npmrc in the root of my monorepo and have all the packages read it.

My PR would be extremely useful.

For now I published my fork as semantic-release-monorepo-npm for anyone that may need this.

[pvdlg]

We use registry-auth-token to retrieve the registry configuration in lib/get-registry.js.
I checked and I can confirm that it retrieve the config from the first .npmrc file it find, starting from cwd and going up the directory tree.

If you have publishConfig.registry in your package.json that take precedence over any .npmrc file.

registry-auth-token relies on rc to read the .npmrc. There is the bug dominictarr/rc#101 which create an issue if you read the config multiple time from different directory. Maybe it has an impact.

Regarding semantic-release-monorepo, as explained in semantic-release/semantic-release#193 it's not a solution that allow to fully support monorepo. If we support monorepo in semantic-release we would do it properly and we would cover every cases. As with any project, accepting PR for new features implies to support them on the long run. That mean maintaining the code and supporting users. We don't want to take on that additional work load for a solution that is partial at best.
Actually in the last few weeks we had a large part of the issues open on semantic-release repos related to semantic-release-monorepo even though it's not our project and we don't support it.

That said, as mentioned in semantic-release/semantic-release#193 we are open to fully support monorepo and we'll happily accept contribution under the circumstances explained over there, basically a solution that will provide a full support and that would rely on Lerna rather than re-implementing Lerna features in semantic-release.

[FezVrasta]

Thanks for the reply, my PR was a 2 lines change, I doubt that would have added so much complexity to the codebase.

Anyway, the fork works just fine, I'll try to keep it up to date with this repo.

[pvdlg]

Well, just as a for info, the PR was really incomplete anyway, it would have miss:

• documentation
• tests
• Handling priorities for all combination of .npmrc, package.json and semantic-release in a sub-project and in the parent directory
• Handling all of those combination with the currentpkgRoot option

Handling all those case would have resulted in a way more complex changes. In addition, in the future we would have to make sure the config resolution for the registry is identical to the npm CLI resolution. So implementing that properly is not as simple as your 2 lines changes would suggest.