stick to a single compiler: babel vs tsc

[mshustov]

In #77298 some compilation perf problems have been reported. I'd like to discuss options we have to decrease the compilation pipeline complexity. The main question is whether we need to run 2 different compilers: babel for code generation, tsc for type check and type declaration output, if most of our code is written in TS.
Pros of babel:

• rich plugin system. we can write a custom plugin and use 3rd party plugins. Our babel plugin deps:
  • babel-plugin-styled-components
  • babel-plugin-transform-imports
  • babel-plugin-filter-imports
  • babel-plugin-transform-define
  • babel-plugin-istanbul
• auto-polyfilling with @babel/env

Benefits of tsc:

• type checks during compilation (right now we can see no type errors when yarn start, yarn test:jest --watch)
• faster builds as we don't have to parse source code twice for *.ts files (parse TypeScript code to remove type annotations in the first pass, parse JS code in the second pass, generate source maps)
• faster re-builds (in theory) with incremental mode
• ability to use TS specific features not supported by Babel https://devblogs.microsoft.com/typescript/typescript-and-babel-7/#caveats

Rebuilding the whole build-toolchain is a significant effort, so this issue is rather an attempt to discuss our long term vision on the ideal state of the matter.

For me, it makes sense to investigate tsc usage on the server-side to understand whether we gain a lot switch to it.

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)

[tylersmalley]

The current plan for #69706 is to use tsc, as among other things, having the types outputted allows for optimizations to determine if downstream projects need to be rebuilt.

[kobelb]

I was able to hack a distributable of Kibana to no longer utilize babel-register. Kibana was able to start-up and I was able to use basic functionality. It reduced the JS heap usage by approximately 200mb, so there are likely some benefits that we'd get from removing babel-register in production and locally. There are also some complications here, but it looks promising.

[mshustov]

@kobelb a separate issue created #78168

We discuss the pros and cons on our today's DX meeting and decided on using tsc as a default compiler by default. The main pros: we want to piggyback on TS incremental builds, plus we are going to run tsc to generate type definitions anyway.

[tylersmalley]

With our discovery and plan to address #107648, we have found that we need to use both Babel and tsc, but use tsc sparingly and only when generating types and Babel to quickly transpile code.

@mshustov, can we close this issue?