Allow tracing changed files to affected story files CH-1205 CH-1393

[ghengeveld]

Depends on https://github.com/chromaui/chromatic/pull/5786

This adds a trace utility and the --trace-changed flag which print a tree visualization of how changed files relate to (bundles containing) affected story files:

Adding the --expanded flag to trace or setting --trace-changed=expanded reveals underlying modules:

npx chromatic trace [...changed file paths] operates on a provided stats file (--stats-file, default storybook-static/preview-stats.json) and provided list of changed files. Alternatively, you can pass the --trace-changed flag to the regular CLI to print this info as part of the Chromatic build (possibly combined with --dry-run).

[linear]

CH-1205 Add full tracing of how a changed file leads to CSF in `stats-to-story-files`

Using a tree-like UI perhaps?

[tmeasday]

This is great, a couple questions:

1. I think maybe you could add some tests to the getDependentStoryFiles just checking the tracedPaths end up looking as we expect? Perhaps the existing tests would work well here?
2. In terms of testing the UI of the traced paths, it might be nice to have at least one test that will ensure we notice if it breaks (I'm not super worried about the specifics of the UI, but we could do stories?)
3. I'm confused about trace vs stats-to-story-files -- are they doing the same thing?

[ghengeveld]

1. I think maybe you could add some tests to the getDependentStoryFiles just checking the tracedPaths end up looking as we expect? Perhaps the existing tests would work well here?

Makes sense. I'll extend one/some of the existing tests with traceChanged and verify the output. Perhaps a Jest snapshot test makes sense for this 🤔

2. In terms of testing the UI of the traced paths, it might be nice to have at least one test that will ensure we notice if it breaks (I'm not super worried about the specifics of the UI, but we could do stories?)

I think the snapshot test for 👆 would cover breakage. We can do a story for the visual side of it but it would require some refactoring to extract the (visual) text from the code into messages (components). At first I didn't think it was necessary because it was just a util, but now that it's also a flag, we should give it the proper UI treatment.

3. I'm confused about trace vs stats-to-story-files -- are they doing the same thing?

They both call getDependentStoryFiles and take roughly the same arguments, but their output is different. Basically stats-to-story-files is a compact version of trace. Do you think we should drop stats-to-story-files in favor of trace? Perhaps we can add a compact mode (similar to expanded) which essentially gives the output of stats-to-story-files. In an earlier version, stats-to-story-files actually returned JSON. Do you think that's worthwhile to have?

[tmeasday]

Perhaps we can add a compact mode (similar to expanded) which essentially gives the output of stats-to-story-files.

I agree that seems like a good idea

Do you think that's worthwhile to have?

JSON output? AFAIK that's not used anywhere so I guess not.

[linear]

CH-1393 Add a storybookBaseDir option to the trace/stats-to-story-files script

Currently you can set the config dir via STORYBOOK_CONFIG_DIR in the environment. Ideally you could do the same with the base dir.

[tmeasday]

LGTM, 👍 @ghengeveld