Enable consuming of ES modules in extensions

[igorskyflyer]

When developing extensions and using either JavaScript or TypeScript we are unable to consume ES modules, only somewhat legacy CommonJS modules, setting the type to module and rewriting the extension to use import instead of require breaks the extension, generating an exception that states that all modules should use import instead of require in internal VS Code JavaScript files, I conclude it's caused by the type: module that forces Node to treat all .js files as ES modules. Tried using TypeScript which transpiles its own syntax to CommonJS module - so that's a no, I have also tried using just .mjs extension, again the same issue.

What is the status of this issue and are there plans to enable using of ES modules in extension development? That (could) bring somewhat big performance gains when bundling extensions with, for example, esbuild because it would enable tree-shaking - dead code removal, thus loading only necessary code. But I think this is not an extension API only issue, right? This needs to be done for VS Code itself?

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Intellisense vs JavaScript Modules - lack of ".js" in completion (#126171)

[igorskyflyer]

Closing after 15 days of no reply.

[alexdima]

cc @jrieken

[Lemmingh]

Sounds like a duplicate of #116056. Is it possible to reopen that issue?

---

The VS Code extension host currently only accepts CJS module, as shown in the (trimmed) error message below:

Activating extension failed

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module
require() of ES modules is not supported.

Instead change the requiring code to use import()

at internal/modules/cjs/loader.js:823:14

at require (internal/modules/cjs/helpers.js:88:18)
at Function.t [as __$__nodeRequire] (c:\Program Files\Microsoft VS Code\resources\app\out\vs\loader.js:5:101)
at v._loadCommonJSModule
at v._doActivateExtension
at v._activateExtension (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:99:11695)

However, I think ES module will be more convenient in future.

Besides, TypeScript can transpile dynamic import() in CJS module in a surprising way (microsoft/TypeScript#43329), while it's never a problem in ES module where import() is emitted as is. VS Code extension authors can benefit from building extension as ES module.

[andyleejordan]

For what it's worth, I ran into this trying to update node-fetch from 2.x to 3.x, since the newer version is ESM only. Looks to be the direction things are going, so extension developers are only more likely in the future to run into issues due to lack of ESM support.

[andyleejordan]

FYI @TylerLeonhardt one of the Code issues I'd love to see fixed 😃

[Lemmingh]

TypeScript 4.5 will perhaps have a new module option called node12, which preserves import() in CJS module. Then, although your entry point still have to be a CJS module now, you can load ES modules internally in an asynchronous manner.

See

• https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/

• TypeScript 4.5 Iteration Plan TypeScript#45418 (comment)

• The links in my comment

[andyleejordan]

Excuse me, @TylerLeonhardt, do you know why my comment above was marked as spam? I have to assume that was a mistake.

[alexdima]

@andschwa I'm sorry, it might have been me that marked the comment as spam, but I don't remember doing it. I personally tend to hide comments that do not bring any value to the underlying discussion or distract from it.

[mark-wiemer]

For SEO, here is a similar error message I've received for an LSP extension after packaging and installing VSIX. It appeared in the Output view > Extension Host channel

2024-09-28 11:15:57.990 [info] ExtensionService#_doActivateExtension mark-wiemer.vscode-autohotkey-plus-plus, startup: false, activationEvent: 'onLanguage:ahk2'
2024-09-28 11:15:58.013 [error] Activating extension mark-wiemer.vscode-autohotkey-plus-plus failed due to an error:
2024-09-28 11:15:58.013 [error] Error [ERR_REQUIRE_ESM]: require() of ES Module c:\Users\markw\.vscode\extensions\mark-wiemer.vscode-autohotkey-plus-plus-6.1.2\dist\extension.js from c:\Users\markw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\bootstrap-fork.js not supported.
Instead change the require of extension.js in c:\Users\markw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\bootstrap-fork.js to a dynamic import() which is available in all CommonJS modules.
    at c._load (node:electron/js2c/node_init:2:13801)
    at y._load (c:\Users\markw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:184:6031)
    at i._load (c:\Users\markw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:181:32144)
    at n._load (c:\Users\markw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:146:34326)
    at Module.require (c:\Users\markw\.vscode\extensions\github.copilot-chat-0.20.3\dist\extension.js:48:34588)
    at i (c:\Users\markw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\bootstrap-fork.js:3:98)
    at m.xb (c:\Users\markw\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:181:33345)
    at async Promise.all (index 0)

[TomasHubelbauer]

VS Code 1.94 now ships the ESM build in the stable channel:
https://code.visualstudio.com/updates/v1_94#_esm-is-shipping-for-vs-code

I tested using ESM in extensiom code and that still appears to be unsupported, but hopefully VS Code now shipping ESM means this limitation will be lifted, soon.

[tats-u]

Hmm, we should wait vm.Modules.... nodejs/node#37648
Possibly require(esm) might also be an escape hatch in the near future:
nodejs/node#52697
nodejs/node#55085
nodejs/node#55217

[yxw007]

Latest vscode I use esm work fine 🎉🎉🎉

[typed-sigterm]

Latest vscode I use esm work fine 🎉🎉🎉

Unfortunately "type": "module" hasn't been supported yet

[CoffeeChaton]

Latest vscode I use esm work fine 🎉🎉🎉

Which repositories?

This target is cjs
https://github.com/yxw007/vscode-translate-next/blame/c61d60d16d86b0d674a35314aeaa54b05c6b1c22/esbuild.js#L32-L33

[JustinGrote]

Latest vscode I use esm work fine 🎉🎉🎉

Which repositories?

This target is cjs yxw007/vscode-translate-next@c61d60d/esbuild.js#L32-L33 (blame)

Agreed, very important to clarify using ESM modules and compiling to CJS is not the same as using them "natively"

[igorskyflyer]

Latest vscode I use esm work fine 🎉🎉🎉

Which repositories?
This target is cjs yxw007/vscode-translate-next@c61d60d/esbuild.js#L32-L33 (blame)

Agreed, very important to clarify using ESM modules and compiling to CJS is not the same as using them "natively"

@yxw007,
this was always possible... Currently, only VS Code itself runs with ESM, extensions still don't allow it.

[yxw007]

@igorskyflyer @CoffeeChaton @JustinGrote
I just changed the packaging results to esm for testing, and found that it cannot be used normally, but it is still possible to use esm in the code.

[JustinGrote]

@igorskyflyer @CoffeeChaton @JustinGrote
I just changed the packaging results to esm for testing, and found that it cannot be used normally, but it is still possible to use esm in the code.

You need to be very careful what you are saying. You are not "using esm", you are transpiling to commonjs, it's a big difference.

[NullVoxPopuli]

So can we use untranspiled ESM?
like, if I author extension in JS (in ESM), I should be able to ship it without compiling?

[JustinGrote]

@NullVoxPopuli not yet, while vscode itself is using ESM now, the extension engine is still bootstrapped via AMD, so extensions still have a commonjs entrypoint and thus need to continue to be commonjs when compiled.

[felipecrs]

Maybe someone from vscode can clarify what is the game plan to get ESM support for extensions?

[JustinGrote]

I am not a vscode team member, but it has to be fixed in the vscode-loader repository is my current understanding, here is the upstream issue for that: microsoft/vscode-loader#56

[ilg-ul]

the upstream issue for that: microsoft/vscode-loader#56

That issue is dated February 29, 2024 and it doesn't seem very active. :-(

Is this the only remaining issue to be fixed?

[axefrog]

@alexdima @jrieken Hey any chance you could weigh in on this? I've been Googling for about half an hour and it's quite hard to find any kind of definitive advice on what those of us implementing a VSCode extensions should be doing given how much of the world has moved on to ESM modules by default.

[JustinGrote]

@axefrog #130367 (comment)
Just use esbuild or bundler of your choice to compile to commonJS, you can use pretty much all the ESM libraries out there for now, it's just not optimal till this gets resolved.

[NullVoxPopuli]

Compilation is easy.
I want to debug source without transpilation and sourcemaps

[JustinGrote]

Compilation is easy. I want to debug source without transpilation and sourcemaps

VSCode makes sourcemaps really easy to work with so that you pretty much can't tell the difference, you can also use tools like esbuild/register to work with the ts files "directly" (they get transpiled on the fly in node)

[axefrog]

@JustinGrote Thankyou! Works beautifully. For anyone else arriving here, I'm using Bun.build for this. It is shockingly fast.

CLI:

bun build --entrypoints ./src/extension.ts --outdir ./out --target node --format cjs --sourcemap=linked --external vscode --watch

Documentation: https://bun.sh/docs/bundler

[bmingles]

There are now instructions in vscode docs for configuring esbuild:
https://code.visualstudio.com/api/working-with-extensions/bundling-extension#using-esbuild

This can also be auto configured as one of the options when scaffolding a new extension using yeoman