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

Large bundle size #678

Open
Lemour-sudo opened this issue Jun 12, 2024 · 10 comments
Open

Large bundle size #678

Lemour-sudo opened this issue Jun 12, 2024 · 10 comments

Comments

@Lemour-sudo
Copy link

I am trying to use the MonacoEditorReactComp along with the language client in an existing project.

The problem is that the addition of this library significantly increases the final bundle size by about 7mb without compression.
This creates a problem for us when deploying our application as the deployment platform enforces a small uncompressed bundle size limit of about 2mb.

Is there a way to reduce the final bundle size? I was thinking if it could also be possible to only run the MonacoEditorReactComp in the existing project such that the final bundle size will be lower, then have the language client running in a separate repo and connect it to the MonacoEditorReactComp through a web socket connection.
I also tried using another monaco react library, https://www.npmjs.com/package/@monaco-editor/react, and it seems to have result in a small bundle size with just a few hundred kbs. But I could not link it to the monaco language client.

@CGNonofr
Copy link
Collaborator

The problem is, if you want to use the language client, you need the VScode api, which needs all the mainThread/extHost stuff which are kind of heavy

The other issue is that monaco-language have ALL service overrides as dependency, and just import it or not depending on the configuration. most of them won't be loaded by the client but it's still present in the bundle @kaisalmen

@kaisalmen
Copy link
Collaborator

The other issue is that monaco-language have ALL service overrides as dependency

That is not true. It only imports this:

└─┬ [email protected] -> .\packages\client
     ├── @codingame/[email protected]
     ├── @codingame/[email protected]
     ├── @codingame/[email protected]
     ├── @codingame/[email protected]
     ├── monaco-editor@npm:@codingame/[email protected]
     ├── [email protected]
     └── vscode@npm:@codingame/[email protected]

@CGNonofr
Copy link
Collaborator

What about the wrapper package?

@kaisalmen
Copy link
Collaborator

kaisalmen commented Jun 12, 2024

@CGNonofr bundle sizes came down already by the measures you took on the monaco-vscode-api side, but we can't below the dependencies stated above. Using the languageclient or monaco-editor-wrapper comes with a price, but it is pretty small in comparison to a real vscode (vscode.dev takes 46 MB).

@kaisalmen
Copy link
Collaborator

What about the wrapper package?

It also only adds what is needed.

@CGNonofr
Copy link
Collaborator

There are a few more services override though, like the textmate service override, which uses a 450ko wasm

@Lemour-sudo do you have a bundler report? you can use https://www.npmjs.com/package/webpack-bundle-analyzer for webpack or https://www.npmjs.com/package/vite-bundle-visualizer for vite

@kaisalmen
Copy link
Collaborator

kaisalmen commented Jun 12, 2024

Also, build:production of the angular verification example should provide you with useful data on the final bundle size. It makes use of the wrapper. The react component only adds react.

@Lemour-sudo
Copy link
Author

vite-visualizer

The image I have attached shows the bundles that are used when just importing the react component and logging it (this is to isolately check what the react component uses independent of the client).

@kaisalmen
Copy link
Collaborator

@CGNonofr could we make use of the sideEffects property?

@CGNonofr
Copy link
Collaborator

@CGNonofr could we make use of the sideEffects property?

Missed that question 🤔

We were, but since we use almost everything now... It's probably improvable, case by case, but I don't think there is any remaining easy win regarding bundle size

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

3 participants