Unable to import exports from client component files in non-component files #66212
Labels
bug
Issue was opened via the bug report template.
Developer Experience
Issues related to Next.js logs, Error overlay, etc.
locked
Module Resolution
Module resolution (CJS / ESM, module resolving)
Runtime
Related to Node.js or Edge Runtime with Next.js.
Turbopack
Related to Turbopack with Next.js.
Webpack
Related to Webpack with Next.js.
Comments
github-actions
bot
added
Developer Experience
hakimmazouz
changed the title
huozhi
added a commit
that referenced
this issue
Jun 10, 2024
### What
Remove creating client proxy for each ESM export, instead for ESM we
create a CJS module proxy for itself and access the property with export
name as the actual export.
### Why
`proxy` is the module proxy that we treat the module as a client
boundary.
For ESM, we access the property of the module proxy directly for each
export.
This is bit hacky that treating using a CJS like module proxy for ESM's
exports,
but this will avoid creating nested proxies for each export. It will be
improved in the future.
Notice that for `next/dynamic`, if you're doing a dynamic import of
client component in server component, and trying to access the named
export directly, it will error. Instead you need to align the dynamic
import resolved value wrapping with a `default:` property (e.g. `{
default: resolved }`) like what `React.lazy` accepted.
Revert #57301
Fixes #66212
x-ref:
[slack](https://vercel.slack.com/archives/C04DUD7EB1B/p1716897764858829)
|
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. |
lubieowoce
pushed a commit
that referenced
this issue
Aug 23, 2024
Remove creating client proxy for each ESM export, instead for ESM we
create a CJS module proxy for itself and access the property with export
name as the actual export.
`proxy` is the module proxy that we treat the module as a client
boundary.
For ESM, we access the property of the module proxy directly for each
export.
This is bit hacky that treating using a CJS like module proxy for ESM's
exports,
but this will avoid creating nested proxies for each export. It will be
improved in the future.
Notice that for `next/dynamic`, if you're doing a dynamic import of
client component in server component, and trying to access the named
export directly, it will error. Instead you need to align the dynamic
import resolved value wrapping with a `default:` property (e.g. `{
default: resolved }`) like what `React.lazy` accepted.
Revert #57301
Fixes #66212
x-ref:
[slack](https://vercel.slack.com/archives/C04DUD7EB1B/p1716897764858829)
lubieowoce
pushed a commit
that referenced
this issue
Aug 23, 2024
Remove creating client proxy for each ESM export, instead for ESM we
create a CJS module proxy for itself and access the property with export
name as the actual export.
`proxy` is the module proxy that we treat the module as a client
boundary.
For ESM, we access the property of the module proxy directly for each
export.
This is bit hacky that treating using a CJS like module proxy for ESM's
exports,
but this will avoid creating nested proxies for each export. It will be
improved in the future.
Notice that for `next/dynamic`, if you're doing a dynamic import of
client component in server component, and trying to access the named
export directly, it will error. Instead you need to align the dynamic
import resolved value wrapping with a `default:` property (e.g. `{
default: resolved }`) like what `React.lazy` accepted.
Revert #57301
Fixes #66212
x-ref:
[slack](https://vercel.slack.com/archives/C04DUD7EB1B/p1716897764858829)
lubieowoce
pushed a commit
that referenced
this issue
Aug 23, 2024
Remove creating client proxy for each ESM export, instead for ESM we
create a CJS module proxy for itself and access the property with export
name as the actual export.
`proxy` is the module proxy that we treat the module as a client
boundary.
For ESM, we access the property of the module proxy directly for each
export.
This is bit hacky that treating using a CJS like module proxy for ESM's
exports,
but this will avoid creating nested proxies for each export. It will be
improved in the future.
Notice that for `next/dynamic`, if you're doing a dynamic import of
client component in server component, and trying to access the named
export directly, it will error. Instead you need to align the dynamic
import resolved value wrapping with a `default:` property (e.g. `{
default: resolved }`) like what `React.lazy` accepted.
Revert #57301
Fixes #66212
x-ref:
[slack](https://vercel.slack.com/archives/C04DUD7EB1B/p1716897764858829)
lubieowoce
pushed a commit
that referenced
this issue
Aug 23, 2024
Remove creating client proxy for each ESM export, instead for ESM we
create a CJS module proxy for itself and access the property with export
name as the actual export.
`proxy` is the module proxy that we treat the module as a client
boundary.
For ESM, we access the property of the module proxy directly for each
export.
This is bit hacky that treating using a CJS like module proxy for ESM's
exports,
but this will avoid creating nested proxies for each export. It will be
improved in the future.
Notice that for `next/dynamic`, if you're doing a dynamic import of
client component in server component, and trying to access the named
export directly, it will error. Instead you need to align the dynamic
import resolved value wrapping with a `default:` property (e.g. `{
default: resolved }`) like what `React.lazy` accepted.
Revert #57301
Fixes #66212
x-ref:
[slack](https://vercel.slack.com/archives/C04DUD7EB1B/p1716897764858829)
lubieowoce
pushed a commit
that referenced
this issue
Aug 23, 2024
Remove creating client proxy for each ESM export, instead for ESM we
create a CJS module proxy for itself and access the property with export
name as the actual export.
`proxy` is the module proxy that we treat the module as a client
boundary.
For ESM, we access the property of the module proxy directly for each
export.
This is bit hacky that treating using a CJS like module proxy for ESM's
exports,
but this will avoid creating nested proxies for each export. It will be
improved in the future.
Notice that for `next/dynamic`, if you're doing a dynamic import of
client component in server component, and trying to access the named
export directly, it will error. Instead you need to align the dynamic
import resolved value wrapping with a `default:` property (e.g. `{
default: resolved }`) like what `React.lazy` accepted.
Revert #57301
Fixes #66212
x-ref:
[slack](https://vercel.slack.com/archives/C04DUD7EB1B/p1716897764858829)
lubieowoce
pushed a commit
that referenced
this issue
Aug 28, 2024
Remove creating client proxy for each ESM export, instead for ESM we
create a CJS module proxy for itself and access the property with export
name as the actual export.
`proxy` is the module proxy that we treat the module as a client
boundary.
For ESM, we access the property of the module proxy directly for each
export.
This is bit hacky that treating using a CJS like module proxy for ESM's
exports,
but this will avoid creating nested proxies for each export. It will be
improved in the future.
Notice that for `next/dynamic`, if you're doing a dynamic import of
client component in server component, and trying to access the named
export directly, it will error. Instead you need to align the dynamic
import resolved value wrapping with a `default:` property (e.g. `{
default: resolved }`) like what `React.lazy` accepted.
Revert #57301
Fixes #66212
x-ref:
[slack](https://vercel.slack.com/archives/C04DUD7EB1B/p1716897764858829)
lubieowoce
pushed a commit
that referenced
this issue
Sep 2, 2024
Remove creating client proxy for each ESM export, instead for ESM we
create a CJS module proxy for itself and access the property with export
name as the actual export.
`proxy` is the module proxy that we treat the module as a client
boundary.
For ESM, we access the property of the module proxy directly for each
export.
This is bit hacky that treating using a CJS like module proxy for ESM's
exports,
but this will avoid creating nested proxies for each export. It will be
improved in the future.
Notice that for `next/dynamic`, if you're doing a dynamic import of
client component in server component, and trying to access the named
export directly, it will error. Instead you need to align the dynamic
import resolved value wrapping with a `default:` property (e.g. `{
default: resolved }`) like what `React.lazy` accepted.
Revert #57301
Fixes #66212
x-ref:
[slack](https://vercel.slack.com/archives/C04DUD7EB1B/p1716897764858829)
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:/hakimmazouz/import-from-client-components
To Reproduce
fragmentthat gets imported from the client componentMyClientComponent.tsxCurrent vs. Expected behavior
This used to work prior to Next.js 14 (13.5.6) but for some reason doesn't work now. I have an inkling as to why (bundling and wanting to separate the interweaving of client and server components) but this break a pattern we use for colocating queries (GraphQL, GROQ etc.) with our components.
Provide environment information
Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:41 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T8103 Available memory (MB): 8192 Available CPU cores: 8 Binaries: Node: 20.8.1 npm: 10.1.0 Yarn: 1.22.19 pnpm: 8.6.0 Relevant Packages: next: 14.2.3 // Latest available version is detected (14.2.3). eslint-config-next: N/A react: 18.3.1 react-dom: 18.3.1 typescript: 5.4.5 Next.js Config: output: N/AWhich area(s) are affected? (Select all that apply)
Developer Experience, Module Resolution, Runtime, Turbopack, Webpack
Which stage(s) are affected? (Select all that apply)
next dev (local), next build (local), next start (local)
Additional context
If anybody can point me to somewhere in the Next.js documentation explaining this behavior I would appreciate it as right now this type of bundling breaks everything I expect out of ES Modules.
The text was updated successfully, but these errors were encountered: