Problem with resolving pnpm's workspace:* references

[pyncz]

Hello there. I have an issue managing packages in pnpm monorepo if they have some references to the other workspace packages through aliases.

Let's say, there's a package called package2, and it has its workspace-peer in the dependencies:

package.json of package2

"dependencies": {
  "package1": "workspace:*",
}

After the publishing via semantic-release-monorepo, I receive following error trying to install package2 in some other project, as a result:

As I understand, the problem is that pnpm converts such "cross-dependency" references into regular deps within its publish command, but semantic-release doesn't.

Now, after the very first release, I replace these "workspace:*" references with actual freshly-released versions, and it works ofc... But it doesn't seem right.

Any advice?

[platojh]

a "hack" for those that also stumble upon this: I am using the following step for GitHub Actions to publish without the workspace being apart of the upstream dependency by removing it in each of the packages with sed:

      - name: Version Bump(s) and Publish
        env:
          GITHUB_TOKEN: ${{ secrets.REPO_TOKEN }}
        run: |
          find . -type f -name package.json -exec sed -i 's/workspace://g' '{}' \;
          pnpm -r --workspace-concurrency=1 exec -- \
          npx --no-install semantic-release -e semantic-release-monorepo

[pmowrer]

As I understand, the problem is that pnpm converts such "cross-dependency" references into regular deps within its publish command, but semantic-release doesn't.

As you point out, this has to do with semantic-releases publish command, which is not currently customized in semantic-release-monorepo. I would argue it is outside the scope of this plugin to cater to specific tooling configuration like pnpm - it would be in the domain of semantic-release-pnpm plugin. However, that plugin doesn't cater to monorepos so not sure where that leaves us.

Feel free to reopen if you have any ideas. In the meantime, @platojh's workaround should be sufficient?

[pmowrer]

Looks like there's an idea here: #132