configurable-file-extensions: Shadowing addon files doesn't always work

[buschtoens]

Cross-posting from #topic-typescript, so it doesn't get lost:

I noticed a peculiar problem with #140. I’m shadowing / clobbering files in the app directory provided by addons. For example, ember-intl re-exports the intl service and t helper in their app directory. I’m shadowing these with my own compatibility layer intl service and t helper. I’m doing the exact same thing to the features service of ember-feature-flags. This used to work reliably with ember-cli-babel 6.

But now it seems that sometimes this shadowing does not work and the addon-provided files “leak through”. I’m also unable to find my override file in the Chrome Dev Tools. Triggering a re-build on the “missing” file by touching it fixes the problem.

Does it maybe have something to do with parallelization?

Concretely what happened is that my t helper was sometimes missing and the ember-intl one leaked through. Same happened to the features service.

One side-note: I’m using my #236 branch to process .ts files.

This might be part of the cause.

[buschtoens]

I have the suspicion that this is actually caused by my overrides having a .ts extension. So this would be related to #236.

I changed the file extension of all override files from .ts to .js. Because of the flaky nature of this bug, we can't really verify with certainty that this fixes it. We're observing it now and so far I have not discovered any builds failing because of this.

I'll get back to you once we have more certainty or another failure.

[buschtoens]

Okay, so I am now 💯 certain, that this is caused by having overrides with a .ts extension, as enabled by #236. Since I made the hotfix of renaming all overrides to .js, I did not experience any flakiness.

As far as I understand the plan with ember-cli-typescript is to move into the direction of using ember-cli-babel to do the compilation, so I guess this is an issue we need to fix?

[dfreeman]

Yep, addons' app trees are merged with (and transpiled alongside) the host's, with the host's files taking precedence when there's a naming conflict. Unfortunately, with multiple possible extensions, two different input paths can now target the same output, and by that point in the process we don't have any way of knowing which file came from which source.

With MU this issue goes away (since there's no longer any merging like that), but in the interim it's likely to be annoying. I could imagine updating broccoli-babel-transpiler to give preference based on the order of the configured extensions, but that seems kind of footgun-y (not to mention tricky with parallelized builds).