-
Notifications
You must be signed in to change notification settings - Fork 86
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
fix: apply type: module only to runtime modules #2549
Conversation
📊 Package size report 0%↑
Unchanged files
🤖 This report was automatically generated by pkg-size-action |
src/build/functions/server.ts
Outdated
await writeFile( | ||
join(ctx.serverHandlerRootDir, 'package.json'), | ||
join(ctx.serverHandlerRootDir, '.netlify', 'package.json'), | ||
JSON.stringify({ type: 'module' }), | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not quite sure if this is a correct fix (or rather if this is full fix) - we definitely shouldn't be setting type: 'module'
for entire handler directory in every case (which is what cause the problem right now).
We definitely should either set it for our runtime modules we copy to handler (which is what this PR does right now) OR make runtime emit .mjs
files and not .js
ones to dist
.
But part that I'm not sure about is wether type: 'module'
should be set in root of handler in case user use this mode? I'll run some experiments here, but in case someone is familiar - I'm happy for any heads up on that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I did update it since this comment - Next.js does output their own package.json
in root of standalone which we were ignoring when copying from it. With my changes we copy it over (this is really just copy of site's package.json so it inherit site's type
essentially) + create package.json just for runtime modules (possibly this could be avoided if we emitted .mjs
files for runtime modules, but my initial attempt at that resulted in problems so I didn't pursue this too much)
|
||
export async function GET() { | ||
return NextResponse.json({ | ||
notBundledCJSModule: __non_webpack_require__(resolve('./cjs-file-with-js-extension.js')), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
__non_webpack_require__
turns into regular require
in compiled output (instead of inlining modules by webpack) which is needed to reproduce the ERR_REQUIRE_ESM
problem (without usage of 3rd party packages)
5936c4c
to
e58d640
Compare
e58d640
to
e3308f1
Compare
// this will include the node_modules folder as well | ||
if (entry === 'package.json' || entry === ctx.nextDistDir) { | ||
if (entry === ctx.nextDistDir) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we are no longer writing top level package.json (we write it just for runtime modules, so it no longer is top-level), hence this copies top-level package.json provided by Next.js (which is really just site's package.json) so it will "inherit" type
from user's site
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great 🚢
Description
We are setting entire request handler function dir as
type: 'module'
right now, which result inERR_REQUIRE_ESM
kind of errors when.js
file which is actually CJS is being required.Documentation
Tests
Integration and e2e test added using same fixture - both fail. Integration test output https://github.com/netlify/next-runtime/actions/runs/9992611474/job/27618021931?pr=2549#step:12:151 showing
ERR_REQUIRE_ESM
error (e2e only see 500 status, as error is hidden in function logs).Second commit makes them pass.
Relevant links (GitHub issues, etc.) or a picture of cute animal