SSR is broken for component v5.16.2+

[DonGissel]

🐛 Bug Report

Upgrading from @loadable/component v5.15.3 (latest 5.15.* in npm) to v5.16.2+ quietly breaks SSR using React 17 and Webpack 5.90.

To Reproduce

Something has broken between @loadable/component v5.15.3 and v5.16.2 (there is no 5.16.0 or 5.16.1 in npm, so 5.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 and 5.16.3 works perfectly, so the problem is not on the server part. No configuration has changed, but somehow, Palpatine returned it has just stopped working. If I downgrade @loadable/component to 5.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 see loadable 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 regular import 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?

Issues without a reproduction link are likely to stall.

I'll take my chances, but thanks.

System info

## System:
 - OS: Windows 11 10.0.22631
 - CPU: (12) x64 Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz
 - Memory: 14.02 GB / 31.76 GB
## Binaries:
 - Node: 20.11.0 - C:\Program Files\nodejs\node.EXE
 - npm: 10.2.4 - C:\Program Files\nodejs\npm.CMD
## npmPackages:
 - @loadable/babel-plugin: ^5.16.1 => 5.16.1
 - @loadable/component: 5.16.3 => 5.16.3
 - @loadable/server: 5.16.2 => 5.16.2
 - @loadable/webpack-plugin: ^5.15.2 => 5.15.2

[theKashey]

"Quiet" is very concerning. It should blow up if something is not right, but quiet....

[DonGissel]

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

[akhmadullin]

I have the same problem after update of @loadable/component to 5.16.3 and @loadable/server to 5.16.2.

Some of the dependencies from my package.json:

"@loadable/component": "5.16.3",
"@loadable/server": "5.16.2",
"@loadable/babel-plugin": "5.16.1",
"@loadable/webpack-plugin": "5.15.2",
"webpack": "5.89.0",

[anambl]

I also have the same problem after updating @loadable/component and @loadable/server to latest version (and also silently failing). I am using exactly the same versions as akhmadullin

"@loadable/component": "5.16.3",
"@loadable/server": "5.16.2",
"@loadable/babel-plugin": "5.16.1",
"@loadable/webpack-plugin": "5.15.2",
"webpack": "5.89.0",

[7rulnik]

The reason for this is ESM migration which was introduced in #989

@loadable/server resolves to different file because it uses require https://unpkg.com/browse/@loadable/server@5.16.2/lib/sharedInternals.js (see line 6)

So basically we end up with two versions of @loadable/component.

As workaround you can set alias for CJS version for webpack:

resolve: {
    alias: {
      '@loadable/component': require.resolve('@loadable/component')
    }
}

[theKashey]

Or we need to “esm” server as well.