yarn2 berry issues with updating the `yarn.lock`

[rburgst]

I am currently using this lib to release my packages in a mono repo using yarn berry.

The problem I have is that the semantic-release/npm plugin properly rewrites the package verisons however, it does not cause an update to the yarn.lock. I played around with configuring an /exec task that runs yarn install however, this also does not work since semantic-release/git only checks the modified files in the package path. Therefore, it cannot see modifications in the root yarn.lock file.

Therefore, the updated yarn.lock is never committed which causes build errors since yarn berry runs yarn install in CI via the -immutable flag automatically.

The only solution I can currently think of is running a yarn install+git commit on my own after MSR is done. It would be nicer if we could somehow get the root yarn.lock into the commit that bumps the version number.

[rburgst]

for all posterity who want to achieve something like this. This is my setup on how it now seems to work finally:

{
  "branches": [
    "master"
  ],
  "plugins": [
    [
      "@semantic-release/commit-analyzer",
      {
        "preset": "conventionalcommits"
      }
    ],
    "@semantic-release/release-notes-generator",
    "@semantic-release/changelog",
    [
      "@semantic-release/npm",
      {
        "npmPublish": false
      }
    ],
    [
      "@semantic-release/exec",
      {
        "prepareCmd": "YARN_ENABLE_IMMUTABLE_INSTALLS=false yarn install && git add ../../yarn.lock",
        "publishCmd": "yarn npm publish"
      }
    ],
    [
      "@semantic-release/git",
      {
        "assets": [
          "CHANGELOG.md",
          "package.json",
          "yarn.lock"
        ],
        "message": "chore(release): ${nextRelease.gitTag} \n\n${nextRelease.notes}"
      }
    ],
    [
      "@semantic-release/github",
      {
        "successComment": false
      }
    ]
  ]
}

[rburgst]

note that #43 still applies so the setup above will require that you download the "old version" of your packages from npm (or whatever other npm package repository you are using).

[antongolub]

Hey @rburgst,

Thanks for highlighting the issue. It seems like the suggested workaround is the only solution available right now.