CLI: Instruct the correct auto-migration command

[ndelangen]

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:

• stories
• unit tests
• integration tests
• end-to-end tests

Manual testing

I didn't test this myself manually.

Documentation

• Add or update documentation reflecting your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Checklist for Maintainers

• When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/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>

[nx-cloud]

☁️ Nx Cloud Report

CI 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 targets

• nx affected -t check -c production --parallel=8
• nx run-many -t build -c production --parallel=8

---

Sent with 💌 from NxCloud.

[valentinpalkovic]

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).

[ndelangen]

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';

[yannbf]

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?

[valentinpalkovic]

@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.