Replies: 1 comment 5 replies
-
|
I currently get around this personally by using a custom Which actually works for now, but overall feels hacky and is depending on timing that is not guaranteed by NextJS |
Beta Was this translation helpful? Give feedback.
5 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the feature you'd like to request
NextJS currently requires code be executed as CommonJS.
Packages in
node_modulesdo this automagically with custompackage.jsonthat will declare"type":"commonjs"or omit the type (and default to commonjs)Code in the
.nextdirectory does not have this luxury, and is stuck using the root packagestype. And because all code is transpiled to commonjs, that forces to top-level package to also be commonjs.Describe the solution you'd like
The best solution to me is simply writing a
package.jsonin the.nextdirectory with the content{ "type": "commonjs" }That allows NextJS to do everything with CommonJS, while simultaneously freeing up the root package to use whatever type they prefer.
Even if they are already using
commonjsthe newpackage.jsonis at the least a NOOPDescribe alternatives you've considered
Change transpiled code to matched the package's type.
This sounds like a lot more work, and probably isn't feasible for use cases like hot reloading, which the current solution requires usage of things like
require.cache, which do not yet have similar solutions in an ESM environment.Beta Was this translation helpful? Give feedback.
All reactions