CLI: Add --build-only option to start-storybook (useful to warm up the cache)

[kaelig]

Issues:

Related to Discussion #13737 (where I initially described the use-case)
Related to #13266
Related to #13789
Related to #13784

---

I’d like a deterministic way to warm up a reusable cache for start-storybook without needing to start the server (nor opening the browser), which ideally would ensure that the next time somebody runs start-storybook, the cache is picked up and it runs faster.

For example, in the proprietary equivalent to GitHub Codespaces we run internally at Shopify, a warm cache means reducing Storybook's boot time by 30s (from 1m to 30s).

This is close to --ci but without the server. It's also close to --smoke-test, but without outputting stats, and with properly working caches.

What I did

I added a new CLI option that intends to run everything a standard start-storybook would, but doesn't start the server.

How to test

Assuming yarn bootstrap ran successfully,

1. cd examples/cra-ts-examples
2. rm -rf node_modules/.cache/storybook
3. yarn start-storybook --build-only: should exit without opening a browser
4. yarn start-storybook: should run faster

[kaelig]

Before this goes into the mainline for the CLI, I'd love to hear feedback, I'm especially interested in thoughts on:

• whether this issue should be solved at another level of abstraction
• does the name --build-only convey the intent correctly?
• how to write integration tests for a new flag like this one?

[ghengeveld]

Just today I discovered we actually have an undocumented flag called --preview-url which will skip building the preview (it will use the provided URL as iframe URL, but you can omit the value). Combine that with --smoke-test and you'll have something that builds and caches (as of 6.2.0-alpha.20) the manager without bundling your stories. Can you try that and compare it to your approach?

[kaelig]

I confirm that yarn storybook --smoke-test --preview-url="" works with the latest alpha. Thank you!

Happy to close this PR, but this undocumented solution feels quite hacky and easily breakable. I'd appreciate a solution that feels more solid and that would end up being documented 🙏

[ndelangen]

@kaelig if the use-case is to "prep the cache for faster starts" then I think the cli flag should reflect that.

my suggestion: --prepare-manager-cache

[kaelig]

I'll close for now and revise when #13808 is out.