8000 Add dry run option to CLI publish command · Issue #614 · changesets/changesets · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add dry run option to CLI publish command #614

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
raypatterson opened this issue Jul 13, 2021 · 12 comments · May be fixed by #669
Open

Add dry run option to CLI publish command #614

raypatterson opened this issue Jul 13, 2021 · 12 comments · May be fixed by #669

Comments

@raypatterson
Copy link

Affected Packages

  • @changesets/cli

Problem

  • It's not possible to verify the end to end publishing configuration without publishing

Proposed solution

[package manager] changeset publish --dry-run
@Andarist
Copy link
Member

This is a very good idea - I've actually lately created a duplicate of this issue: #645

I probably won't have time to work on this at the moment though. An implementation provided by the community would be awesome.

@dkozma
Copy link
dkozma commented Feb 28, 2024

@Andarist It looks like #669 can resolve this issue, and has been open for a bit, is there any way that can be merged in? It looks like all of the concerns in the PR have been addressed, unless I missed something.

@denbite
Copy link
denbite commented Apr 24, 2025

just wanted to drop a note here since this PR has been open for quite a while and it doesn’t look like it’s getting merged anytime soon

for anyone looking for a workaround to simulate a dry run in the meantime, here’s a solution that’s worked for me

pnpm changeset status --output sim.json

this command will create a sim.json file like the following

{
  "changesets": [
    {
      "releases": [
        {
          "name": "pkg-a",
          "type": "major"
        },
        {
          "name": "pkg-b",
          "type": "minor"
        }
      ],
      "summary": "Description",
      "id": "rotten-flies-butter"
    }
  ],
  "releases": [
    {
      "name": "pkg-a",
      "type": "major",
      "oldVersion": "1.3.1",
      "changesets": [
        "rotten-flies-butter"
      ],
      "newVersion": "2.0.0"
    },
    {
      "name": "pkg-b",
      "type": "minor",
      "oldVersion": "1.6.8",
      "changesets": [
        "rotten-cases-dance"
      ],
      "newVersion": "1.7.0"
    }
  ]
}

hope this helps someone 👌

@raypatterson
Copy link
Author

I've been using verdaccio

@Andarist
Copy link
Member

I'd like to understand the use case better before committing to this. What a dry run even is in this context? Could somebody write down what's the goal is and how it is different from calling changeset version?

@raypatterson
Copy link
Author

Thanks for the question and all the work on this tool @Andarist !

The dry run reports what will happen without actually doing anything.

Maybe this PR from the beachball tool could be a point of reference?

@shakiba
Copy link
shakiba commented Apr 25, 2025

Use case: similar to npm publish dry-run, to validate what would be published without actually publishing.

@Andarist
Copy link
Member

I just wonder how you want to use this because changeset version already applies all of the updates on disk and it doesn't publish to the registry. So how this is different from changeset version? 🤔

@cjpearson
Copy link

changeset version and changset status outputting to JSON have covered most of my needs.

However, we occasionally have issues where the version on npm doesn't match the version in the repository. (Typically if something failed in the publish job after pushing to npm) If it's not cleaned up, then a subsequent publish will try to create the release again but will skip pushing to npm because the version already exists there.

I also haven't used the npm functionality, but perhaps a publish dry-run would be able to catch this?

Another small benefit would be validating the tag creation without actually pushing to npm.

@raypatterson
Copy link
Author

@Andarist I guess this is more about publishing for me. I want to see a representation of what will be published to ensure everything is correct. I'm curious about the PR attached to this issue and whether people think it was the expected solution. #669 (comment)

@caseyisonit
Copy link

I'm working in a very complex, very old, messy mono repo with a bundle and individual component packages. I'm debugging our versioning and tagging. This feature would be massively helpful for working through my issues with the confidence that I won't actually publish anything, but also get useful outputs to work against. I'll be looking into the workaround suggested above since it's not likely this will get adopted.

@Andarist, can you share your hesitation about adopting a widely available NPM feature? You mentioned an external contribution would be welcomed since you didn't have time to work on this; it's been four years.

@devjiwonchoi
Copy link

I'd like to understand the use case better before committing to this. What a dry run even is in this context?

I think it likely shares the same purpose as the other CLI packages' --dry-run flag: to verify that changeset publish works without actually publishing to NPM.

My use case is that I'm adding changesets to a repository and want to verify that changeset publish works during the CI. However, I don't want to verify by publishing to NPM.

Could somebody write down what's the goal is and how it is different from calling changeset version?

It would differ from the changeset version because what I want is to verify if "NPM publish" worked, not "versioning the packages" worked.

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

Successfully merging a pull request may close this issue.

8 participants
0