-
Notifications
You must be signed in to change notification settings - Fork 27k
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
regression when dynamically importing client component causing error #71840
Comments
unstubbable
added a commit
that referenced
this issue
Oct 28, 2024
When registering a client reference for a client component module, React offers two distinct functions: - `registerClientReference`: Register a named or default export of an ES module as a client reference. - `createClientModuleProxy`: Create a client module proxy for a CJS module that registers every module export as a client reference. Until this PR, we were using the client module proxy for both kinds of modules, which is incorrect. It was especially problematic because in the Node.js runtime we were always awaiting the client module proxy. This was a workaround for handling async modules (see #66990), but led to issues like #71840. With this PR, we are now using `registerClientReference` if we detect that a module is an ES module. This aligns the Webpack implementation with the one in Turbopack. fixes #71840
unstubbable
added a commit
that referenced
this issue
Oct 28, 2024
When registering a client reference for a client component module, React offers two distinct functions: - `registerClientReference`: Register a named or default export of an ES module as a client reference. - `createClientModuleProxy`: Create a client module proxy for a CJS module that registers every module export as a client reference. Until this PR, we were using the client module proxy for both kinds of modules, which is incorrect. It was especially problematic because in the Node.js runtime we were always awaiting the client module proxy. This was a workaround for handling async modules (see #66990), but led to issues like #71840. With this PR, we are now using `registerClientReference` if we detect that a module is an ES module. This aligns the Webpack implementation with the one in Turbopack. fixes #71840
unstubbable
added a commit
that referenced
this issue
Oct 28, 2024
When registering a client reference for a client component module, React offers two distinct functions: - `registerClientReference`: Register a named or default export of an ES module as a client reference. - `createClientModuleProxy`: Create a client module proxy for a CJS module that registers every module export as a client reference. Until this PR, we were using the client module proxy for both kinds of modules, which is incorrect. It was especially problematic because in the Node.js runtime we were always awaiting the client module proxy. This was a workaround for handling async modules (see #66990), but led to issues like #71840. With this PR, we are now using `registerClientReference` if we detect that a module is an ES module. This aligns the Webpack implementation with the one in Turbopack. fixes #71840
Thank you for the fix, @unstubbable! Just tested canary and it works as expected now 🎉 |
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Link to the code that reproduces this issue
https://github.com/souporserious/next-15-dynamic-module-bug
To Reproduce
Create a dynamic import utility and try to render a component that has the
use client
directive:This will throw the following error:
Current vs. Expected behavior
Using a utility to access the dynamic import was working prior to version 15. It seems that the heuristic is incorrectly determining how the component is being imported. Using the
--turbopack
flag results in the expected behavior and does not throw an error so it only seems to be an issue in Webpack.Interestingly, if the getter is not async and simply returns the module value there is no error:
However, marking the utility as
async
like the following will result in an error:This shouldn't make a difference since the function is doing async work and does not interfere with the module value.
Provide environment information
Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 24.0.0: Tue Sep 24 23:39:07 PDT 2024; root:xnu-11215.1.12~1/RELEASE_ARM64_T6000 Available memory (MB): 16384 Available CPU cores: 10 Binaries: Node: 21.2.0 npm: 10.8.1 Yarn: 1.22.21 pnpm: 9.9.0 Relevant Packages: next: 15.0.2-canary.6 // Latest available version is detected (15.0.2-canary.6). eslint-config-next: N/A react: 19.0.0-rc-1631855f-20241023 react-dom: 19.0.0-rc-1631855f-20241023 typescript: 5.6.3 Next.js Config: output: N/A
Which area(s) are affected? (Select all that apply)
Webpack
Which stage(s) are affected? (Select all that apply)
next dev (local)
Additional context
I tested against the latest version
15.0.1
as well ascanary
which both resulted in the error.The text was updated successfully, but these errors were encountered: