Closed jvliwanag closed 1 month ago
Woah ok i did not know that was possible. Thanks for the suggestion! Will take a look.
This is where metro docs being better would have gone a long way 😅.
I will add this to withStorybook most likely and remove the changes that apply to overall config
Hehe, was pulling my hair out as well trying to figure out this one. As a last note, might as well make unstable_conditionNames
explicit here since bare react-native (non-expo) projects will have a different default for it:
return context.resolveRequest(
{
...context,
unstable_enablePackageExports: true,
unstable_conditionNames: ["import"],
},
moduleName,
platform,
);
@jvliwanag can you try this alpha version: 8.3.8-alpha.0
this is published with the changes in #621
Tested this and works perfectly! Thanks for this!
Thanks for the suggestion 🙇
now released on 8.3.8
Finally got storybook v8 working! Awesome new UI!
However, I'm finding that forcing users to use
unstable_enablePackageExports
and with the expo addingimport
tounstable_conditionNames
here is just breaking a lot of things.Many of the global state management libs break (zustand, jotai, valtio) without patching. See another sample here.
Trying to undo expo's unstable_conditionNames and metro's default as
["react-native", "require"]
does unbreak the other packages since we end up with commonjs -- but this breaks@storybook/*
complaining instead on "static block class". Though we can go with the polyfill route, I'm suggesting we go another direction.My suggestion is unless
unstable_enablePackageExports
is explicitly turned on from the user's metro config, we keep it off. But when resolvingstorybook
deps which we know work better on the esm builds, then we turn it on. I've had success configuring metro this way: