-
Notifications
You must be signed in to change notification settings - Fork 651
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
Comments
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. |
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 {
"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 👌 |
I've been using verdaccio |
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 |
Use case: similar to npm publish dry-run, to validate what would be published without actually publishing. |
I just wonder how you want to use this because |
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. |
@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) |
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. |
I think it likely shares the same purpose as the other CLI packages' My use case is that I'm adding changesets to a repository and want to verify that
It would differ from the |
Affected Packages
Problem
Proposed solution
The text was updated successfully, but these errors were encountered: