feat: output uses "type": "module" when esModule is set to true#478
feat: output uses "type": "module" when esModule is set to true#478tichopad wants to merge 2 commits intodenoland:mainfrom
esModule is set to true#478Conversation
This change enables ES module compatibility by automatically adding "type": "module" to the generated package.json when ESM output is included. The test runner code has also been updated to handle ES module environments by adding the necessary import statements and compatibility shims. Key changes: - Modified package.json generation to include "type": "module" field when includeEsModule is true - Updated test runner code generation to add ES module compatibility imports (createRequire, __dirname polyfill) - Updated all test expectations to reflect the new "type": "module" field in generated package.json files This ensures that generated npm packages work correctly in ES module environments while maintaining backward compatibility.
| if (options.includeEsModule) { | ||
| // ensure compatibility with esm ("type": "module") | ||
| writer.writeLine(`import { createRequire } from 'module';`); | ||
| writer.writeLine(`const require = createRequire(import.meta.url);`); | ||
| writer.writeLine( | ||
| `const __dirname = new URL(".", import.meta.url).pathname;`, | ||
| ); | ||
| } |
There was a problem hiding this comment.
I considered polyfilling the safer way to enable ESM compatibility instead of outputting ES modules directly.
| const type = { | ||
| ...(includeEsModule | ||
| ? { | ||
| type: "module", | ||
| } | ||
| : {}), | ||
| }; |
There was a problem hiding this comment.
Includes "type": "module" if esModule: true, otherwise doesn't add the type field at all.
It also still allows the user to explictly overwrite the type field via the build function's config.
| // Copyright 2018-2024 the Deno authors. MIT license. | ||
|
|
||
| import { parse } from "jsr:@std/csv/parse"; | ||
| import { parse } from "jsr:@std/csv@1.0.6/parse"; |
There was a problem hiding this comment.
I added a version specifier to fix a linter error. The version used is based on the latest @std/csv version specified in deno.lock.
| "no-explicit-any", | ||
| "camelcase" | ||
| "camelcase", | ||
| "no-import-prefix" |
There was a problem hiding this comment.
I've run into linter issues with the existing code using inline imports. This rule got added to the default ruleset in Deno 2.5.
My assumption is the project's okay with inline imports, so I decided to exclude the rule instead. Let me know if I should rather refactor inline imports instead.
|
Tests are failing on Windows. Let me take a look later 👍 |
1 participant
Summary:
Sets output package.json
typeto bemodulewhenesModule: trueis used. This ensures the output package is automatically ESM-compatible.Also fixes ESM compat for the generated
test_runner.jsfile by polyfillingrequireand__dirnamein an ESM context.Details:
Users targeting ESM output now have to explicitly add
"type": "module"to the build function's configuration. This makes the output ESM compatible, but breaks the generated test runner.This is potentially a breaking change because of
"type": "module"implications in the output package.Fixes #476
Checks:
deno task test) passing with Node versions 18-24