Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable consuming of ES modules in extensions #130367

Open
igorskyflyer opened this issue Aug 8, 2021 · 94 comments
Open

Enable consuming of ES modules in extensions #130367

igorskyflyer opened this issue Aug 8, 2021 · 94 comments
Assignees
Labels
extension-host Extension host issues extensions Issues concerning extensions feature-request Request for new features or functionality
Milestone

Comments

@igorskyflyer
Copy link

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
Copy link

vscodebot bot commented Aug 8, 2021

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

@igorskyflyer
Copy link
Author

Closing after 15 days of no reply.

@alexdima
Copy link
Member

cc @jrieken

@alexdima alexdima added extension-host Extension host issues feature-request Request for new features or functionality web Issues related to running VSCode in the web and removed web Issues related to running VSCode in the web labels Aug 25, 2021
@Lemmingh
Copy link
Contributor

Lemmingh commented Sep 3, 2021

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
Copy link
Member

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
Copy link
Member

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

LinqLover added a commit to LinqLover/downstream-repository-mining that referenced this issue Oct 2, 2021
@Lemmingh
Copy link
Contributor

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

@andyleejordan
Copy link
Member

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

@alexdima
Copy link
Member

alexdima commented Nov 1, 2021

@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
Copy link

mark-wiemer commented Sep 28, 2024

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
Copy link
Contributor

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.

@bpasero bpasero mentioned this issue Oct 4, 2024
13 tasks
@tats-u
Copy link
Contributor

tats-u commented Oct 4, 2024

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
Copy link

yxw007 commented Oct 8, 2024

Latest vscode I use esm work fine 🎉🎉🎉

@typed-sigterm
Copy link

Latest vscode I use esm work fine 🎉🎉🎉

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

@CoffeeChaton
Copy link

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
Copy link
Contributor

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
Copy link
Author

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
Copy link

yxw007 commented Oct 9, 2024

@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
Copy link
Contributor

@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
Copy link

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
Copy link
Contributor

@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
Copy link
Contributor

felipecrs commented Oct 31, 2024

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

@JustinGrote
Copy link
Contributor

JustinGrote commented Oct 31, 2024

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
Copy link

ilg-ul commented Oct 31, 2024

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?

ArquintL added a commit to viperproject/vs-verification-toolbox that referenced this issue Nov 7, 2024
@axefrog
Copy link

axefrog commented Nov 20, 2024

@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
Copy link
Contributor

@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
Copy link

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

@JustinGrote
Copy link
Contributor

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
Copy link

axefrog commented Nov 20, 2024

@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
Copy link

bmingles commented Nov 20, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
extension-host Extension host issues extensions Issues concerning extensions feature-request Request for new features or functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.