I have been charged with the task of writing a webpack loader for the CompilerCLI's offline compilation a code generation feature.

Because the compiler-cli was written as a one off 'build step', it implements ts.CompilerHost. This however poses a problem for Lifetime transpilation tools like a webpack loader. If you look at the source code in both ts-loader and awesome-typescript-loader you'll notice that both of these implement ts.LanguageServiceHost. Although these two interfaces overlap, piping a ts.LanguageServiceHost is not a plug-and-play solution: TheLarkInn/awesome-typescript-loader@7b21b13

Proposal

1. Expose any of the functionality required in the compiler-cli (codegen, annotation conversions) so that the those steps can be performed on a per-file basis. Since webpack already handles finding the correct .ts files via loaders any of that boilerplate code that is used thanks to ts.CompilerHost to assist in finding and reading files is obsolete/not needed.
2. Allow any of the currently exposed classes from the compiler-cli (TsickleHost, Codegenerator, ReflectionHost, MetadataHost) to accept and incorporate ts.LanguageServiceHost.