Open Hejtmus opened 1 month ago
Hi @Hejtmus Thank You for your interest in my project!
I have published a new version (1.2.2) that adds support for this, you can now override any esbuild param, check the readme for details.
Let me know if this meets your needs 😃
Thanks James
Wow, that was quick, good job @yarbsemaj. Thanks for your quick reaction.
But I think there is needed one other tweak as apparently it generates cjs code for some parts of code:
Building router
â–² [WARNING] The CommonJS "exports" variable is treated as a global variable in an ECMAScript module and may not work as expecte
d [commonjs-variable-in-esm]
build/edge/_router.js:5:0:
5 │ exports.handler = (event, context, callback) => {
╵ ~~~~~~~
This file is considered to be an ECMAScript module because the enclosing "package.json" file sets
the type of this file to "module":
package.json:39:12:
39 │ "type": "module",
╵ ~~~~~~~~
Node's package format requires that CommonJS files in a "type": "module" package use the ".cjs"
file extension.
I think this is caused by second build, which doesn't apply the override.
Also I saw your usage of spread syntax, I'm not sure if that's an intention, but you can use it like this:
esbuild.buildSync({
entryPoints: [`${edge_directory}/_router.js`],
outfile: `${edge_directory}/router.js`,
format: 'cjs',
bundle: true,
platform: 'node',
...esbuildOverride
})
Sorry, solution I proposed wouldn't fix the warning, as that cjs export is in router's code. For my app I manually replaced it for esm export (which does the trick), but I'm not sure how to accomplish this automatically from esbuild config.
Hello, I was just considering using this adapter, but my application uses top level awaits, which is only supported by esmodules. This adapter enforces commonjs, which negatively influences usability. My suggestion is giving ability to users to override esbuild options, as majority of other adapter does. Best regards, Filip.