[typescript] add typescript support for the server and browser

[spalger]

Part of #18780

This PR enables TypeScript support in both the server and the client. It does not implement tslint, that will come in #19105 .

Here is a summary of how this works:

• distributable
  • does not have any way to run TypeScript
  • all TS transpilation must happen at build time before shipping distributable
• building
  • .ts and .tsx files are converted to .js files in place
  • Full type-check is run while TS is transpiled into .js
  • **/*.ts, **/*.tsx, **/*.d.ts and **/tsconfig.json files are stripped from the build after successful compilation
• plugin helpers
  • plugins with a tsconfig.json file at their root will be transpiled like Kibana is and have TS files stripped while building
• development
  • ts-node added to babel-register to auto-transpile .ts files in the server/jest/mocha
  • ts-loader transpiles .ts and .tsx files in webpack (without checking types)
  • Transpilation in both the server and optimizer is done without type checking, the process runs out of memory really fast otherwise
  • Editor integrations provide type-checking feedback to developers (vscode, atom, vim, webstorm)

To test this out grab a file and convert it to TypeScript. I find constants.js files to be easiest:

• https://github.com/elastic/kibana/blob/master/x-pack/plugins/apm/public/constants/index.js
• https://github.com/elastic/kibana/blob/master/src/core_plugins/kibana/public/context/query/constants.js
• https://github.com/elastic/kibana/blob/master/x-pack/server/lib/constants.js

[elasticmachine]

💚 Build Succeeded

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

[elasticmachine]

💚 Build Succeeded

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

[spalger]

@epixa RE no type checking in dev. This was included in a previous version of the description and I've added it back. Type checking is not supplied by the optimizer or babel-register. Adding type checking here causes things to run out of memory even on very small workloads, so instead editor integrations are leaned on for type checking information. Like you discovered, the build is the final gate and a full type-checking is done there.

[spalger]

@tylersmalley the root server directory in x-pack is not selected by the tsconfig.json file, so the typescript there is not being transpiled. Add server/**/* to

kibana/x-pack/tsconfig.json

Line 4 in bd0f4e1

"plugins/**/*"

and it should work

[spalger]

@epixa #19105 will also be a tool people can use to run typechecking a little more efficiently than rebuilding Kibana or opening every file in their editor.

[tylersmalley]

@spalger, that did the trick.

From the build/kibana/node_modules/x-pack/server/lib directory:

-rw-r--r--  1 tyler  staff    472 May 17 15:47 constants.js
-rw-r--r--  1 tyler  staff  10708 May 15 20:45 esjs_shield_plugin.js
-rw-r--r--  1 tyler  staff    562 May 15 20:45 get_client_shield.js
-rw-r--r--  1 tyler  staff   1642 May 15 20:45 key_case_converter.js
-rw-r--r--  1 tyler  staff    825 May 15 20:45 mirror_plugin_status.js
-rw-r--r--  1 tyler  staff   1313 May 15 20:45 parse_kibana_state.js
-rw-r--r--  1 tyler  staff    513 May 15 20:45 xpack_usage.js

[elasticmachine]

💚 Build Succeeded

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

[epixa]

the root server directory in x-pack is not selected by the tsconfig.json file, so the typescript there is not being transpiled. Add server/**/* to

@spalger Any reason why we wouldn't just do that from the start?

[epixa]

RE no type checking in dev. This was included in a previous version of the description and I've added it back. Type checking is not supplied by the optimizer or babel-register. Adding type checking here causes things to run out of memory even on very small workloads, so instead editor integrations are leaned on for type checking information. Like you discovered, the build is the final gate and a full type-checking is done there.

I think I'm OK with this at least initially. It's not ideal, and maybe this is something we can fix down the line, perhaps with an upgrade of babel and/or webpack. On the fly type checking is certainly useful and expected with statically typed languages, and clearly it's possible since my editor tree is handling it. But let's not block progress for the sake of things we can do down the line.

[elasticmachine]

💚 Build Succeeded

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

[weltenwort]

I gave this a try with a greenfield kibana plugin written in typescript and was able to adapt it such that the following worked:

• run it in --dev mode (optimization time for .ts file change ~8s)
• plugin-helpers build it such that it produces a .zip
• kibana-plugin install that .zip and check that the plugin is loaded correctly

In doing so I stumbled across a few things:

• If the plugin is a mixed js/ts project with allowJs: true in the tsconfig.json, plugin-helpers build breaks, because it would try to recompile the .js files into themselves. Maybe the limitation to ts-only and the risks of customizing the tsconfig.json too much should be pointed out in the docs.
• Since the plugin-helpers by default only copy over a very limit set of files (https://github.com/spalger/kibana/blob/20eb9688a8f3483c3336cb5f1f0cfef2a8565d30/packages/kbn-plugin-helpers/lib/plugin_config.js#L11-L17), the main entry point can not be a index.ts. Maybe the need to override it in the plugin-helpers build arguments in such cases should be documented.
• The fact that the jsx option is set to react for the --dev mode webpack config (https://github.com/spalger/kibana/blob/20eb9688a8f3483c3336cb5f1f0cfef2a8565d30/src/optimize/base_optimizer.js#L284) , but unset in the normal tsconfig.json can lead to errors in IDEs and editors which can not pick that up.

Not tested:

• Typescript in Mocha and Jest

Overall, great progress with a few kinks to iron out 😍

[spalger]

6.x/6.4: 07f4e5a

[sorenlouv]

@spalger Ever since this file was added vscode has been complaining about errors in the workspace:

[ts] No inputs were found in config file '/Users/sqren/elastic/kibana/x-pack/tsconfig.json'. Specified 'include' paths were '["common/**/*","server/**/*","plugins/**/*"]' and 'exclude' paths were '[]'.

Any idea how to fix this?

[spalger]

@sqren this is probably because there aren't actually any ts files in the x-pack project yet.. Maybe you should convert something small in APM to typescript 😄 or we can remove the tsconfig.json file for now.