Replies: 10 comments 4 replies
-
|
Actually, this kind of resolution is also supposed to work under |
Beta Was this translation helpful? Give feedback.
-
|
Seems like part of this limitation might be in the Webpack module resolution step. Adding: config.resolve.extensionAlias = {
'.js': ['.js', '.ts', '.tsx']
};...to next.config.js is a partial workaround, but the generated webpack modules are still using require() calls, so code like this: import { default as _NextDoc, Html, Head, Main, NextScript } from 'next/document.js';
const Document = _NextDoc.default;...will produce different results under Node16/NodeNext than Node module resolution. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! Adding the We can't use the new |
Beta Was this translation helpful? Give feedback.
-
|
After more research, the second part of the issue above (importing default from next/document.js) is a difference between how Node.js imports CommonJS modules from ESM and how web browsers would attempt to do the same (which is governed by the packing technology, webpack). So it honestly doesn't make a lot of sense to use nodenext/node16 moduleResolution in the Next.js page files, but I want to use it for the rest of the server, so I don't know exactly what to do here. I doubt I can set two different module settings for my project. Will post back if I can find a solution. |
Beta Was this translation helpful? Give feedback.
-
|
Actually, there's one clear solution that would be the simplest for the end user: Have webpack fully emulate Node16/NodeNext, up to and including the way Node imports CommonJS modules. |
Beta Was this translation helpful? Give feedback.
-
|
Also been having CJS interop issues with libraries like react-avatar - node under ESM loads import reactAvatar from 'react-avatar';properly having put everything on the default object as per its interop spec, whereas next throws While not being a generic fix per se, in order to get past this what i've done is normalized to the nodejs usage through yarn patches. So for react-avatar for example, what i did was re-export the ESM version with a single default export that matches what node does. |
Beta Was this translation helpful? Give feedback.
-
|
I’m experimenting with At the time of writing (Next 13.0.1), I need to apply two hacks: Tweak next.config.js webpack: (config) => {
return {
...config,
resolve: {
...config.resolve,
extensionAlias: {
".js": [".js", ".ts"],
".jsx": [".jsx", ".tsx"],
},
},
};
},Hack typings for some default imports -import x from "x";
+import _x from "x";
+const x = _x as unknown as typeof _x.default;Details: microsoft/TypeScript#50058 (comment) Not sure if it’s production-ready yet. |
Beta Was this translation helpful? Give feedback.
-
|
First of all, a huge thank you to @kachkaev - you just solved an issue that I've been trying to fix for days now. All it took was setting the // next.config.js
const NEXT_CONFIG = {
webpack(config) {
config.resolve.extensionAlias = {
".js": [".js", ".ts"],
".jsx": [".jsx", ".tsx"],
};
return config;
},
};
export default NEXT_CONFIG;But even though the resolution to my problem was the same, I think my problem was 'reversed' in a sense. My I was having an issue using code from my library package that I was importing into my Next project. I'm using SWC to compile that library, and then I was attempting to install and use it in the aforementioned Next project. Everything I imported from the library worked server-side, but threw an error when the page was loaded in the browser. This ended up being because Node was able to properly resolve code from my library, but the browser was not. |
Beta Was this translation helpful? Give feedback.
-
|
I also had to apply a third "hack": Importing local images, i.e. using /// <reference types="next/image-types/global.js" /> |
Beta Was this translation helpful? Give feedback.
-
|
I find it a little surprising that the I'm on 13.4.9 |
Beta Was this translation helpful? Give feedback.
-
|
Just to note, I also needed to change tailwind.config.cjs -> tailwind.config.js |
Beta Was this translation helpful? Give feedback.
-
|
How are you solving importing the import Image from 'next/image.js'
<Image /> // error: 'Image' cannot be used as a JSX component. |
Beta Was this translation helpful? Give feedback.
-
|
You don't, because NextJS itself cannot into Node ESM output. Just use |
Beta Was this translation helpful? Give feedback.
-
|
*Sigh* fine, I'll bite. Introducing next-turbopack-nodenext - a package that patches your Next.js config so that Turbopack could resolve fully specified https://github.com/wojtekmaj/next-turbopack-nodenext
|
Beta Was this translation helpful? Give feedback.
-
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 now has support for ES Modules, and there have been several patches that seem to support using module mode for the main project, but Next.js can't resolve TypeScript files when using NodeNext or Node16 module resolution, which means specifying a .js extension for an import even if the target file is a .ts/.tsx file. Next.js/SWC will complain that a module can't be resolved even though TypeScript shows no errors.
I can't use babel.config.js to change the behavior as mentioned here because Next.js tries to require() it, which doesn't work in an ESM project, and Next.js refuses to attempt to load a .cjs config file.
Expected Behavior
Next.js/SWC should resolve the TypeScript module the way TypeScript does when NodeNext/Node16 module resolution is in effect.
Link to reproduction
https://github.com/fluggo/nextjs-module-resolution-bug
To Reproduce
Just run the project linked above. You should see the error:
Running
npx tsc --noEmit, though, produces no errors.Beta Was this translation helpful? Give feedback.
All reactions