Include base/ platform from VS Code and leverage DomScrollableElement

[Tyriar]

This is a work in progress that leverages DomScrollableElement from VS Code instead of our very fragile and hacky Viewport. This is something I've wanted to do for a long time but wasn't sure of how to accomplish it. This gives us a bunch of wins:

• Scroll bars could look exactly the same in VS Code's terminal as everywhere else in the product
• No more DOM-hacks; the Viewport component is one of my least favorite parts to work in as it's so fragile.
• No more user agent-specific scroll bar styles. Chromium seems to have changed recently which I think broke the appearance permanently https://github.com/microsoft/vscode/issues/216521
• All the base/ utils are available in xterm.js (with some exceptions, eg. workers) with seemingly low maintenance overhead.
• We have a lot more control over the scroll bar now.

Performance is mostly on par with what we had previously.

I haven't looked into the resulting bundle yet but my thinking is that this will worth it as this is not the only thing we can leverage (eg. various widgets, helpers, data structures, etc.) and we could also remove some of our own utils that are pulled from VS Code's codebase (like Lifecycle.ts, potentially even InstantiationService). Only the imported files should be included in the bundle, I'm not sure what the tree shaking situation is though. I've optimized the vs/base inclusion for easy tracking of the vscode main branch for when new useful changes come in.

Here's what it looks like atm:

When the overview ruler is enabled a black border now shows up and it's pixel perfect with the scroll bar:

---

TODOs in src/browser/ and src/common/ the code track most remaining items. Here are the high level items:

• [ ] Action TODOs
• [ ] Make sure all options work as expected
• [ ] Sort out CSS variable situation
• [ ] Investigate bundle size difference and its impact on startup time
• [ ] Investigate what's included in the bundle - is tree shaking possible?
• [x] Investigate what files are included in base/, should we be git excluding some parts?
• [ ] Polish the new tsconfig.json
• [ ] Ensure licensing is all good (marked, dompurify, vscode)

@jerch I'm curious on your thoughts on this change

[jerch]

@Tyriar Oh wow this looks promising. But +234,923 −438 changes? Is that for real or does that still need a basic cleanup? I'll def. need some time to go through this :fearful:

[Tyriar]

@jerch I might be able to exclude some of the folders (eg. src/vs/base/**/test/*), one of the main things I wanted to accomplish here was to just copy and paste the entirety of the folder with minimal changes to make it really easy to bring in any upstream changes. I think the only change that is required right now is to commend out the css includes (import 'vs/css!...';). A git submodule is also an option if we wanted to keep the codebase a little more clean at the cost of a little extra overhead in updating it.

To "review" this I wouldn't go through all of base/, but look at:

• All the changes outside of src/vs
• What we import:

  import { DomScrollableElement } from 'vs/base/browser/ui/scrollbar/scrollableElement';
  import type { ScrollableElementChangeOptions } from 'vs/base/browser/ui/scrollbar/scrollableElementOptions';
  import { ScrollbarVisibility, type ScrollEvent } from 'vs/base/common/scrollable';

• What we will likely import like:
  • base/common/event.ts which contains some very handy helpers like Event.any, Event.debounce, Event.accumulate, PauseableEmitter. We could maybe remove common/EventEmitter.ts in favor of this.
  • base/common/lifecycle.ts which has DisposableTracker for detecting leaks, DisposableMap, etc. We could maybe remove common/Lifecycle.ts in favor of this.
  • base/browser/ui containing various widgets that might be useful, eg. sash
  • base/common/async lots of helpers around dealing with async/promises.

[Tyriar]

Removed a bunch of files in the latest, still +82k but a lot of this is code that we would be able to leverage now

[Tyriar]

Old

• Demo (dev mode) 5520KB
• yarn package:
  • xterm.js 285KB
  • xterm.js.map 1138KB
• yarn package-headless:
  • xterm-headless.js 139KB
  • xterm-headless.js.map 619KB

Warnings for yarn package:

WARNING in asset size limit: The following asset(s) exceed the recommended size limit (244 KiB).
This can impact web performance.
Assets: 
  xterm.js (285 KiB)

WARNING in entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (244 KiB). This can impact web performance.
Entrypoints:
  main (285 KiB)
      xterm.js

WARNING in webpack performance recommendations: 
You can limit the size of your bundles by using import() or require.ensure to lazy load some parts of your application.
For more info visit https://webpack.js.org/guides/code-splitting/

New

• Demo (dev mode) 7932KB ⬆️
• yarn package:
  • xterm.js 646KB ⬆️
  • xterm.js.map 2510KB ⬆️
• yarn pakcage-headless:
  • xterm-headless.js 139KB
  • xterm-headless.js.map 619KB

Warnings for yarn package:

WARNING in ./out/base/common/network.js 222:49-56
Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
 @ ./out/base/browser/dom.js
 @ ./out/base/browser/ui/scrollbar/scrollableElement.js
 @ ./out/browser/Viewport.js 17:28-85
 @ ./out/browser/Terminal.js 35:19-46
 @ ./out/browser/public/Terminal.js 5:19-46

WARNING in ./out/base/common/network.js 263:49-56
Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
 @ ./out/base/browser/dom.js
 @ ./out/base/browser/ui/scrollbar/scrollableElement.js
 @ ./out/browser/Viewport.js 17:28-85
 @ ./out/browser/Terminal.js 35:19-46
 @ ./out/browser/public/Terminal.js 5:19-46

WARNING in asset size limit: The following asset(s) exceed the recommended size limit (244 KiB).
This can impact web performance.
Assets: 
  xterm.js (645 KiB)

WARNING in entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (244 KiB). This can impact web performance.
Entrypoints:
  main (645 KiB)
      xterm.js

WARNING in webpack performance recommendations: 
You can limit the size of your bundles by using import() or require.ensure to lazy load some parts of your application.
For more info visit https://webpack.js.org/guides/code-splitting/

[Tyriar]

Looked into esbuild again today as I wasn't happy with the tree shaking in webpack. Looks like it's not good enough to find some important unused parts either, so I'm thinking maybe I need to manually include files which will increase the update from upstream burden but keep the bundle size as low as possible.

[jerch]

@Tyriar Thx for the cleanup, looks much more digestible now :smile_cat:

About webpack and its tree shaking - I am not very deep into this, but it somehow rings a bell. If I remember right, their dead code elimination is heavily based on ESM module boundaries & exports, which by nature wont work well with non ESM-based projects. Not sure though if they fixed that with more recent releases...

[Tyriar]

Yeah I tried switching to ESM and it still doesn't eliminate some particularly troublesome functions like this that are definitely not used, esbuild is the same. I'll do it manually today but keep the update script so it's still relatively easy to pull in changes (run script, then delete a bunch of files and maybe functions until the diff looks good).

[Tyriar]

Continuing on esbuild branch: https://github.com/xtermjs/xterm.js/pull/5077