Unable to override addon re-exports in the consumer application

[ro0gr]

repo with reproduction. This reproduction is based on a dummy app but it's also reproducible within a host app.

Steps to reproduce:

$ ember g template test
$ ember g template test --dummy

produces following files:

• addon/templates/test.hbs
• app/templates/test.js
• tests/dummy/app/templates/test.hbs
• ...

Now if you run the build it will fail with an EEXIST exception:

ember build
...
EEXIST, file already exists '/home/beatle/workspace/ember-cli-apps/c/tmp/template_compiler-output_path-beowNp4d.tmp/dummy/templates/test.js'
Error: EEXIST, file already exists '/home/beatle/workspace/ember-cli-apps/c/tmp/template_compiler-output_path-beowNp4d.tmp/dummy/templates/test.js'
    at Error (native)
    at Object.fs.symlinkSync (fs.js:848:18)
    at symlink (/home/beatle/workspace/ember-cli-apps/c/node_modules/symlink-or-copy/index.js:82:14)
    at symlinkOrCopySync (/home/beatle/workspace/ember-cli-apps/c/node_modules/symlink-or-copy/index.js:58:5)
    at TemplateCompiler.Filter._handleFile (/home/beatle/workspace/ember-cli-apps/c/node_modules/broccoli-persistent-filter/index.js:101:12)
    at TemplateCompiler.<anonymous> (/home/beatle/workspace/ember-cli-apps/c/node_modules/broccoli-persistent-filter/index.js:88:21)
    at /home/beatle/workspace/ember-cli-apps/c/node_modules/promise-map-series/index.js:11:14
    at lib$rsvp$$internal$$tryCatch (/home/beatle/workspace/ember-cli-apps/c/node_modules/rsvp/dist/rsvp.js:493:16)
    at lib$rsvp$$internal$$invokeCallback (/home/beatle/workspace/ember-cli-apps/c/node_modules/rsvp/dist/rsvp.js:505:17)
    at lib$rsvp$$internal$$publish (/home/beatle/workspace/ember-cli-apps/c/node_modules/rsvp/dist/rsvp.js:476:11)

As I can see after some debugging it happens when broccoli tries to save compiled tests/dummy/app/templates/test.hbs to the tests/dummy/app/templates/test.js where the app/templates/test.js is merged already.

A little bit strange but this error happens only on cold starts and works ok on rebuilds.

[ro0gr]

I've checked if it's reproducible for another kind of files(coffeescript).
The answer is yes. It's the same as for .hbs.

So if you have the following addon:
some-addon/addon/components/test.coffee
some-addon/app/components/test.js

And the consumer application which tries to extend component from addon:
consumer-application/app/components/test.coffee
the build fails with the same EEXIST error.

[locks]

I'm also getting this for the application template in https://github.com/locks/ember-welcome-page.

[stefanpenner]

I believe this was addressed by: stefanpenner/fs-tree-diff@8a8cf15

[ro0gr]

Unfortunately no. I've updated reproduction app to use ember-cli@2.8.0 and have exactly the same error.
Also the latest fs-tree-diff is installed:

npm list fs-tree-diff
b@0.0.0 /home/ro0gr/workspace/tmp-apps/emcli-templates-collision-repro
└─┬ ember-cli@2.8.0
  └── fs-tree-diff@0.5.3 

@stefanpenner could you please reopen?

[ro0gr]

Maybe it's better to add a pr with a failing test here?
I can try to implement it.

[nathanhammond]

@ro0gr:

1. Can confirm that this does throw an error.
2. Inside of the dummy app I don't think we care; just rm tests/dummy/app/templates/test.hbs.

Does this throw an error in a consuming application which is separate from the dummy app?

The mental model here is that an addon is "pushing" something into the app's namespace. It's reasonable for that to error upon collision. I personally prefer that consumers of an addon handle this sort of thing via explicit imports from the addon's namespace which neatly sidesteps the problem and is more similar to our proposed future state.

I'm leaving this closed for now, but in the mean time we will still continue to receive notifications from any followup comments on this issue; being closed doesn't mean that we're ignoring the thread. (Stef closed ~30 on me in one day, so it's taking a while to get through the backlog.)

[ro0gr]

@nathanhammond thanks for your response.
I've got a chance to look at this issue under slightly different angle. Earlier I was under impression that host app sources applied to the tree after all addons sources are merged.

The mental model here is that an addon is "pushing" something into the app's namespace.

now I can see it works in an opposite order.

Does this throw an error in a consuming application which is separate from the dummy app?

Yes. #5336 (comment)
I've used a dummy app example in order to reduce use case(at least I've tried 😅 ).

This issue still makes me think that something is wrong here.
When I build this:

host-app/app/templates/my-template.hbs
charitable-addon/app/templates/my-template.hbs

build finishes successfuly and host-app template wins.

Then when I build this:

host-app/app/templates/my-template.hbs
charitable-addon/addom/templates/my-template.hbs
charitable-addon/app/templates/my-template.js

build fails with an EEXIST exception.

From my point of view here should not be a difference for a build result between these two use cases.

[ro0gr]

updated issue description. Mostly dropped irrelevant blocks of text and mentioned that issue is reproducible for separate app + adddon(not only for dummy app).