Breaks all later preprocessors when used in addon code

[ef4]

ember-cli-typescript is not playing nice with other preprocessors.

Specifically, there is only a compiler for the top-level app, so addon code does not go through the normal preprocessor pipeline, and instead it does a weird sideways thing here.

The fallout is that later preprocessors cannot see the output of ember-cli-typescript. So, for example, you cannot use ember-auto-import in a TS file in an addon (it works in an app, because you use the normal preprocessor pipeline in that case).

I understand the goal of having a single compiler for the whole application, but there are better ways to achieve that. ember-auto-import has the same exact need (a single webpack for the whole application, with global visibility into every app or addon that uses ember-auto-import), and avoids this problem by having a protocol for all the copies to discover each other directly and coordinate.

[mike-north]

I've run into this personally, and it makes interoperability with some other parts of the ember ecosystem very difficult or impossible.

We should prioritize fixing this before we do too much more work on "build" related enhancements that might take us further in the wrong direction.

[dfreeman]

This is one of the big drivers in our investigation of using Babel 7's TypeScript support. It would get ember-cli-typescript out of the transpilation process entirely (we'd only be concerned with emitting type errors and registering Babel plugins in our parent), eliminating a ton of fragile code in this addon and making us much better ecosystem citizens.

[jamescdavis]

I also ran into this a couple of months ago and, after poking at it for a while, my conclusion was that Babel 7 was the only reasonable answer.

[chriskrycho]

Should be resolved by our updating to work in the normal Ember CLI way in v2.