As VS Code has grown larger and more featureful, so does the main bundle size that increases the time it takes to load/parse/compile the JS linearly. This isn't an issue for anything not in main bundle (shared proc, exthost, ptyhost, built-in extensions, etc.), but code for features like the terminal, tasks and the welcome page are all loaded in even if they are not used yet.

We have had various discussions about this in the past which I don't think are documented anywhere. Here are some of the things discussed and a brain dump of other thoughts on the topic:

• Moving off AMD (to ESM? Explore AMD to ESM migration #160416) is probably the long term solution to this problem, but it's a large and difficult multi-month project
• We have not yet measured the actual impact of reducing bundle size, the current assumption is that it will reduce this compile block on startup relative to the percentage of code removed from the bundle
  
  The section after will reduce some, but I believe that is the code that is run in the top level which is mostly registering contributions which will need to remain in the main bundle.
• It will be a win if all we're doing is moving non-critical features for the editor to function to LifecyclePhase.Eventually as it will speed up startup
• Code splitting can be achieved manually by using a technique like in tyriar/code_splitting, but that's a lot of overhead put on the component author.
  • This would ideally be all handled for us by the bundler so we can keep the DX of auto importing and not worrying about what code is included in what bundle as it will inevitably cause problems.
  • Importing code could be prevented by lint rules, but there's still the overhead problem.
• It makes sense to target editor and workbench contribs are candidates for code splitting, they also typically have some well defined dependencies (eg. tasks depends on terminal, not the other way)
• xterm.js uses TypeScript projects as a way to make totally separate components of a project even stricter, this is an option we could use if we wanted more strictness around contrib dependencies. Currently this is handled by eslint, to prevent layers going in the wrong direction (common/ cannot depend on browser/) and high level folders (base/ cannot depend on platform/)