-
-
Notifications
You must be signed in to change notification settings - Fork 380
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSR is broken for component v5.16.2+ #999
Comments
"Quiet" is very concerning. It should blow up if something is not right, but quiet.... |
Yeah, that was exactly my thinking as well. And as stated, downgrading to an older version immediately fixed it. I'll just stay on that version for now, but it's... weird. |
I have the same problem after update of Some of the dependencies from my package.json:
|
I also have the same problem after updating
|
The reason for this is ESM migration which was introduced in #989
So basically we end up with two versions of As workaround you can set alias for CJS version for webpack: resolve: {
alias: {
'@loadable/component': require.resolve('@loadable/component')
}
} |
Or we need to “esm” server as well. |
🐛 Bug Report
Upgrading from
@loadable/component
v5.15.3
(latest5.15.*
in npm) tov5.16.2+
quietly breaks SSR using React 17 and Webpack 5.90.To Reproduce
Something has broken between
@loadable/component
v5.15.3
andv5.16.2
(there is no5.16.0
or5.16.1
in npm, so5.15.3
->5.16.2/3
is the only upgrade path available). SSR yields absolutely no output for the components, and there are no collected chunks in the output (rehydrating to interactive seems to fix the problem, but that's not really enough).Using
@loadable/component
5.15.3
together with@loadable/server
5.15.3
and5.16.3
works perfectly, so the problem is not on the server part. No configuration has changed, but somehow,Palpatine returnedit has just stopped working. If I downgrade@loadable/component
to5.15.3
, everything works again.Expected behavior
I'd expect it to... you know, render the components on the server. 😅 I looked into the changelog for the repository, and saw the main difference for the client was an added
loadable
named export, so one should not have to use the default exports, but in the versions available on npm, I can't seeloadable
being exported (and the compiler explodes when I try accessing it). The types available through@types/loadable__component
and@types/loadable__server
have not been updated recently either, so I think the default export is still the way to go when using the regularimport
pattern (ES6/ESM).Link to repl or repo (highly encouraged)
Sadly, it's a proprietary client repo, but since everything else is unchanged, I hope/fear it's reproducible anywhere? Or it might be something in this unique setup that's broken, but it's weird that it'd only break in the relatively short jump from 5.15.3 to 5.16.2?
I'll take my chances, but thanks.
System info
The text was updated successfully, but these errors were encountered: