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

Build Theia as ESM modules #13272

Open
tsmaeder opened this issue Jan 15, 2024 · 3 comments
Open

Build Theia as ESM modules #13272

tsmaeder opened this issue Jan 15, 2024 · 3 comments

Comments

@tsmaeder
Copy link
Contributor

Feature Description:

Currently, Theia is published to npm as a bunch of CommonJS modules. This works fine, but might start to have disadvantages in the future:

  1. We use the ESM build of VS Code for the monaco editor, but consume it as CJS modules: forcing the module type to ESM breaks our uses of vscode stuff in our tests. Since we currently use Webpack for the back end also, the productive build seems to work. However, we need to patch some files in the ESM VS Code build that use the export keyword to use the CJS export convention
  2. More and more published modules switch to ESM-only format: in order to use such modules from CJS modules, we'd have to use the async require function. Webpack can alleviate this problem, unless the modules use "top level async" functionality.
  3. We can't properly tree-shake CJS modules. We could probably expect our artifacts to be around 30% smaller if we could. With our front end artifacts clocking in at around 10mb, using optimized ESM modules might make startup quite a bit faster on slowish connections.
@tsmaeder
Copy link
Contributor Author

@sdirix, @msujew , @JonasHelming and @tsmaeder had a discussion about this and here's a couple of results:

  • Moving to ESM would be a breaking change for our adopters: not only would they have to fix their build, but you have to explicitly export symbols from your package, many symbols which are exported now would become private. On the other hand, this would give us more control over what we consider API.
  • Offering both a ESM and CommonJS build of Theia is probably unfeasible: if we start using VS Code as a real ESM build mixing the module formats does not make sense.
  • Since we can "fix" the VS Code build to work as a CJS modules, we are under no immediate pressure to move to ESM. It's a bit more work for each monaco uplift, but probably doable.

Overall, we decided moving to ESM is a mid-term project that needs more consideration before implementation.

@msujew
Copy link
Member

msujew commented Oct 7, 2024

@tsmaeder Now that VS Code's source code is almost completely ESM (see microsoft/vscode#226260), has anything on that last post changed? Can we still consume everything as is?

@tsmaeder
Copy link
Contributor Author

tsmaeder commented Oct 7, 2024

I've prototyped consuming the esm build of VS Code and that seems to work with a couple of webpack magic. As for points 1 and 2 above, I don't think anything has changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants