Skip to content

Conversation

nathanhammond
Copy link
Collaborator

@nathanhammond nathanhammond commented Sep 13, 2016

ember-browserify currently does a one-level deep check in an attempt to find the host application, making it work in addons which directly descend from the host. This is incomplete. Addons can be nested infinitely deep and we need to recurse up to the host.

This code is extracted from Ember CLI.

Except for the one line added by ember-engines since the host is not always guaranteed to be the top level application. The host may also be the closest lazily-loaded engine.

This code is identical to the check which ember-engines uses to support importing.

Closes #92 and #93.

@asakusuma
Copy link
Collaborator

@nathanhammond I presume this has been tested on past and present versions of ember-cli? I noticed that your new approach is looking for the existence of different properties than before.

@nathanhammond
Copy link
Collaborator Author

app was previously either the addon or the host application. The host application always had an import method. app.app always refers to the parent in a nested addon, so we should directly use the .parent property which was introduced in 0.2.0

Related commit.

@asakusuma asakusuma merged commit 7fd2b39 into ef4:master Sep 13, 2016
@nathanhammond nathanhammond deleted the find-host branch September 13, 2016 17:28
@stefanpenner
Copy link
Collaborator

I don't believe we want this. We need to mangle input names, and be sure we don't collide.

@stefanpenner
Copy link
Collaborator

@nathanhammond spoke about it, and we have come up with a solution. Going to pair on it.

@stefanpenner
Copy link
Collaborator

#100 is our WIP

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cannot read property 'sourcemaps' of undefined
3 participants