Fix ESM exports

[remcohaszing]

This uses the package.json exports field to support native ESM. The module field is redundant and can even lead to compatibility issues, so it was removed.

TypeScript project references are used for building the project with two different settings. An additional package.json is written to mark the ESM output as actual ESM. Since ESM requires file extensions, those were added to all imports.

Mocha has been reconfigured to run tests for both CJS and ESM.

Also ESLint has been configured to lint all files in the repo, not just a shell specific glob pattern. As a result, this change contains some small ESLint fixes.

Closes #56
Closes #57

[graham-atom]

any idea on when this will merge?

[Yokozuna59]

Is there any updates on this PR? The workaround stated in #57 for esbuild build:

{
  // ...
  mainFields: ["module", "main"]
}

broke other parts, so the only way to resolve such error would be with this approach.

[remcohaszing]

I rebased and added the module export condition, like in microsoft/vscode-languageserver-node#1386

[remcohaszing]

This is also blocking some downstream issues mentioned in microsoft/vscode#192144

[afonsojramos]

Hi @aeschli, who needs to review this?

[aeschli]

I added an exports section with #90

[remcohaszing]

That PR:

• Didn’t add .js extensions to relative imports, breaking usage from ESM
• Points the import condition to a .js file with a package.json that doesn’t specify "type": "module" (faux ESM), breaking usage from ESM.
• Only has CJS type definitions, which probably works, but is technically incorrect.

The latest version on npm is now broken.

$ cat package.json
{
  "dependencies": {
    "jsonc-parser": "3.3.0"
  }
}
$ node asd.mjs      
(node:134587) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
/home/remco/Projects/test/node_modules/jsonc-parser/lib/esm/main.js:6
import * as formatter from './impl/format';
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at wrapSafe (node:internal/modules/cjs/loader:1376:18)
    at Module._compile (node:internal/modules/cjs/loader:1405:20)
    at Module._extensions..js (node:internal/modules/cjs/loader:1544:10)
    at Module.load (node:internal/modules/cjs/loader:1275:32)
    at Module._load (node:internal/modules/cjs/loader:1091:12)
    at wrapModuleLoad (node:internal/modules/cjs/loader:212:19)
    at cjsLoader (node:internal/modules/esm/translators:318:5)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:258:7)
    at ModuleJob.run (node:internal/modules/esm/module_job:262:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:474:24)

Node.js v22.3.0

[xiaoxiangmoe]

What's the meaning of "module" exports?
I didn't see it in nodejs docs and webpack docs. Where is it used for or where is the official doc for it?

[remcohaszing]

It tells bundlers to use it, even when the module is required from a CJS file. So it helps reduce bundle size and avoid the dual package hazard.

[xiaoxiangmoe]

But the "import" condition is more widely used in webpack, vite and node. Why should we add unofficial "module" condition.

[xiaoxiangmoe]

It seems that remove-sourcemap-refs job is useless. We can set "sourceMap": false in tsconfig. @aeschli

[remcohaszing]

That breaks code coverage and source mapping when running tests.

[adrian-gierakowski]

anything still blocking this?

[afonsojramos]

@aeschli please note the issues referenced above

[aeschli]

The PR removes the AMD/UMD support. Until now I was hesitating to do that as the Monaco editor still uses AMD for its development setup.
It looks like the Monaco editor team is now ok that we remove the AMD support.

• We can go one step further and only publish ESM. Is that still too early?
• We need to create new major version for the API breakage

[remcohaszing]

Personally I would love to go ESM-only. I even advocate for it. But that would definitely be a breaking change.

This affects more than just the VSCode ecosystem. I suggest to discuss the impact with the team internally. Perhaps @jakebailey also has an opinion on this.

I’ll gladly update this PR accordingly

[jakebailey]

There are other alternative packaging tools which would retain the other formats. I sort of suspect that someone's loading UMD in the browser or something, though I'm not sure how to determine that.

If you go ESM only, just please do so in a major bump. Other breaking changes have happened in minor bumps and have been frustrating to work with, but dropping whole module formats would be extra breaky.