Fix the exports of vscode-languageserver-types

[remcohaszing]

The exports field is needed for dual publishing CJS and ESM. The module field on the other hand, is a non-standard property. Some bundlers incorrectly interpret it, causing interop issues.

An additional package.json file is written to mark the ESM output as actual ESM.

I don’t really like this solution, but it works.

This may break projects that rely on hacks to use the faux ESM. That could be resolved by adding more exports to support all old paths. I’m not convinced this is an issue.

Correctness can be tested on https://arethetypeswrong.github.io. Note that it currently states that the version on npm is ok due to a false negative.

My personal recommendation would be to stop dual publishing to avoid the dual package hazard among other complexities. This still stands, but it would be a breaking change.

[remcohaszing]

It turns out only vscode-languageserver-types and vscode-languageserver-textdocument published faux ESM, so this PR is ready as-is.

[dbaeumer]

@aeschli can you have a look. I remember that you added the ESM support to types and text documents and I don't know in which use cases we need this and if they are still covered.

[aeschli]

@remcohaszing Yes, our node modules layout need to properly adopt ESM modules.

Many packages fully move to esm, but, as you say, that's a breaking change and will cause an outcry.

I read up on how to publish a hybrid. https://www.sensedeep.com/blog/posts/2021/how-to-create-single-source-npm-module.html supports your suggestion.
Should we add a package.json to the umd folder as well?

[remcohaszing]

For the .js extension, Node.js looks up the closest package.json. For the umd folder, this is the package.json, which (implicitly) specifies those files are CJS.

The package.json file in the esm folder is needed to mark the files in that folder as ESM.

This could be swapped, but it's less convenient. This is in part because TypeScript isn't meant for dual publishing.

Also note that I created microsoft/vscode#192144 as an umbrella issue for the exports of several VSCode client libraries. It contains some more general details.

[aeschli]

The changes look good. I tested that consuming the esm script work from our webpack files in VS Code, no client side changes needed.

I added a commit that updates the target to es6. Any objections?

[rcjsuen]

Could this be the reason why RunKit is broken for this library?

var vscodeLanguageserverTypes = require("[email protected]"); // ok
var vscodeLanguageserverTypes = require("[email protected]"); // ok
var vscodeLanguageserverTypes = require("[email protected]"); // does not work

I have tried using RunKit for my own library and it seems after changing to 3.17.3 it won't run anymore... 🤔

[remcohaszing]

I would like to address any concerns in this and related PRs once I get back from vacation next week.

[remcohaszing]

I just posted them here: microsoft/vscode#192144 (comment)

Anyway, I think this PR is mostly fine now.

[remcohaszing]

@rcjsuen:

Could this be the reason why RunKit is broken for this library?

var vscodeLanguageserverTypes = require("[email protected]"); // ok
var vscodeLanguageserverTypes = require("[email protected]"); // ok
var vscodeLanguageserverTypes = require("[email protected]"); // does not work

I have tried using RunKit for my own library and it seems after changing to 3.17.3 it won't run anymore... 🤔

Sorry, I have no clue why this is broken. This looks like a RunKit issue.

[remcohaszing]

@aeschli:

I added a commit that updates the target to es6. Any objections?

Do you target a specific Node.js version? I recommend looking at https://github.com/tsconfig/bases/tree/main/bases to pick a target. Most notably IMO, a target of es2017 means async/await is supported without downleveling, and es2018 adds support for for await...of. That means targeting Node.js 10, which is already far beyond EOL.

[aeschli]

Thanks for the limk, yes then we should go to a more modern version such as es2018.
@dbaeumer Has just made a new release of the LSP libraries, so will do it for the next update.