-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
CLI: Instruct the correct auto-migration command #26515
Conversation
☁️ Nx Cloud ReportCI is running/has finished running commands for commit a2582ba. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 2 targetsSent with 💌 from NxCloud. |
const automigrateCommand = isPrerelease(versions.storybook) | ||
? 'npx storybook@next automigrate' | ||
: 'npx storybook@latest automigrate'; |
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.
If someone runs npx storybook@next upgrade
and after the upgrade someone wants to rerun the automigrations, shouldn't we just tell the users to call npx storybook automigrate
to run the local version? This makes the most sense to me. Because people might run a specific version of an upgrade like npx storybook@8.1.0 upgrade
and then the above commands again do not fit, because the user wants to run the automigrate
command from 8.1.0 and not from latest
or next
(If 8.1.0 doesn't match latest
or next
).
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 don't think that that's a great idea, we should optimize for the common cases.
Before this PR, the suggested command to run was always with @next
, this seems important to fix ASAP?
Because people might run a specific version of an upgrade like npx storybook@8.1.0 upgrade and then the above commands again do not fit
True, but it's not super common to happen?
There's possibly even more edge cases?
The code is also an exact copy of how we already this the exact thing somewhere else already:
storybook/code/lib/cli/src/doctor/index.ts
Lines 144 to 146 in d52adbb
const doctorCommand = isPrerelease(storybookVersion) | |
? 'npx storybook@next doctor' | |
: 'npx storybook@latest doctor'; |
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.
If a user runs a command to upgrade Storybook and it fails to upgrade, then if we tell them to run npx storybook <command>
that will use the non-upgraded version, a version we might not want, right?
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.
@yannbf I might be mistaken, but the migration summary isn't shown when the upgrade
fails. It should only tell the user that the automigrate
CLI can be re-executed when automigrations are skipped, but the upgrade itself was successful. Otherwise, only running the automigrate
command when the upgrade
fails doesn't make much sense. You don't know whether the correct dependencies are already installed or in which phase the upgrade failed.
@ndelangen, Can you elaborate on your concerns about why it isn't a good idea? I am not convinced by the arguments yet. The argument that things traditionally were already done in a specific fashion doesn't tell anything about the quality of an idea or why it is good or bad.
We explicitly worked on the idea to enable people to upgrade to specific versions of Storybook. So, we have already identified this use case as pretty important, and we want to acknowledge it and not treat it as an edge-case.
If next
is 8.4 and someone upgrades to 8.3
via npx storybook@8.3.0 upgrade
it is a terrible idea to run automigrations from 8.4.0
. I understand @yannbf argument, that 8.4 might have automigration improvement/fixes, which 8.3.0
doesn't have, on the other hand, the automigration scripts are versioned, and therefore they are coupled with the rest of Storybook's ecosystem in a particular point in time, opening the door for terrible bugs. Second, if Storybook 9 is published, and people upgrade from 7 to 8, should they run npx storybook@next automigrate
or npx storybook@latest automigrate
, which both point to a Storybook 9 version? I don't think that's what we want.
…n-cli CLI: Instruct the correct auto-migration command (cherry picked from commit 1726622)
Closes #26478
What I did
I re-used a solution also in used in the doctor command, to show the correct command-suggestion.
Checklist for Contributors
Testing
The changes in this PR are covered in the following automated tests:
Manual testing
I didn't test this myself manually.
Documentation
MIGRATION.MD
Checklist for Maintainers
When this PR is ready for testing, make sure to add
ci:normal
,ci:merged
orci:daily
GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found incode/lib/cli/src/sandbox-templates.ts
Make sure this PR contains one of the labels below:
Available labels
bug
: Internal changes that fixes incorrect behavior.maintenance
: User-facing maintenance tasks.dependencies
: Upgrading (sometimes downgrading) dependencies.build
: Internal-facing build tooling & test updates. Will not show up in release changelog.cleanup
: Minor cleanup style change. Will not show up in release changelog.documentation
: Documentation only changes. Will not show up in release changelog.feature request
: Introducing a new feature.BREAKING CHANGE
: Changes that break compatibility in some way with current major version.other
: Changes that don't fit in the above categories.🦋 Canary release
This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the
@storybookjs/core
team here.core team members can create a canary release here or locally with
gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>