[Bug?]: Storybook 7.2.0 'Broken Build' error #9073
Labels
bug/confirmed
We have confirmed this is a bug
Comments
pantheredeye
added
the
bug/needs-info
|
Update on this: Storybook fails on a fresh install with this error:
Yarn RW Info |
|
Temp fix within a project from @Josh-Walker-GM works for me:
|
drikusroor
added a commit
to drikusroor/ohayo-goededagu
that referenced
this issue
Sep 10, 2023
drikusroor
added a commit
to drikusroor/ohayo-goededagu
that referenced
this issue
Sep 10, 2023
* chore(deps): Upgrade yarn * feat: Scaffold Image Gallery * fix: "Temporary" fix for babel runtime transform plugin See also: redwoodjs/redwood#9073 (comment) * fix: Rename image-galleries route path * feat: Add image-galleries to dashbord navigation * feat: Cascade delete related entities when deleting image gallery
|
i had the same issue, but then upgraded to |
|
@pantheredeye, @chenull, could you two try the latest patch? I believe I've gotten to the bottom of the issue: https://github.com/redwoodjs/redwood/releases/tag/v6.2.1 |
jtoar
added
bug/confirmed
@jtoar just upgraded. storybook is now working |
|
@chenull awesome! closing this one for now then |
jtoar
added a commit
that referenced
this issue
Sep 15, 2023
the previous babel fix (#9144) to issues like #9156 and #9073 was only a temporary solution and didn't work for all users. after more thinking, i'm pretty sure that the root of the problem is that we pin the version of the babel packages we depend on. take a redwood app that was just created from `yarn create redwood-app`. most redwood projects request a specific version of a babel package. for example, for `@babel/core`, redwood packages say they want `7.22.17`. the redwood packages aren't the only ones that want `@babel/core`, but they use a caret when they ask for the version, like `^7.22.5` at the outset, yarn can usually make everyone happy with one version. but say a new version of `@babel/core` comes out, `7.22.19`. and then a user installs storybook, or some other package that depends on `@babel/core`. the problem is that yarn checks npm to see if there's a new version, and if there is, it updates the caret versions like `^7.22.5` to resolve to the new one. but all the redwood packages are insisting they want `7.22.17`, not `7.22.19`, so yarn has to keep both around and now, when it comes to hoisting, has a choice to make: which version of `@babel/core` is at `node_modules/@babel/core`? more packages are ok with `7.22.19` so it wins out, and `7.22.17` gets buried into the redwood package's node_modules. to figure out which babel packages need the caret, i relied on a combination of `yarn info -R --dependents ${packageName}`, `yarn why ${packageName}`, and `find ./node_modules -type d -path '*/${packageName}'`. the next steps for this are to get it into canary so i can confirm.
jtoar
added a commit
that referenced
this issue
Sep 15, 2023
the previous babel fix (#9144) to issues like #9156 and #9073 was only a temporary solution and didn't work for all users. after more thinking, i'm pretty sure that the root of the problem is that we pin the version of the babel packages we depend on. take a redwood app that was just created from `yarn create redwood-app`. most redwood projects request a specific version of a babel package. for example, for `@babel/core`, redwood packages say they want `7.22.17`. the redwood packages aren't the only ones that want `@babel/core`, but they use a caret when they ask for the version, like `^7.22.5` at the outset, yarn can usually make everyone happy with one version. but say a new version of `@babel/core` comes out, `7.22.19`. and then a user installs storybook, or some other package that depends on `@babel/core`. the problem is that yarn checks npm to see if there's a new version, and if there is, it updates the caret versions like `^7.22.5` to resolve to the new one. but all the redwood packages are insisting they want `7.22.17`, not `7.22.19`, so yarn has to keep both around and now, when it comes to hoisting, has a choice to make: which version of `@babel/core` is at `node_modules/@babel/core`? more packages are ok with `7.22.19` so it wins out, and `7.22.17` gets buried into the redwood package's node_modules. to figure out which babel packages need the caret, i relied on a combination of `yarn info -R --dependents ${packageName}`, `yarn why ${packageName}`, and `find ./node_modules -type d -path '*/${packageName}'`. the next steps for this are to get it into canary so i can confirm.
jtoar
added a commit
that referenced
this issue
Sep 15, 2023
the previous babel fix (#9144) to issues like #9156 and #9073 was only a temporary solution and didn't work for all users. after more thinking, i'm pretty sure that the root of the problem is that we pin the version of the babel packages we depend on. take a redwood app that was just created from `yarn create redwood-app`. most redwood projects request a specific version of a babel package. for example, for `@babel/core`, redwood packages say they want `7.22.17`. the redwood packages aren't the only ones that want `@babel/core`, but they use a caret when they ask for the version, like `^7.22.5` at the outset, yarn can usually make everyone happy with one version. but say a new version of `@babel/core` comes out, `7.22.19`. and then a user installs storybook, or some other package that depends on `@babel/core`. the problem is that yarn checks npm to see if there's a new version, and if there is, it updates the caret versions like `^7.22.5` to resolve to the new one. but all the redwood packages are insisting they want `7.22.17`, not `7.22.19`, so yarn has to keep both around and now, when it comes to hoisting, has a choice to make: which version of `@babel/core` is at `node_modules/@babel/core`? more packages are ok with `7.22.19` so it wins out, and `7.22.17` gets buried into the redwood package's node_modules. to figure out which babel packages need the caret, i relied on a combination of `yarn info -R --dependents ${packageName}`, `yarn why ${packageName}`, and `find ./node_modules -type d -path '*/${packageName}'`. the next steps for this are to get it into canary so i can confirm.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What's not working?
I keep running into this problem:
and I do not know what is causing it. There was a bug in Storybook 7.2.0 that swallows errors, which is what I am experiencing above. The issue was patched in 7.2.1.
Is there a way that I can manually bump the version of storybook to upgrade to 7.2.1?
How do we reproduce the bug?
I am not sure... storybook was working before I added a couple of components. I feel like there is a problem in my code that is causing this, but I don't see any errors in my code right now. The nature of this issue is that storybook errors are swallowed, so I cannot debug from their end.
What's your environment? (If it applies)
System: OS: Windows 10 10.0.19045 Binaries: Node: 18.14.1 - C:\Users\BBURNW~1\AppData\Local\Temp\xfs-1ac32ce6\node.CMD Yarn: 3.6.1 - C:\Users\BBURNW~1\AppData\Local\Temp\xfs-1ac32ce6\yarn.CMD Browsers: Edge: Spartan (44.19041.1266.0), Chromium (116.0.1938.54) npmPackages: @redwoodjs/cli-storybook: 6.1.0 => 6.1.0 @redwoodjs/core: 6.1.0 => 6.1.0Are you interested in working on this?
The text was updated successfully, but these errors were encountered: