[tsc] Ensure shared TypeScript modules are compiled to be compatible with Node and Webpack

[joshdover]

Summary

This modifies the TypeScript build step order to ensure that any shared code is built to a format that both Node and Webpack can use. I did this by making the browser build complete before the server build so that shared code is built into CommonJS modules.

This "works" with the current modules that are shared since the shared modules will be in CommonJS format (compiled by the serve build) and we're actually only import type information right now across to the client-side code.

I think this solution is fine for the time being, because it is temporary. We plan to move to immutable bundles with no JS or TS compilation happening at all in production builds. Other options before we get to immutable bundles:

• Ship TS source files and the TypeScript compiler with ts-loader to be able to generate ES6 Modules when re-optimizing in production.
• After upgrading to Babel 7 with TS, compile browser babel output to .browser.js and prefer that when importing via Webpack.
• Use a static file system for all of the webpack source files, server files, or both, which would allow us to potentially have separate source files for browser and server use.

From #32567

The core issue here is that for production builds, we build TS code for the server (tsconfig.json) as commonjs modules and for the browser (tsconfig.browser.json) as esmodules. If a module is imported by both the server and client-side builds, then the client-side build wins and the file is outputted as an esmodule, which Node cannot read.

In order to support TS code sharing (or even just type sharing) between server and browser code, we need to be outputting to a format that both Node and Webpack can read. In my testing it seems that outputting to CommonJS modules works for both environments.

[elasticmachine]

Pinging @elastic/kibana-operations

[spalger]

The reason we need to use esm for the browser typescript is so we have esm features like mutable export bindings, but if you find a way around that I'd be happy to have this.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[joshdover]

@spalger That's what I ended up realizing. I've modified this now to make it build browser TS first, and then server TS. This "works" with the current modules that are shared since the shared modules will be in CommonJS format (compiled by the serve build) and we're actually only import type information right now across to the client-side code.

I think this solution is fine for the time being, because it is temporary. We plan to move to immutable bundles with no JS or TS compilation happening at all in production builds. If we wanted to a slightly better intermediate step, we could ship TS source files and the TypeScript compiler with ts-loader to be able to generate ES6 Modules when re-optimizing in production.

[spalger]

Yeah, that sounds reasonable to me. Maybe once we have babel7 we could compile these files to .browser.js or something and have webpack pickup those versions over the .js files, so we would still be able to avoid shipping TypeScript, avoid duplicating the file tree, and be able to avoid problems importing ui code from the server when necessary. Alternatively, we can move forward with a static file system for all of the webpack source files, server files, or both, which would allow us to potentially have separate source files for browser and server use.

[epixa]

LGTM

Can you update the comment before merging with details about the drawback to this that you and @spalger discussed in the PR comments? Right now it just explains why we do it but not what the consequence of this is, even if it is only temporary.