[heft-storybook] Support storybook static build

[RongqiZ]

We want to use storybook static build files with the heft.
So I added this plugin into the build actions, and we could pass the static build module path.

This is the heft config after change:

{
      "plugin": "@rushstack/heft-storybook-plugin",
      "options": {
        "storykitPackageName": "@storybook/react",
        "startupModulePath": "@storybook/react/bin/index.js",
        "staticBuildModulePath": "@storybook/react/bin/build.js"
      }
    }

And this is the command in the package.json

"storybook": "heft start --storybook",
"build-storybook": "heft build --storybook",

So that in the local environment, developers could use storybook command to start the server to see the result.
In the CI, we could use the build-storybook command to build static files for visual regressions.

Test scenarios:

• only configured startupModulePath, and run with heft start --storybook
• startupModulePath & staticBuildModulePath configured, run with heft start --storybook
• startupModulePath & staticBuildModulePath configured, run with heft build --storybook

Summary

Details

How it was tested

Impacted documentation

[D4N14L]

@octogonz does this make sense to you? The idea is to be able to produce storybook assets alongside the webpack assets during a build, but not during start mode.

[iclanton]

@RongqiZ - Can you sign the CLA? #3843 (comment)

[RongqiZ]

[RongqiZ]

@RongqiZ please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@microsoft-github-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.
• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

Contributor License Agreement

@microsoft-github-policy-service agree [company="Microsoft"]

[RongqiZ]

@RongqiZ - Can you sign the CLA? #3843 (comment)

Sure, updated

[RongqiZ]

@microsoft-github-policy-service agree [company="Microsoft"]

@microsoft-github-policy-service agree [company="Microsoft"]

[RongqiZ]

@microsoft-github-policy-service agree company="your company"

@microsoft-github-policy-service agree company="Microsoft"

[elliot-nelson]

Very interesting! Where exactly does the static site get built in this model?

The way we have been structuring this internally is usually something like:

• apps/dynamite depends on libraries/dynamite-ui (which is a storybook)
• sandbox/dynamite-storybook depends on libraries/dynamite-ui
• libraries/dynamite-ui depends on libraries/dynamite-ui-storykit (for babel etc)

In this structure, the dynamite app actually uses the storybook UI and has its own deployment scripts (terraform or whatever), and the sandbox project also has its own deployment scripts, so that the storybook site can be deployed somewhere QA and other teams can play with it.

So the "storybook build" doesn't happen in the UI library, it happens in a separate project with its own dist folder.

I'm wondering if this PR would be compatible with this approach, so we could cut out of some of our custom scripts.