CLI: Add optional --dev and --no-dev options to storybook init CLI

[fastfrwrd]

Closes #25510

What I did

adds optional --dev and --no-dev options to the storybook init CLI.

• this option allows users of the init CLI to force the init workflow to conclude before running the dev server after initialization.
• this is still the default behavior when storybook init is run in CI or in the Storybook sandbox, although the option can also be used to override the behavior in those cases as well.
  • unfortunately, because Commander automatically initializes the boolean with the default value of true, and I couldn't override the default value from the negated --no-dev option, I was forced to add a --dev option with the correct defaults. see --no is bugged with default arguments tj/commander.js#2068 (comment) and Adding negative option makes Commander.js to return "true" when option is not specified tj/commander.js#979 for more on this topic.

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

as far as I could tell, there aren't automated tests for the init CLI?

Manual testing

Ran the sandbox as described. Additionally, I ran the following against a fresh create-next-app to test that the flag works as expected, that the default behaviors still worked as expected, and that the intersection of the defaults and the flags also worked.

$ > npx create-next-app

$ > node ../storybook/code/lib/cli/bin/index.js init
$ > node ../storybook/code/lib/cli/bin/index.js init --dev
$ > node ../storybook/code/lib/cli/bin/index.js init --no-dev

$ > CI=true node ../storybook/code/lib/cli/bin/index.js init
$ > CI=true node ../storybook/code/lib/cli/bin/index.js init --dev
$ > CI=true node ../storybook/code/lib/cli/bin/index.js init --no-dev

$ > IN_STORYBOOK_SANDBOX=true node ../storybook/code/lib/cli/bin/index.js init
$ > IN_STORYBOOK_SANDBOX=true node ../storybook/code/lib/cli/bin/index.js init --dev
$ > IN_STORYBOOK_SANDBOX=true node ../storybook/code/lib/cli/bin/index.js init --no-dev

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 b300ae3. 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 1 target

• nx run-many -t build -c production --parallel=3

---

Sent with 💌 from NxCloud.

[fastfrwrd]

since there is direct programatic usage of doInitiate in the sandbox task, and because of the Commander behaviors around boolean options mentioned above, I ended up needing to define the default behavior with the environment variables in two places (in the Commander program definition and in the task itself). If anyone has a better idea for this, let me know!