Repository navigation
Enable consuming of ES modules in extensions #130367
Description
Activity
(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:Reacted by Christoph Thiede, Rafid Muhymin Wafi, Igor Dimitrijević, Alexander Ozhigin, Spencer Miller, Yuri Gadow, Thomas Wang, Théo LUDWIG, Ali Sawari, Lewis and 43 more- assigned and unassigned
on Aug 10, 2021 Closing after 15 days of no reply.
Reacted by Mr Beedell, Roke Julian Lockhart, Vitaliy Sugrobov, Adifyr and AFCMSReacted by Luiggy Macias and Vitaliy SugrobovReacted by Lemmingh, Igor Dimitrijević, Andrew Plummer, Jason Williams, Sam, ELLIOTTCABLE, Telmo Gomes, Hubert Kuoch, Alexandr Berbat, Ali Sawari and 37 more- Reacted by Igor Dimitrijević and Tufan Al-Aqsa
- added this to the Backlog Candidates milestone
on Aug 25, 2021 This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
Reacted by Igor Dimitrijević and Robson Oliveira157 remaining items
Status of Web Worker support for import maps:
WICG/import-maps#2
whatwg/html#10858The whatwg/html#10858 (comment) from the author of that PR suggests that this is stalled just because they don't want to push it over the finish line if no one is going to implement. So it seems that at the moment someone needs to convince browsers to step up and actually care about finishing import-map support.
Reacted by Eli, Sebastian Danielsson, Tomáš Hübelbauer and Abbey Hawk Sparrow- added a commit that references this issue
on May 13, 2026 I've been following this issue for a while and as I was just cleaning up my house I was thinking about this. (About to start a new extension in a few days 🤞🏻)
Would it be possible to shim out web worker support here? https://github.com/guybedford/es-module-shims was the import map polyfill back in the day, and it supported web workers. I just took another look and judging from the issues, I think vs code could still use it to shim out the
vscodeimport in workers so long as they're not service workers.Apologies if a similar approach has already been considered, it just seemed from the comments above that the team was open to alternatives to waiting on standardization.
(Also, my apologies for any typos, I'm typing this on my phone because I wanted to get it down before I forgot)
EDIT: And now that I posted, this probably should have gone in the loader repository but oh well 🤷🏻♂️
Reacted by Igor DimitrijevićReacted by Igor Dimitrijević- added a commit that references this issue
on Jul 2, 2026 🤖 Thanks for the report and the follow-up context. This is now implemented for the Node extension host in commit 15260e7 via #245214 and is contained in 1.100.0 and later. Current main detects .mjs / package type "module" extension entry points and loads them with import(...), and #248286 added the hybrid path for extensions that use ESM in the Node extension host and CJS in the web worker extension host. I think this can be closed as completed; any remaining request for ESM in the web worker extension host should be tracked separately.
Reacted by Igor Dimitrijević, Adam Wójcik, Malix - Alix Brunet, Suraj, zWing, mizdra, FreeCoderX, Nerixyz, Théo LUDWIG, Felipe Santos and 6 moreReacted by Igor DimitrijevićReacted by Igor Dimitrijević, Adam Cook, Christian Svensson, manish-techverito and Daniel BayleyReacted by Igor DimitrijevićReacted by Igor Dimitrijević- added a commit that references this issue
on Aug 20, 2026 Does there exist an issue for ESM in the web worker extension host?
Reacted by ExE Boss, Eli and stefnotch
When developing extensions and using either JavaScript or TypeScript we are unable to consume ES modules, only somewhat legacy CommonJS modules, setting the
typetomoduleand rewriting the extension to useimportinstead ofrequirebreaks the extension, generating an exception that states that all modules should useimportinstead ofrequirein internal VS Code JavaScript files, I conclude it's caused by thetype: modulethat forces Node to treat all.jsfiles 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.mjsextension, 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,
esbuildbecause 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?