Skip to content
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

Closed
souporserious opened this issue Oct 25, 2024 · 2 comments · Fixed by #71968
Closed

regression when dynamically importing client component causing error #71840

souporserious opened this issue Oct 25, 2024 · 2 comments · Fixed by #71968
Assignees
Labels
bug Issue was opened via the bug report template. locked Webpack Related to Webpack with Next.js.

Comments

@souporserious
Copy link
Contributor

souporserious commented Oct 25, 2024

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:

async function getImport(slug: string, exportName: string) {
  const moduleExports = await import(`./${slug}.tsx`)
  return moduleExports[exportName]
}

export default async function Home() {
  const Button = await getImport('components/Button', 'Button')
  return <Button />
}

This will throw the following error:
image

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:

async function getImport(slug: string) {
  const moduleExports = await import(`./${slug}.tsx`)
  return {
    getExport: (name: string) => moduleExports[name],
  }
}

export default async function Home() {
  const Button = (await getImport('components/Button')).getExport('Button')
  return <Button />
}

However, marking the utility as async like the following will result in an error:

async function getImport(slug: string) {
  const moduleExports = await import(`./${slug}.tsx`)
  return {
++    getExport: async (name: string) => moduleExports[name],
  }
}

export default async function Home() {
++  const Button = await (await getImport('components/Button')).getExport('Button')
  return <Button />
}

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 as canary which both resulted in the error.

@souporserious souporserious added the bug Issue was opened via the bug report template. label Oct 25, 2024
@github-actions github-actions bot added the Webpack Related to Webpack with Next.js. label Oct 25, 2024
@unstubbable unstubbable self-assigned this Oct 28, 2024
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
@souporserious
Copy link
Contributor Author

Thank you for the fix, @unstubbable! Just tested canary and it works as expected now 🎉

Copy link
Contributor

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 12, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue was opened via the bug report template. locked Webpack Related to Webpack with Next.js.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants