Open jdelStrother opened 9 months ago
@jdelStrother did you ever solve this? I'm running into the same error with storybook 8
No, sorry - I decided to stick with storybook 7 till this got worked out
Hey guys, any idea what is causing this?! Having the same issue suddenly with storybook v8.
Aw great. I'm having the same exact issue after upgrading to v8. Any idea what might be the cause? I did so many changes to get us on v8. Moving back to v7 would be a problem.
The issue I found was something about how Vite bundles. We had Babel running directly on the files, but after switching to Vite, that's when the issue first appeared.
React-Docgen is erroring when loading a chunk from that bundle.
I changed the version of our library to the previous Babel release, and was able to load all the components just fine in v8. This means something about chunked imports is causing the problems in react-docgen. We previously used react-docgen-typescript, and I wonder if it handles those differently.
Looking into this further, it seems you can actually debug it pretty easily.
In main.ts
, I set the docgen
prop to undefined
.
That will cause it to run Storybook and your code bypassing that cryptic error message. Now that your code's running, you can actually see the error. In my case, it's something to do with useMemo
in a chunk!
TypeError: Cannot read properties of null (reading 'useMemo')
at b.useMemo (http://localhost:6006/@fs/Users/[REDACTED]/[REDACTED]/packages/[REDACTED]/dist/ExternalLink-BhUztxxa.js?t=1732233947609:258:20)
at A$ (http://localhost:6006/@fs/Users/[REDACTED]/[REDACTED]/packages/[REDACTED]/dist/MenuItem-C4r-pRo5.js?t=1732233947609:27187:21)
at T$ (http://localhost:6006/@fs/Users/[REDACTED]/[REDACTED]/packages/[REDACTED]/dist/MenuItem-C4r-pRo5.js?t=1732233947609:27196:13)
at renderWithHooks (http://localhost:6006/node_modules/.cache/storybook/ce5b28a99969a952315cc9515f5d949ac3e56cf9da18b6c094ed0e7bb2285118/sb-vite/deps/chunk-YJOGCSKE.js?v=562ac336:12151:26)
at updateFunctionComponent (http://localhost:6006/node_modules/.cache/storybook/ce5b28a99969a952315cc9515f5d949ac3e56cf9da18b6c094ed0e7bb2285118/sb-vite/deps/chunk-YJOGCSKE.js?v=562ac336:14557:28)
at updateSimpleMemoComponent (http://localhost:6006/node_modules/.cache/storybook/ce5b28a99969a952315cc9515f5d949ac3e56cf9da18b6c094ed0e7bb2285118/sb-vite/deps/chunk-YJOGCSKE.js?v=562ac336:14438:18)
at updateMemoComponent (http://localhost:6006/node_modules/.cache/storybook/ce5b28a99969a952315cc9515f5d949ac3e56cf9da18b6c094ed0e7bb2285118/sb-vite/deps/chunk-YJOGCSKE.js?v=562ac336:14348:22)
at beginWork (http://localhost:6006/node_modules/.cache/storybook/ce5b28a99969a952315cc9515f5d949ac3e56cf9da18b6c094ed0e7bb2285118/sb-vite/deps/chunk-YJOGCSKE.js?v=562ac336:15945:22)
at beginWork$1 (http://localhost:6006/node_modules/.cache/storybook/ce5b28a99969a952315cc9515f5d949ac3e56cf9da18b6c094ed0e7bb2285118/sb-vite/deps/chunk-YJOGCSKE.js?v=562ac336:19721:22)
at performUnitOfWork (http://localhost:6006/node_modules/.cache/storybook/ce5b28a99969a952315cc9515f5d949ac3e56cf9da18b6c094ed0e7bb2285118/sb-vite/deps/chunk-YJOGCSKE.js?v=562ac336:19166:20)
Even more info, Vite is building that chunk funky:
It's complaining that B.current
might be null
. I put a B.current?.
after all of them, and it does something else!
Just wanna note I don't even use useMemo
nor any React functions the file that was chunked, so maybe it's a tree shaking issue.
I have "type": "module"
in my package.json
. Is it something to do with that?
I fixed this by removing Vite from the equation and rolling tsc
manually. In the past, we were using Babel directly on the files to convert them from ts to js. All I changed now was to use tsc instead without a Babel step.
Not sure what Vite chunking is doing, but it's unnecessary for this library.
Hopefully, that helps someone else!
react-docgen seems to fail on this file:
producing:
I'm using react-docgen 7.0.3. Curiously, the docgen playground doesn't throw an error on the same file, correctly reporting that it doesn't have a component definition.
Replacing the object-function-shorthand with arrow functions seems to sidestep the issue: