Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add Addon.prototype.isEnabled for an addon to exclude itself from the project #2271

Merged
merged 1 commit into from
Nov 18, 2014

Conversation

jakecraige
Copy link
Member

closes #2269

addons can exclude themselves by implementing an isEnabled hook where they can access this.app to do whatever checks they want to.

I've also removed the requirement for settings this.app in the included hook. It always does it now.

@@ -187,7 +187,10 @@ Project.prototype.initializeAddons = function() {
var addon = vertex.value;
var AddonConstructor = Addon.lookup(addon);

project.addons.push(new AddonConstructor(project));
var initializedAddon = new AddonConstructor(project);
if(!environment || !initializedAddon.isEnabled || initializedAddon.isEnabled(environment)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

environment being undefined here should not prevent isEnabled from being called.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The addon itself already knows the environment also now that I think about it (from this.app.env since this.app is set in the included hook of the addon).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's been called at this point, get's called here I was thinking it was too, thus I agree with removing the argument if we can switch it up to be like that.

Seems like the addon's might need to be removed after being initialized in EmberApp.prototype._notifyAddonIncluded. That way they can access the full app instance due to included being called. Seems a little dirty though

What do you think?

@jakecraige
Copy link
Member Author

@rwjblue updated based on a few things. Mainly the ordering of hooks being called. Now it works how you'd expect. isEnabled is called prior to included but has the app set on the addon so you can use that for the enabled logic

@jakecraige jakecraige changed the title add Addon.prototype.isEnabled for an addon to exclude itself from the tree add Addon.prototype.isEnabled for an addon to exclude itself from the project Oct 9, 2014
@rwjblue
Copy link
Member

rwjblue commented Oct 9, 2014

We need isEnabled to also work for the other hook types (non-build related) like serverMiddlewares and config.

@jakecraige
Copy link
Member Author

@rwjblue Since those are based on project.addons, would they be filtered out first here? or does it not always go through the EmberApp ?

edit: I'm pretty sure I'm wrong, but I need to ask

@stefanpenner
Copy link
Contributor

@rwjblue your 2 cents would be great.

@jakecraige also tests are red

@rwjblue
Copy link
Member

rwjblue commented Nov 18, 2014

I'm 👍 once the tests pass.

@jakecraige
Copy link
Member Author

@rwjblue All fixed up now

rwjblue added a commit that referenced this pull request Nov 18, 2014
add Addon.prototype.isEnabled for an addon to exclude itself from the project
@rwjblue rwjblue merged commit 888e13b into ember-cli:master Nov 18, 2014
@jakecraige jakecraige deleted the addon-env branch November 18, 2014 20:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Proposal: Addon environment prop for inclusion
3 participants