Please can you optimize the size of the VSCode extension

[mgholam]

Is your feature request related to a problem? Please describe.
Please can you optimize the on disk size of the VSCode extension (i.e. smaller than 150mb)

Describe the solution you'd like
By possibly pre-building the extension before publishing.

[dummdidumm]

@orta can we do anything about this? I'm not sure how the publish-to-marketplace stuff works and how we could add a bundle/minify step before that.

[orta]

The official recommendations are here: https://code.visualstudio.com/api/working-with-extensions/bundling-extension

Basically it's 'move to webpack'

[dummdidumm]

Tried with a rollup config, but no success.

So far I have:

• One rollup config for the language-server. It builds the package into a single file
• One rollup config for svelte-vscode. It build the extension into a single file
• A deploy script in svelte-vscode which takes care of executing both these rollup builds and then replacing the contents of dist in node_modules/svelte-language-server in svelte-vscode with the built output. Reason: That way the require.resolve(...) in extension.ts will still work
• Added ignore for all node_module content except that of svelte-language-server. Since svelte-language-server/dist contains everything it needs, other modules are not relevant anymore. They still need to be present during deployment though so vsce does not throw errors.

Yes, this all feels very hacky 😄

Problems:

• Inside the language server, there is some dynamic require.resolve stuff. This does not work well with the current rollup config, as, well, those are all bundled now and not found anymore like that. Don't know how to solve this.

[mgholam]

I did this https://github.com/mgholam/svelte-multi-page-app with one rollup.config.js if it helps.

[dummdidumm]

Down to less than 90mb now. Since we do some dynamic requires/depending on node_modules resolution at runtime and that is very tricky in combination with bundling, I will not explore bundling further for now.

[mgholam]

What kind of numbers are we looking at if all goes well (currently at 80mb)?

The biggest folder is "typescript" at 54mb right now.

[dummdidumm]

Honestly I don't know, but with bundling and minification I assume it could go down to less than 10mb.

[mgholam]

Can you give me a starting point, so I can have a crack at this?

[dummdidumm]

Not really I'm afraid. I would try webpack (my attempt with rollup failed) and then try to write a config to bundle the extension (packages/vs-code). Pitfalls are the dynamic require-calls which need to work after bundling.

[mgholam]

How can we keep the require.resolve() calls and just delete the node_modules\typescript folder in the output (50Mb saving)?

[dummdidumm]

You mean we don't bundle and instead just delete typescript from the output? I don't know if this will work, you could try it out yourself.

• bundle the extension locally to vsix (vsce package)
• delete node_modules/typescript from the output (you can just use zip to look into the bundle)
• install the vsix manually as a VSCode extension
• test if everything works

[jasonlyu123]

Just find out vetur actually vscodeignore a lot of files in node_modules/typescript. We probably could also do this since typescript outputs multiple different builds for different purposes. And we didn't use most of them. We can further optimize it to also strip localization files. We also didn't use it now.

Another potential optimization is prettier. Prettier ships both ESM(8.6MB) and CJS. And we only use CJS.

[dummdidumm]

That's a nice idea which is low-effort and can be done directly without introducing a build step (which we may want later, but not right now) - would you like to test this out and create a PR for it?