Fix Storybook preview config being set up in old config directory

[Philzen]

• Resolves [Bug]: setup ui & setup i18n commands still use old storybook folders #11864
• Synchronizes the echo output with the state of Remove extraneous i18n dependency from i18n setup #11789
• Work around issue where chakra-ui's preview.[tsx|js] would contain two exports (see comment below for details)

@Tobbe this should definitely go into the next patch release as it is broken since v8.0.0.

Got a couple of more optimizations for chakra-ui setup in the pipeline that can build on this but are non-critical additions that can go into a minor or major version bump.

---

This PR needs to be released together with #11789

[Philzen]

Also fixing (well, working around would be more accurate) this issue which would generate an invalid preview file for chakra-ui all along when running yarn rw setup ui chakra-ui:

The root cause is that this

redwood/packages/cli/src/lib/configureStorybook.js

Lines 52 to 58 in a99bde0

	const merged = await merge(storybookPreviewContent, newConfigContent, {
	ImportDeclaration: interleave,
	ArrayExpression: concatUnique,
	ObjectExpression: concatUnique,
	ArrowFunctionExpression: keepBothStatementParents,
	FunctionDeclaration: keepBoth,
	})

correctly merges the file, however it doesn't filter out if the file it merges with already has a default export.

Hence we need to ensure the i18n, mantine & chakra-ui setup templates do not contain a default export (which the first two don't) to work around this issue for the moment.

[Tobbe]

Thanks @Philzen 🙏
Can you also please take a look at the failing test cases?

[Philzen]

Can you also please take a look at the failing test cases?

Done.

With a few years of background in unit testing, looking at the concerned packages/project-config/src/__tests__/paths.test.ts IMHO:

1. it shouldn't repeat the implementation (which it does 4 times 🙈) → this is the reason it failed, although it shouldn't because from a first glance it is testing a completely different aspect)
2. it therefore could be ~1000 lines shorter

[Philzen]

1. it shouldn't repeat the implementation…
2. it therefore could be ~1000 lines shorter

OK i may have gone a little crazy here, but i thought i'd give it a try to increase the test maintainability and hence reduce a little technical debt.

Check cbacc5f...8b7a4d6

I could only save 480 lines of test code … which is better than nothing, but i probably promised a bit too much. As the implementation / single-source-of-truth is not exported in a consumable manner, i could only refactor the tests so they still repeat it … but now it at least only repeats it once except of four times and is much more readable IMHO. Thinking of #11760 where now we'd be able to delete four more lines out of this test and make everything more complete.

Technically this is way out-of-scope – so @Tobbe if you want i can pick them over into a separate PR for cleaner separation of concerns.

[Philzen]

@Tobbe good to merge from your perspective? I have two+ more PRs in the pipeline that build upon this fix, which can then continue to go forward.

On a sidenote:

Synchronizes the echo output with the state of #11789

I realized this requires to release #11789 as part of the same patch release that this PR will be in. If that's the plan, we're good here, otherwise i can cherrypick this into a separate PR.

[Tobbe]

Technically this is way out-of-scope – so @Tobbe if you want i can pick them over into a separate PR for cleaner separation of concerns.

Yes please.

And honestly, I'm not a big fan of the current code implementation either. It's not just the test code that has redundancies. But getting the test refactoring out in a separate PR is a great first step 🙏

[Tobbe]

I realized this requires to release #11789 as part of the same patch release that this PR will be in. If that's the plan, we're good here

Shouldn't be a problem. Don't know exactly when I'll be able to get to it, but there are a few more patches I want to get out, so hopefully later this week (future me always have more time than current me 😛)

[Philzen]

(future me always have more time than current me 😛)

Oh yeah i feel you

if you want i can pick them over into a separate PR for cleaner separation of concerns.

Yes please.

I've dropped the test refactoring commits in this branch now and will open a separate PR with them as soon as this one is merged. Fire at will 😁

[Tobbe]

Fire at will 😁

Auto-merge is on. As soon as all the tests pass the PR will be merged

[Tobbe]

Question: Why not keep the storybook config in web/config/?

RW has taken the opinionated stance that's where we store all config files.
I should have asked this much earlier, and we should definitely go with .storybook/ now. But I'm still curious 🙂
(Didn't pick up on what the change really ment until I wrote the changeset entry for this PR)

[Philzen]

Question: Why not keep the storybook config in web/config/?

Good question … that would have prevented this PR and issue, and also #11748 – losing track of how many places that would need to be changed at this point 😄
However, all the upgrade guides starting with https://community.redwoodjs.com/t/storybook-in-redwood-is-moving-to-vite/7212 in June 2024 did advise for the new location, so i guess you'd have to ask people that implemented that change…
I do have to say i personally like the .storybook folder, or vice-versa i'd find it confusing to have main.ts, preview.tsx, preview-body.html (and potentially preview-head.html) all lying around in the same /config-directory – although i guess they could sit in a subfolder then.

Rhetorical counter-question: If going down that opinionated route… shouldn't the jest.config.js, ESLint config, tsconfig, etc. all be stored in /config as well? Actually, now as you mentioned it, yarn rw setup i18n also creates it i18n.js config under web/src and not in config. While the chakra setup stores the theme-extension file in config, completely breaking chakra-ui's recommendation and actually not making any sense there (b/c it arguably is not a config file per se).

So i guess my point being: this has been inconsistent all along. In all my projects i'm having a good DX w/o any config folder at all – but if the opinionated implementation was to store all configs in the config folder, a whole lot more of customization would be needed.

May be worth to come to a definitive decision here at some point in the future. Smells like an RFC in the air 🙂

[Tobbe]

A .storybook/ subfolder inside config/ could make sense. I'd love to have jest.config.js and the eslint config inside config/ as well.
I don't know enough about chakra or our i18n setup to know where I'd want those.

Yeah, should probably be an RFC or something like that first. No something I have bandwidth for now though.