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.

[Malix-off]

I personally am desperate to make typescript + vite work for VSCode extension development.

It seems that any tsconfig.json (https://github.com/Malix-off/VSC-Extension-StashFlow/blob/dev/tsconfig.json) and vite.config (https://github.com/Malix-off/VSC-Extension-StashFlow/blob/dev/vite.config.ts) I tried didn't worked

I think it might be tied to that issue.
Do you guys found a workaround?

Update:

1. ESNext TS + Vite works now!
   Thanks a lot to @rxliuli for chore: Update vite config of build cjs output Malix-off/VSC-Extension-StashFlow#4 ❤️

[theoludwig]

#196941 The next Electron is 27 not 28...

The next one is now Electron v28.
Progress can be tracked here: #201935

We should be able to close this issue very soon! 😄

[JustinGrote]

I personally am desperate to make typescript + vite work for VSCode extension development.

It seems that any tsconfig.json (https://github.com/Malix-off/VSC-Extension-StashFlow/blob/dev/tsconfig.json) and vite.config (https://github.com/Malix-off/VSC-Extension-StashFlow/blob/dev/vite.config.ts) I tried didn't worked

I think it might be tied to that issue. Do you guys found a workaround?

Update:

1. ESNext TS + Vite works now!
   Thanks a lot to @rxliuli for chore: Update vite config of build cjs output Malix-off/VSC-Extension-StashFlow#4 ❤️

FYI pretty sure this won't work inside a vscode runner with vscode-test, because the vitest runner is ES only.

[Malix-off]

I didn't use vitest, so can't confirm

[starball5]

Related on Stack Overflow: How do I import an ES6 JavaScript module in my VS Code extension written in TypeScript?

[alexandruavadanii]

Looks like #203956 was just merged in main, so the next one of the next Insiders builds will be based on Electron 28 (probably after the endgame release from the stable branch is verified).

[igorskyflyer]

Looks like #203956 was just merged in main, so the next one of the next Insiders builds will be based on Electron 28 (probably after the endgame release from the stable branch is verified).

[estruyf]

Great news, the latest Insiders build includes Electron 28!

A big step forward, but now the VSCode loader needs to support ESM as well before we can use it in extensions.

[alexandruavadanii]

I'm not familiar enough with js, so I don't know how much of this is still relevant, but an issue has been waiting in the vscode-loader repo at microsoft/vscode-loader#36 for a while. Maybe others do have expertise in that area and can chime in.

[lppedd]

So the answer is we're still mid-way. The base platform now supports ES modules, but the VS Code infrastructure doesn't.
Correct?

[lppedd]

Btw, there is also the question of Web Extensions to consider.

IIRC as of now we compile them using CJS. And I suppose the base framework needs to be updated to handle ESM imports.

[metawrap-dev]

I have a project that depends on being able to load ESM into VSCode extensions, which I assume also means that VSCode extensions themselves need to be ESM.

I'm considering downgrading the project to CJS.

Should I wait? Is a fix to this weeks away or months... or more?

[itsdouges]

Hi folks — can you confirm dynamic imports should work in VSCode extensions? When running my code for production (i.e. it's packaged and installed) I'm getting an Invalid host defined options error:

[error] TypeError: Invalid host defined options
    at Object.module.exports.<computed> [as createServer] (/Users/douges/.vscode/extensions/triplex.triplex-vscode-0.0.1/node_modules/vite/index.cjs:23:36)

Which, when zooming to that line of code, is this highlighted line:

// vite/index.cjs
asyncFunctions.forEach((name) => {
  module.exports[name] = (...args) =>
+    import('./dist/node/index.js').then((i) => i[name](...args))
})

Leading me to believe it's not supported. Could it be because Vite has this in a cjs file? Something else?

Edit: I've seen microsoft/vscode-loader#36. Seems quite relevant and matches my experience.

[lppedd]

@metawrap-dev imo you should switch to CJS.

Don't make plans based on what you read on issues. Not the first time highly requested features take years to land.

[JustinGrote]

@itsdouges @metawrap-dev as of today, the general recommendation is to use a bundler like esbuild (recommended) or rollup and use their features/plugins to convert ES modules to CJS automatically. They can even translate default imports and you can use import syntax in your code which will get translated to the require syntax by the bundler, so when ESM is available you don't have to go back and change all that.

Generally have had no issues with this, the only major roadblock I've seen is you can't run E2E in-vscode testing using testing frameworks that require ESM such as vitest, but mocha is the de-facto standard used by everything including the official vscode test cli and you can still run tests that don't need/reference the vscode api or mock it in whatever framework you want.

[itsdouges]

I understand. Unfortunately there are a few packages that don’t work well with bundling, so I’m doing both: bundling but marking dependencies that can’t be bundled as external.

…

On Tue, 23 Apr 2024 at 1:33 AM, Justin Grote ***@***.***> wrote: @itsdouges <https://github.com/itsdouges> @metawrap-dev <https://github.com/metawrap-dev> as of today, the general recommendation is to use a bundler like esbuild (recommended) or rollup and use their features/plugins to convert ES modules to CJS automatically. They can even translate default imports. Generally have had no issues with this, the only major roadblock is you can't run E2E in-vscode testing using testing frameworks that require ESM such as vitest, but mocha is the de-facto standard used by everything including the official vscode test cli and you can still run tests that don't need/reference the vscode api or mock it in whatever framework you want. — Reply to this email directly, view it on GitHub <#130367 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABT4PHLAMN2URABDSREZXZDY6UUTLAVCNFSM5BYXHNA2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBWHE4TCMRQGMYQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[metawrap-dev]

@itsdouges @metawrap-dev as of today, the general recommendation is to use a bundler like esbuild (recommended) ...

Thanks. That's exactly what I did as a workaround. I am glad that you have confirmed the choice,