Improved Layering and enabling TS strict

Background

While in Prague, @mofux and I got together to discuss a better architecture for xterm.js that could lead to things like pulling all DOM access away from the core, moving parts of xterm.js into a web worker, and swapping out the frontend completely. Notes from this discussion were captured in https://github.com/xtermjs/xterm.js/issues/1506

Proposal

I propose we split the codebase into distinct parts with very specific roles. This could be done all in the VS Code repo and still result in only a single xterm module being published, while also not obstructing a future where we may want to allow swapping parts out.

Here is the breakdown:

• src/ - Contains all source code as today
  • base/ - Contains interfaces for core and frontend to communicate with each other, as well as code that is used between both of them
  • core/ - This runs in both node.js and browser runtimes. This means far better and easier testing since everything is just node.js without worrying about the DOM
  • ui/ - This code runs only in a browser, anything in xterm.js that interacts with the DOM today will move to here. That includes things like mouse wheel handling (and translating), composition helper, textarea, etc.
  • public/ - This provides an implementation of the current day xterm.js API.

Dependencies between this folders are strictly enforced:

|------------------|
|       base       |
|------------------|
    ↑       ↑    ↑
|------| |----|  |
| core | | ui |  |
|------| |----|  |
    ↑       ↑    |
|------------------|
|      public      |
|------------------|

Notice that ui does not depend on core, any dependencies between core and ui are pulled into interfaces and placed into base.

Example file structure

This tree will give you an idea of what lives where:

src/
  base/
    Types.ts (maybe this should be .d.ts?)
    Clone.ts
  core/
    Types.ts
    Core.ts
    components/
      Buffer.ts
      BufferSet.ts
      Parser.ts
  ui/
    Types.ts
    UserInterface.ts
    components/
      Accessibility.ts
      Composition.ts
  public/
    xterm.d.ts
    Terminal.ts

Composite projects

In TypeScript 3 we will get the ability to build parts of projects independently and depend on them. This would lead to improved build times but also we get the layering enforcement for free as the tsconfig.json for core for example will not contain the dom APIs, so any use of them will fail compilation.

Absolute imports

We may be able to use absolute imports when these changes happen, whenever I try to do it I run into issues with importing a file from the same folder as an absolute import. See https://github.com/xtermjs/xterm.js/issues/1314

Plan

This is quite a large shift from the way things are done now and therefore will take a fair bit of time to execute. Luckily it can be done in parts and many in parallel. It may be best to move to this first:

|------------------|
|       base       |
|------------------|
    ↑            ↑
|------|         |
| core |         |
|------|         |
    ↑            |
|------------------|
|      public      |
|------------------|

And slowly separate core from ui.

[jerch]

@Tyriar Good thinking - lets not over complicate the repo structure. In particular I like the service idea to delegate and structure access to internals (as I really worry that a more direct access to internals that was requested several times will break at hard to track down ends). Also I think we should not put to much effort into solving a problem, thats not yet at hand - webworkers.

[mofux]

That’s perfect, structuring it this way is definitely the way to go IMHO 👍. It also supports the ideas raised in #1515 very well.