[heft] Cannot CI storyshots-puppeteer due to roaming storybook ports

[DavidRieman]

Summary

Although we have a working 'heft start --storybook' script, this seems to use a random port each time. The --port nnnnn option is not available through heft, nor does there seem to be any way to build storybook to static files instead of starting the server.

Storyshots and storyshots-puppeteer can generate code and visual snapshots (respectively) of your Stories, but needs to know where to find the storybook (I believe either by using a static port or using path to static built files). Since neither of these seem to be available with heft storybook support, we seem to be blocked on using this technology ATM through rushstack.

Repro steps

• Having a working 'heft start --storybook' script.

• Look for ways to specify the port through heft.

• Look for ways to heft build storybook to static files.

  Expected result: Perhaps a way to specify --port nnnn or --port=nnnn after heft start --storybook? Perhaps a way to build storybook like heft build --storybook that produces static files instead of starting a server?

  Actual result: Could not find any support.

Details

N/A

Standard questions

Please answer these questions to help us investigate your issue more quickly:

Question	Answer
@rushstack/heft version?	latest (0.48.0)
Operating system?	Windows and MacOS
Would you consider contributing a PR?	Yes
Node.js version (node -v)?	14.19.0

[iclanton]

It'd be pretty straightforward to add the --port parameter to heft-storybook-plugin. Would you be interested in making that change?

This is where the --storybook parameter is defined: https://github.com/microsoft/rushstack/blob/main/heft-plugins/heft-storybook-plugin/src/StorybookPlugin.ts#L113-L118. Someone would just need to add a --port parameter next to that one (or maybe --storybook-port) and plumb it through here: https://github.com/microsoft/rushstack/blob/main/heft-plugins/heft-storybook-plugin/src/StorybookPlugin.ts#L219-L228

[DavidRieman]

Yeah I'll probably be working on this soon. Seems other technologies like percy/storybook will hit the same requirements. Personally I think static storybook output will be the more valuable of the port and static options; Never built storybook static before but if I understand it correctly, this will be more convenient to CI since it will mean less custom concurrency complexity is required. I'm thinking this could be specified like --storybook-static ./output/path

[DavidRieman]

Good news: Turned out the percy/storybook CLI chains the process of building Storybook into the process of capturing images, so I didn't need this after all for that tech. Bad news: As such, I no longer have a business justification for building this feature for the community and have to move on to other work. If for some reason I find time to pick this back up, I'll comment again.

[aramissennyeydd]

I just ran into a similar issue, sharing here in case someone comes across this in the future. I ended up using the undocumented SBCONFIG_PORT to override the roaming port. This worked for me in SB 6, but YMMV, it's expressly an internal option.