Support incremental compilation via TS API

[chriskrycho]

As of TypeScript 2.7, the incremental compilation is exported as public API – see PR here. This should enable broccoli-typescript-compiler to work directly with it, enabling much faster (and cleaner) incremental rebuilds.

[chriskrycho]

They're also building some docs around this here.

[rwjblue]

Thoughts @krisselden?

[stefanpenner]

some further details from when i chatted with @DanielRosenwasser a week or two ago: https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API#writing-an-incremental-program-watcher

[chriskrycho]

You may also find our implementation in ember-cli-typescript helpful. We (really: @dfreeman) did a bunch of work to make it integrate nicely into a broccoli pipeline.

[dfreeman]

"Nicely" might be a stretch... 😄

[stefanpenner]

@chriskrycho / @dfreeman awesome, thanks for the tip. Do you guys see these projects converging? If not, please share why.

[dfreeman]

In a perfect world, absolutely—I have zero interest in maintaining our own TS/Broccoli integration when other folks with deeper knowledge of both have built this :)

The primary reason we split off from using broccoli-typescript-compiler was our desire to support a single joint compilation across multiple trees based on things outside of Broccoli's own domain, e.g. compiling an addon under development in combination with its dummy app, perhaps also including other in-repo or linked developing addons. To actually accomplish that, we've cheated and made some fairly sketchy assumptions about project layout rather than using the proper input trees provided by the CLI, but in practice it's worked well for most projects and actually aligns fairly nicely with the way other tooling (e.g. editors) see the world.

Our hope, though, is to be able to stop doing that relatively soon. We've discussed (and I'm hoping to hack together this weekend) using Babel 7's preset-typescript to get out of the business of doing the transpilation ourselves at all. That would (in theory) allow us to drop all the code that manually gathers up the different bits of the project, compiles them, and then re-emits slices of the output into the appropriate places in the Broccoli graph. Instead we could let Babel to strip out all TS-specific syntax and just spin up a noEmit compiler instance, relying on the project's tsconfig.json to include the appropriate files and only concerning ourselves with emitting type errors/build failures via the CLI.

The trick with that approach is that (as far as I know) it's not possible for an addon to fail a rebuild except via an exploding Broccoli plugin, which is what I'm hoping to spend some time thinking about/experimenting with this weekend. If we do go down that path, though, it obviously distances us even further from being able to use something like broccoli-typescript-compiler, since we'd mostly be getting away from interacting (directly) with Broccoli much, if at all.

I'd love input from the folks in this thread, though. Did we completely miss out on a reasonable way to be using broccoli-typescript-compiler in the context of ember-cli across a bunch of disparate trees for the addon stuff? Does the Babel approach seem reasonable, or is that just a further step in a different direction that we should be reconsidering?