Open Pagebakers opened 2 years ago
After some more testing the .mjs extension seems to cause issues, renaming the esm files to .js resolves the issues.
Thanks, I was first going to suggest upgrading the packages to 1.3
as it seems to have been fixed, but I saw that you are the maintainer, so you are likely here to get an answer why https://github.com/saas-js/saas-ui/commit/f6ec7dcdf3b408e3c14025f34620f05023c35a7f was needed.
When ESM resolution is enabled, the work is handed off to the Node.js resolver:
The general rule is that conditions should be from most specific to least specific in object order.
Given that import
and require
are mutually exclusive on the same specificity level and default
is just a fallback (the least specific), I assume require
gets picked instead of default
as it's higher specificity. I think it's correct to assume that require
and import
should always be used together.
All examples I have seen define both import
and require
.
Webpack's guidelines also suggest avoiding default
:
Avoid the
default
export. It's handled differently between tooling.
Resources:
Thanks @balazsorban44
This issue is related to: https://github.com/chakra-ui/chakra-ui/issues/6436
Chakra UI uses .js extension for ESM modules. Any other package that depends on Chakra UI and uses .mjs extension for ESM modules will run into this error. Renaming all .mjs files to .js in @saas-ui/react ultimately resolved it for now, but this is more a workaround then a solution imho.
I looked into framer as well, which had a similar issue open with Next.js last year. They are using require (.js) and default (.mjs) without any issues, so that doesn't seem to be the problem.
https://github.com/vercel/next.js/issues/30750
Here to proposed solution was to use .mjs.
I'm not sure what is going on, but anyway the compiler behaviour changes based on which extension is used for ESM modules, while the package.json definitions are the same, as well as the code of the modules.
As far as I can tell, Framer does not have require
or default
, but :thinking::
"type": "module",
"exports": {
".": "./build/index.js",
"./package.json": "./package.json",
"./*": "./build/*"
},
Sorry, probably the wrong package above. framer-motion
has this:
"exports": {
".": {
"require": "./dist/cjs/index.js",
"import": {
"types": "./dist/index.d.ts",
"default": "./dist/es/index.mjs"
},
"default": "./dist/cjs/index.js"
},
"./package.json": "./package.json"
},
https://unpkg.com/browse/framer-motion@7.0.0/package.json
So actually they use both import
and require
.
Ok, my bad I misread this yesterday.
Then we can agree using both 'import' and 'require' is the way to go, leaves us only with the question why the compiler behaves different with .js and .mjs file extensions for es modules.
Do you mean https://github.com/saas-js/saas-ui/commit/a43204dc77e5154fd00bddd222c358734c1822c9?
If you want to signal Node.js to treat your .js
files as ESM, you need to set type: "module"
at the top level.
The
"type"
field defines the module format that Node.js uses for all .js files that have thatpackage.json
file as their nearest parent.
https://nodejs.org/api/packages.html#type
UPDATE:
Oh, it's the other way around. :thinking: You fixed it by going from .mjs
to .js
. Hmm.
Also, If using .mjs
, the type
config is ignored:
Regardless of the value of the "type" field, .mjs files are always treated as ES modules and .cjs files are always treated as CommonJS.
So if no .mjs are found (even though type = module , or 'import' is defined, it will always treat the package as cjs?
So if no .mjs are found (even though type = module , or 'import' is defined, it will always treat the package as cjs?
Not sure yet, will have to investigate further.
https://github.com/vercel/next.js/issues/39375#issuecomment-1208109442 So if no .mjs are found (even though type = module , or 'import' is defined, it will always treat the package as cjs?
Our research would confirm this. We have the following setup:
NextJS project that uses @our-company/lib
@our-company/lib
uses @tabler/icons
as dependency (and FYI, even if it's not a dependency but a peerDependency NextJS will act the same way).
@tabler/icons
correctly defines this in it's package.json:
{
"exports": { ".": { "import": "./icons-react/dist/index.esm.js" } }
}
Now the above ends with .js
and not with .mjs
. Technically this is perfectly fine.
Now what NextJS does is: If THAT package is requested from ANOTHER package (so not directly from the NextJS app but from a sub-package, in our case @our-company/lib
) it will ALWAYS throw the error that the ESM file is a CJS file, probably judging by its extension .js
instead of .mjs
.
This is extremely weird and I'd be willing to help out here if I know in which file to start. I am actually wondering why so few people seem to have this issue. But I assume that people find workarounds.
Our findings are backed by the fact that if we rename those files to .mjs
by hand it works.
I've done a bit more research on this and since the error is being triggered with this error log
ModuleJob._instantiate
node:internal/modules/esm/module_job (124:21)
async ModuleJob.run
node:internal/modules/esm/module_job (190:5)
I have the gut feeling that this problem might be rather a node-based problem than a framework-based problem which is interesting.
According to https://nodejs.org/api/esm.html .mjs
is the proposed format and it seems to hit confusion in combination with exports:
. Which, when type isn't explicitly module
, currently (node 16,18,19) won't resolve what's defined in the exports: { import: "... "}
as ESM but as CJS when it doesn't have that specific .mjs
extension.
So maybe at this point of information / node status it's best to have this resolved in the related / imported libraries. But what's really interesting is why it works for direct dependencies (maybe because NextJS bundles those but it doesn't transform the sub-deps?)
Alright. I've researched this for quite some while now. What I reported above seems to hold true.
Now for people searching for a SOLUTION only I have exactly 2 proposals for you:
Clean one: Go to the affected repository of the "problematic" library and make sure they export the ESM files with .mjs
extension and/or have it set type: "module"
in the package.json
Workaround: Abuse your next.config.js
:
const nextConfig = {
experimental: {
transpilePackages: ["problematic-package", "other-problematic-package", "etc", "..."],
},
}
Warning: This isn't a clean solution so only do this when you are beyond desperate.
@activenode Great work, thank you.
The saga continues for me. Chakra UI renamed everything back to .mjs, and my library started having the same issues again, but reversed :)
I've released new bundles with .mjs extensions, which fixed it partially. But one dependency @react-aria/* uses .js for module bundles, so back at the start.
I have the gut feeling that this problem might be rather a node-based problem than a framework-based problem which is interesting.
I was wondering the same, looking at the logs nothing really points to Next.js
Also Webpack detects the packages correctly as ESM, even overriding the package type to ESM doesn't seem to work.
Your proposed work around doesn't seem to fix the issues with @react-aria for me. I'll keep digging.
I bundle Typescript src files with Saas UI at the moment, changing imports to @saas-ui/date-picker/src
is a work around for now.
For reference. Adobe reverted their update to .mjs recently.
For reference. Adobe reverted their update to .mjs recently.
Well, there's just standard people working everywhere.
But with revert you mean .js
to .mjs
or not? Because those diffs seem like it https://github.com/adobe/react-spectrum/pull/3630/files#diff-b0c5db6e52be47d05cc62e47a08b31818cfc69d80b48a1c395129dd885b91dd8
Which would make sense to me.
I get your pain and I feel it comes from the mix (which must be resolved depending on how the mix is setup - which is one of the described problems here).
At the end of the day it comes down to: If everything is using .mjs
it doesn't matter the type
of the package.json because then Node will correctly detect --> Make sure that the libs are using .mjs
.
Going back reverting to .js
just because of a specific setup feels like going back for false reasons (see Node ESM Link above)
What I still find interesting though is that it only appears (in my experience) with deps of deps not with deps but that could be explained as direct deps might run through the bundler whereas the deps of deps don't.
I was having the same problems with a @company/lib
that implements the adobe stack (react-aria
, @react-stately
, @internationalized
).
I found two possible workarounds for it:
Change the libraries files:
This is updating the package.json
's lines:
"main": "dist/main.js",
"module": "dist/module.js",
to:
"exports": {
".": {
"import": "./dist/module.mjs",
"require": "./dist/main.js"
}
}
as you may have noticed it also requires renaming module.js
to module.mjs
.
This fixes next.js/node resolving the wrong file.
Client-side rendering
I don't know why this happens or if it's a solution only to my use case but I found that importing the component from @company/lib
using dynamic import and ssr: false
also solve the issue.
Is tsconfig.js
make sure moduleResolution
is set to node16
Is
tsconfig.js
make suremoduleResolution
is set tonode16
Too few information: When does this help and where? Are you suggesting to set moduleResolution: node16
in the project (NextJS project) that is using troublesome (non-mjs peerdeps) libraries?
Is
tsconfig.js
make suremoduleResolution
is set tonode16
Too few information: When does this help and where? Are you suggesting to set
moduleResolution: node16
in the project (NextJS project) that is using troublesome (non-mjs peerdeps) libraries?
yes the tsconfig in Nextjs.
Facing the same issue when bumping nextjs from 13.2.4
to 13.3.1
on liveReload.
It still works in 13.2.4
, but breaks as soon I bump to 13.3.1
.
error - file:///Users/marco/code/blog/node_modules/next-contentlayer/dist/hooks/useLiveReload.js:1
import { addMessageListener } from 'next/dist/client/dev/error-overlay/websocket.js';
^^^^^^^^^^^^^^^^^^
SyntaxError: Named export 'addMessageListener' not found. The requested module 'next/dist/client/dev/error-overlay/websocket.js' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:
import pkg from 'next/dist/client/dev/error-overlay/websocket.js';
const { addMessageListener } = pkg;
at ModuleJob._instantiate (node:internal/modules/esm/module_job:124:21)
at async ModuleJob.run (node:internal/modules/esm/module_job:190:5) {
digest: undefined
}
Any thoughts?
@marcofranssen having this issue too with 13.2.4 now with a fresh checkout of my project.
I had to upgrade @swc/helpers in order to resolve another bug. #48593
Seems to related to swc's resolver?
Fixed it with those two steps
"module": "esnext",
"moduleResolution": "node16",
"resolveJsonModule": true,
Looks like this step isn't needed. but feel free to change it if you like.
Follow instructions here to fix the issue: https://nextjs.org/docs/messages/import-esm-externals
Add transpilePackages in next.config.mjs
transpilePackages: ["@nivo/line", "@nivo/colors", "d3-color"],
I'm on next 13.1.2
After some more testing the .mjs extension seems to cause issues, renaming the esm files to .js resolves the issues.
Thank you very much, it works for me
What worked in my case was to remove the curly braces from the import statement in the quoted JS file: "/var/www/nextjs/node_modules/next-contentlayer/dist/hooks/useLiveReload.js"
info - Collecting page data .file:///var/www/nextjs/node_modules/next-contentlayer/dist/hooks/useLiveReload.js:1 import { addMessageListener } from 'next/dist/client/dev/error-overlay/websocket.js'; ^^^^^^^^^^^^^^^^^^
Verify canary release
Provide environment information
What browser are you using? (if relevant)
No response
How are you deploying your application? (if relevant)
No response
Describe the Bug
Next.js fails to resolve sub dependencies correctly and tries to load CJS from ESM modules, causing the build to fail.
@chakra-ui/react a dependency of @saas-ui/react
Saas UI uses exports definition in package.json to define package entries and exports the ESM module as default.
Removing exports or changing default to
import
fixes the issue.However I think Next.js should handle this correctly.
Expected Behavior
Next.js resolves all packages correctly as ESM.
Link to reproduction
https://github.com/msnegurski/test-saas-ui
To Reproduce
Make sure @saas-ui/react@1.2.x is installed (not 1.3)
NEXT-1381