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.

[tats-u]

Why is this in not "On Deck" but "Backlog"?

c.f.
#160416
#226260

[tats-u]

There has ever been no one mentioning a concrete error message.

An extension using Pyodide:

#197329

Prettier (v10.0.0):

TypeError: A dynamic import callback was not specified.
	at importModuleDynamicallyCallback (node:internal/modules/esm/utils:228:9)
	at Object.<anonymous> (c:\Users\tatsu\.vscode\extensions\esbenp.prettier-vscode-10.0.0\node_modules\prettier\index.cjs:600:23)
	at u._compile (c:\Users\tatsu\AppData\Local\Programs\Microsoft VS Code\resources\app\out\bootstrap-fork.js:2:1257)
	at Module._extensions..js (node:internal/modules/cjs/loader:1432:10)
	at Module.load (node:internal/modules/cjs/loader:1215:32)
	at Module._load (node:internal/modules/cjs/loader:1031:12)
	at c._load (node:electron/js2c/node_init:2:13801)
	at E._load (c:\Users\tatsu\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:177:6051)
*snip*

 600   │ var prettierPromise = import("./index.mjs");

[tats-u]

In VS Code Exploration available from #160416 (comment), the error message is changed:
The execution of .mjs file itself looks successful.

Cannot find module 'c:\Users\WDAGUtilityAccount\.vscode-exploration\extensions\esbenp.prettier-vscode-10.0.0\node_modules\prettier\internal\internal.mjs' imported from c:\Users\WDAGUtilityAccount\.vscode-exploration\extensions\esbenp.prettier-vscode-10.0.0\node_modules\prettier\index.mjs
Error [ERR_MODULE_NOT_FOUND]: Cannot find module 'c:\Users\WDAGUtilityAccount\.vscode-exploration\extensions\esbenp.prettier-vscode-10.0.0\node_modules\prettier\internal\internal.mjs' imported from c:\Users\WDAGUtilityAccount\.vscode-exploration\extensions\esbenp.prettier-vscode-10.0.0\node_modules\prettier\index.mjs
    at finalizeResolution (node:internal/modules/esm/resolve:265:11)
    at moduleResolve (node:internal/modules/esm/resolve:940:10)
    at defaultResolve (node:internal/modules/esm/resolve:1176:11)
    at nextResolve (node:internal/modules/esm/hooks:866:28)
    at resolve (data:text/javascript;base64,CglleHBvcnQgYXN5bmMgZnVuY3Rpb24gcmVzb2x2ZShzcGVjaWZpZXIsIGNvbnRleHQsIG5leHRSZXNvbHZlKSB7CgkJaWYgKHNwZWNpZmllciA9PT0gJ2ZzJykgewoJCQlyZXR1cm4gewoJCQkJZm9ybWF0OiAnYnVpbHRpbicsCgkJCQlzaG9ydENpcmN1aXQ6IHRydWUsCgkJCQl1cmw6ICdub2RlOm9yaWdpbmFsLWZzJwoJCQl9OwoJCX0KCgkJLy8gRGVmZXIgdG8gdGhlIG5leHQgaG9vayBpbiB0aGUgY2hhaW4sIHdoaWNoIHdvdWxkIGJlIHRoZQoJCS8vIE5vZGUuanMgZGVmYXVsdCByZXNvbHZlIGlmIHRoaXMgaXMgdGhlIGxhc3QgdXNlci1zcGVjaWZpZWQgbG9hZGVyLgoJCXJldHVybiBuZXh0UmVzb2x2ZShzcGVjaWZpZXIsIGNvbnRleHQpOwoJfQ==:13:10)
    at nextResolve (node:internal/modules/esm/hooks:866:28)
    at Hooks.resolve (node:internal/modules/esm/hooks:304:30)
    at handleMessage (node:internal/modules/esm/worker:196:24)
    at Immediate.checkForMessages (node:internal/modules/esm/worker:138:28)
    at process.processImmediate (node:internal/timers:478:21)

Update: a newer build is available: #226399 (comment)

Update: ESM will be enabled since 1.94 (Insiders since early next month)
See #226260

[tats-u]

If the update in the next month or in the current Insiders (1.94) doesn't help, we need to wait for vm.Module. nodejs/node#37648

[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.