Update to vscode-languageclient 8

[baronfel]

This required mostly just changing the shape of a documentselector (since that was changed in VSCode 3.16 but we never adapted to it). Along the way debugging that, though, I got frustrated with webpack's sourcemap-based debugging not working and ripped it out entirely, replacing it with esbuild (based in part on #1684 but replacing every part of the build).

I also updated to latest fantomas. I believe this is working in its entirety, but before merge I want to:

• have a PR to the languageclient F# types to fix the DocumentSelector bindings
• ensure f5 debugging is still good here (fake integration and whatnot)
• test the built vsix locally

[baronfel]

Something's very off here - LSP features don't seem to be working at all.

[baronfel]

probably going to revert most of this in favor just of the documentselector change - too much change is making it hard to pin down where errors are coming from

[baronfel]

@AngelMunoz I could use some help here if you have time.

The new versions of vscode-languageclient apparently use syntax that the current webpack configuration doesn't understand. When I bundle, I get the following output:

ERROR in ./node_modules/vscode-languageclient/lib/node/main.js 267:50
Module parse failed: Unexpected token (267:50)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
|                 if (node.runtime) {
|                     const args = [];
>                     const options = node.options ?? Object.create(null);
|                     if (options.execArgv) {
|                         options.execArgv.forEach(element => args.push(element));
 @ ./out/Core/LanguageService.js 31:0-55 1059:15-29
 @ ./out/fsharp.js

To me, this means that I need to preprocess this dependency somehow? So I attempted to explicitly include all of the vscode dependencies in the bundling, but that didn't solve it. Do you have any ideas?

I'd like to not take on the esbuild transition in this work, because I've tried it and ended up with the extension not working at all, so I'm a little frazzled :(

[AngelMunoz]

I'll try to give it a check tomorrow but this looks odd, is the language client available in vscode itself at runtime? you could mark it as an external in the webpack config (just like vscode is an external) if that's the case, otherwise we might want to take this babel plugin to fix this particular issue
https://babeljs.io/docs/en/babel-plugin-proposal-nullish-coalescing-operator

[Krzysztof-Cieslak]

is the language client available in vscode itself at runtime?

No, it's just a normal npm package that we add as our dependency.

[baronfel]

ok, I've added that plugin, but it's not getting triggered because we exclude all of node_modules from being loaded by any loader. is this a good behavior? should we include (some subset of) node_modules in our transformations?

[baronfel]

I have added a loader rule to load all of the vscode dependency js files, and we now build. However when testing loading the extension fails at runtime with the following error:

[2022-07-11 09:36:32.698] [exthost] [error] TypeError: Cannot assign to read only property 'exports' of object '#<Object>'
	at Module.<anonymous> (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:9794:16)
	at Module../node_modules/semver/internal/debug.js (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:9795:30)
	at __webpack_require__ (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:21:30)
	at Object../node_modules/semver/internal/re.js (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:9873:13)
	at __webpack_require__ (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:21:30)
	at Object../node_modules/semver/index.js (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:9697:18)
	at __webpack_require__ (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:21:30)
	at Object../node_modules/cross-spawn/lib/parse.js (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:1157:14)
	at __webpack_require__ (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:21:30)
	at Object../node_modules/cross-spawn/index.js (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:1034:13)
	at __webpack_require__ (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:21:30)
	at Module../out/paket-files/ionide/ionide-vscode-helpers/src/Helpers.js (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:95450:69)
	at __webpack_require__ (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:21:30)
	at Module../out/Core/Utils.js (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:68830:115)
	at __webpack_require__ (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:21:30)
	at Module../out/fsharp.js (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:95116:72)
	at __webpack_require__ (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:21:30)
	at c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:85:18
	at Object.<anonymous> (c:\Users\chethusk\OSS\ionide-vscode-fsharp\release\fsharp.js:88:10)
	at Module._compile (node:internal/modules/cjs/loader:1163:14)
	at Object..js (node:internal/modules/cjs/loader:1216:10)
	at Module.load (node:internal/modules/cjs/loader:1035:32)
	at node:internal/modules/cjs/loader:876:12
	at Function.<anonymous> (node:electron/js2c/asar_bundle:5:13343)
	at Function.<anonymous> (c:\Users\chethusk\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:111:32133)
	at Function.<anonymous> (c:\Users\chethusk\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:111:28715)
	at Function._load (c:\Users\chethusk\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:106:61601)
	at Module.require (node:internal/modules/cjs/loader:1059:19)
	at require (node:internal/modules/cjs/helpers:102:18)
	at Function.r [as __$__nodeRequire] (c:\Users\chethusk\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\loader.js:5:101)
	at w._loadCommonJSModule (c:\Users\chethusk\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:111:30173)
	at w._doActivateExtension (c:\Users\chethusk\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:97:14758)
	at w._activateExtension (c:\Users\chethusk\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:97:13706)
	at processTicksAndRejections (node:internal/process/task_queues:96:5)
	at async b._activate (c:\Users\chethusk\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:85:8180)
	at async b._waitForDepsThenActivate (c:\Users\chethusk\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:85:8122)
	at async b._initialize (c:\Users\chethusk\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:85:7486)

Some googling suggests that there are different module styles being used here - is there a way to centralize on one easily? Will this require bundling all of node_modules?

[baronfel]

ok, we don't need babel at all in newer versions of webpack! I've updated us and we're all set as far as I can tell.

[Krzysztof-Cieslak]

LGTM