Ensure auto-import processes the same extensions as ember-cli-babel

[dfreeman]

As of ember-cli-babel@7.17, options['ember-cli-babel'].extensions is no longer the only factor that determines which file extensions will be processed as inputs to Babel. The use of the enableTypeScriptTransform flag or the presence of ember-cli-typescript >= 4.0.0-alpha.1 will trigger it to process .ts files even without explicit extensions configuration.

This PR updates Package to read the configured extensions from the result of ember-cli-babel's buildBabelOptions method rather than directly from user configuration, which accounts for this new behavior. It also adds a sample-typescript4 test package modeled off the sample-typescript2 app.

This should fix #267.

/cc @chriskrycho @jamescdavis

[jamescdavis]

This looks great! Would it be total overkill to also add a test app that sets enableTypeScriptTransform and doesn't have ember-cli-typescript as a dependency at all? Right now, that is kind of redundant, but it's public API and what if something changes about how that affects Babel's build options?

[dfreeman]

I waffled on that. In principle now that auto-import is consuming ember-cli-babel’s computed filterExtensions it shouldn’t matter how they got there, but you’re right that it’s plausible they could diverge. I guess it’s just down to the cost/benefit of the weight of an extra test app vs the additional coverage. @ef4 do you have a preference one way or the other?

[ef4]

Thanks!

[jamescdavis]

@ef4 no pressure, but just curious when this could be released as it's a blocker for ember-cli-typescript v4.

[NullVoxPopuli]

I pulled this down locally and linked and it does indeed work / allows my app to build with ec-ts 4 + TS 3.9.5

:D

yay 🎉

[jamescdavis]

Released in 1.6.0