Skip to content

Publishing does not replace yarn workspace:* version #246

Description

@emmenko

Hi 👋

I started using the workspace: protocol in one of my repos but noticed that when publishing the version didn't get replaced, ending up with a broken release.

image

Is this a known issue? Is there anything that I'm missing that I need to configure?

Thanks


I'm using Yarn v3.

My github action is configured like this:

- name: Creating release pull request or publishing release to npm registry
  id: changesets
  # uses: changesets/action@v1.3.0
  uses: dotansimha/changesets-action@v1.3.3
  with:
    publish: yarn changeset publish
    version: yarn changeset:version-and-format
    commit: 'ci(changesets): version packages'
    createGithubReleases: aggregate
    githubReleaseName: v${{ steps.release_version.outputs.VALUE }}
    githubTagName: v${{ steps.release_version.outputs.VALUE }}
  env:
    GITHUB_TOKEN: ${{ secrets.RELEASE_GITHUB_TOKEN }}
    SKIP_POSTINSTALL_DEV_SETUP: true

My Changesets config is configured like this.

Activity

  1. trivikr commented on Jan 30, 2023

    @trivikr
    Contributor

    Looks like this issue was reported earlier, but no response:

  2. Andarist commented on Jan 31, 2023

    @Andarist
    Member

    This is being fixed by changesets/changesets#674 - unfortunately, I couldn't find time to finish that work.

  3. mkurapov commented on Mar 24, 2023

    @mkurapov

    @emmenko does it work if you replace "package": "workspace:*" with the actual version of the workspace dependency, ie: "package": "workspace:1.0.0"? Changesets should end up bumping the workspace dependency version automatically when running changeset version, e.g. "package": "workspace:1.0.1"

  4. adesso-os commented on Mar 25, 2023

    @adesso-os

    When you specify the actual version number, then that version number is pulled during installation and placed into node_modules. Usually, developers don't want that. They want the actual project from the other workspace linked into NM. That is what workspace:* provides, but then changesets breaks.

  5. mkurapov commented on Mar 29, 2023

    @mkurapov

    @adesso-os

    then that version number is pulled during installation and placed into node_modules

    This is true for "package": "1.0.0", which will install from the registry, but it should still be linked locally if using the workspace protocol (while specifying a specific version), eg. "package": "workspace:1.0.0". (unless I'm misunderstanding here)

  6. unional commented on Jun 4, 2023

    @unional

    workspace:^

  7. arthurfiorette commented on Oct 10, 2023

    @arthurfiorette

    Hey folks! I could get everything working fine by using this custom release script:

    "ci:publish": "pnpm publish -r --access public && changeset tag",

    In case someone actually wants to see it in action:

    https://github.com/kitajs/kitajs/blob/e96dc95033e58c9a3a49ab8246ebc085b83a937b/.github/workflows/main.yml#L59
    https://github.com/kitajs/kitajs/blob/e96dc95033e58c9a3a49ab8246ebc085b83a937b/package.json#L21

    workspace:^, dependencies, scoped packages and github releases are working 🙏.

  8. arthurfiorette commented on Mar 20, 2024

    @arthurfiorette

    UPDATE: This is how I made publishing in PNPM work with prereleases publishing to a custom npm tag.

    In package.json, define your publish script using a $PUBLISH_TAG env var:

    {
      "scripts": {
        "ci-publish": "pnpm publish -r --access public --tag $PUBLISH_TAG && changeset tag",
        "ci-version": "changeset version && pnpm install --no-frozen-lockfile"
      }
    }

    Then in your workflow, resolve the tag and pass it as an environment variable:

    - name: Resolve publish tag
      id: publish-tag
      uses: actions/github-script@v8
      with:
        result-encoding: string
        script: |
          const fs = require('fs');
          try {
            return JSON.parse(fs.readFileSync('.changeset/pre.json', 'utf8')).tag;
          } catch {
            return 'latest';
          }
    
    - name: Create Release Pull Request or Publish
      id: changesets
      uses: changesets/action@v1
      with:
        version: pnpm ci-version
        commit: 'chore: update versions'
        title: 'Release plan'
        publish: pnpm ci-publish
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        NPM_CONFIG_PROVENANCE: true
        PUBLISH_TAG: ${{ steps.publish-tag.outputs.result }}

    The github-script step reads .changeset/pre.json and returns the tag (e.g. next), or falls back to latest if you're not in prerelease mode. The PUBLISH_TAG env var is then consumed by the ci-publish script. This avoids inlining commands directly in the publish field, which doesn't work reliably with multi-line values.

    Btw, don't try to inline the scripts, this action does not support && syntax and will fail during release.

  9. mattfysh commented on Jun 23, 2024

    @mattfysh

    why does the changeset tool only half-work with the workspace protocol? i.e. bumps during version but doesn't support a subsequent publish?

  10. davtha-aa commented on Nov 17, 2025

    @davtha-aa

    I am using yarn@4.5.0 and getting workspace published with workspace:*

    Installing package that has been published.

    npm i
    npm error code EUNSUPPORTEDPROTOCOL
    npm error Unsupported URL Type "workspace:": workspace:*

    GitHub Action

    - uses: changesets/action@v1
       with:
         version: yarn changeset version
         publish: yarn release

    My release script in root package.json:

    {
       "release": "turbo run build && changeset publish"
    }

    The version PR creation and Publishing works well. Just this last step of workspace:* not being resolved to actual versions.

  11. tianyingchun commented on Nov 26, 2025

    @tianyingchun

    This problem has existed for a long time, and no one has gone to fix it.😂

  12. changed the title [-]Publishing does not replace `workspace:*` version[/-] [+]Publishing does not replace yarn `workspace:*` version[/+] on May 15, 2026
  13. added theissue type on May 15, 2026
  14. bluwy commented on Jun 25, 2026

    @bluwy
    Member

    I'm going to close this as this is a core changeset issue now using yarn to publish. I understand that it's frustrating that it's still not resolved today, but we're starting some work again at changesets/changesets#2097 that should help with this. See also changesets/changesets#674 for the previous PR with links to issues of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions