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.

[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.