CLI: Add command to generate annotations file

[yannbf]

Issue: N/A

What I did

The CLI now has a command to generate preset annotations file. This will get framework presets, addon presets and project annotation (preview.js) and write to a file that might look like this:

import * as frameworkPreset from "@storybook/react/dist/esm/client/docs/config";
import * as frameworkPreset2 from "@storybook/react/dist/esm/client/preview/config";
import * as addonPreset from "@storybook/addon-docs/dist/esm/frameworks/common/config";
import * as addonPreset2 from "@storybook/addon-actions/dist/esm/preset/addDecorator.js";
import * as addonPreset3 from "@storybook/addon-actions/dist/esm/preset/addArgs.js";
import * as addonPreset4 from "@storybook/addon-backgrounds/dist/esm/preset/addDecorator.js";
import * as addonPreset5 from "@storybook/addon-backgrounds/dist/esm/preset/addParameter.js";
import * as projectAnnotations from "./preview.ts";

export default [addonPreset, frameworkPreset, frameworkPreset2, addonPreset2, addonPreset3, addonPreset4, addonPreset5, projectAnnotations];

How to test

1 - Build CLI
2 - Use it locally with sb generate-annotations in a Storybook project

• Is this testable with Jest or Chromatic screenshots?
• Does this need a new example in the kitchen sink apps?
• Does this need an update to the documentation?

If your answer is yes to any of these, please make sure to include it in your PR.

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit a644602. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 1 target

• nx run-many --target=prepare --all --parallel=2 --max-parallel=15 -- --optimized

---

Sent with 💌 from NxCloud.

[shilman]

We should probably wait to merge this until #17755 is merged

[tmeasday]

Generally good! Some nitpicks

[shilman]

I'm unclear on the workflow here. Is the idea that the user will run this to generate an annotations file, and then will edit it down by hand to only include the pieces that they want? Based on our discussions I thought we concluded that typically users would build these files "constructively" by adding the minimal number of decorators etc. that they might need, rather than "destructively" by deleting. But maybe I misunderstood!

[shilman]

(oops one more dupe... 🤷 )

[shilman]

(oops duplicate)

[shilman]

(oops another duplicate?)

[yannbf]

I'm unclear on the workflow here. Is the idea that the user will run this to generate an annotations file, and then will edit it down by hand to only include the pieces that they want? Based on our discussions I thought we concluded that typically users would build these files "constructively" by adding the minimal number of decorators etc. that they might need, rather than "destructively" by deleting. But maybe I misunderstood!

Generally yes, but I thought we were going to get this PR in because it would make our experimentation easier?

cc @tmeasday

[shilman]

Works for me. I'm not enthusiastic about it, but I'm fine if it's convenient.

We can merge & re-address in 7.0 CLI refactor if needed

[yannbf]

@tmeasday after discussing more about this with @shilman we decided to keep this open until #17755 is resolved.

[github-actions]

	Fails
🚫	PR is not labeled with one of: ["cleanup","BREAKING CHANGE","feature request","bug","documentation","maintenance","dependencies","other"]

Generated by 🚫 dangerJS against a644602

[yannbf]

Closing this as might be too impactful for the changes we are planning to do in 7.0. If we ever want this again we can revive the PR.