-
-
Notifications
You must be signed in to change notification settings - Fork 75
release plan helper command #808
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
release plan helper command #808
Conversation
I'd say let's give it a spin! THANKS for adding this :) I think it's missing the |
// Commit changes | ||
await commit(newVersion, workspace.path, workspace.name); | ||
|
||
// TODO : remove this after the script proves to work ok. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to take it slow and try it one by one first.
So the script will stop after a single package.
If that works you can simply remove these lines and it will do the whole batch.
forgot to mention explicitly Because packages with unreleased local dependencies are skipped you will need to run it multiple times. In theory I can let it bump dependency versions and continue from there. But I think it is better if it only releases things that were prepared by a human and doesn't start to alter and release packages on it's own. for example :
I can make it capable of this. The downside is that we will still need to alter a few things manually in between chunks of releases. It now stops at There are two error cases I am a bit worried about in this context :
1 : Over time we will find out if the script is dependable or not. If we are confident it is good we can make it do more. There is also not much difference between releasing 5 or 50 broken states. It will require cleanup either way. 2 : I think this will be extremely rare. |
Context :
We have a whole lot of packages and now that we are also authoring our own tokenizers and parsers the dependency graph can easily become complex.
Publishing everything is a lot of work when you have to get these things right consistently :
CHANGELOG.md
editWhat if we use the
CHANGELOG.md
as a signal to create and execute a release plan.Each
CHANGELOG.md
for an unreleased update has :Unreleased (patch|minor|major)
.Anything else is ignored.
When publishing you first run :
npm run release-plan --dry-run
.This will tell you :
When publishing for real you run :
npm run release-plan
.How it works :
CHANGELOG.md
file for eachThe
publish
sub process inherits stdio from the main process.So a prompt for 2FA will just be passed to you.
After all releases :
npm install
to update the lock fileThese changes are not committed to make it easier to review what has changes.
"up to date local dependencies" means that this package does not depend on another local package that needs to be released
Thoughts?