For whitelisting, it is not clear to me if any of these properties can be set inside of init or if they must be set on the prototype:

• actions: prototype,
• attributeBindings: prototype,
• classNameBindings: prototype,
• classNames: prototype,
• concatenatedProperties: prototype?
• instrumentDisplay: init possible
• mergedProperties: prototype?
• queryParams: prototype?

Any others that I'm missing @mixonic, @rwjblue?

@mitchlloyd that list seems fine. It just raises that most of those things, like positionalParams, should probably be defined on the class and not on the instance 😢.

I believe only mutable primitives should be flagged invalid by this rule. Immutable values (numbers, strings, etc) can sometimes be better set on init for raw performance, however they don't come with the logical footgun a mutable value brings.

Recently, we got trolled pretty hard by acceptance tests that weren't cleaned up due to someone putting mutable models with timers, observers, etc. onto the prototype. So, I went looking for this rule.

Would love to reopen the dialog on this rule if y'all think it's viable.

Whitelisting seems like a maintenance headache at best and error prone at worst. But, I'm not sure if there's a smarter way to figure out what's acceptable to be on the prototype.

Happy to help if needed.

@justinaray This repo predates eslint-plugin-ember which is now the best spot for Ember-related ESLint rules. You'll find what you're looking for there!

FWIW, I just released eslint-plugin-ember which adds exactly the rule that is proposed here.

This can probably be closed...

Donezo. Thanks @rwjblue!

Thanks @mitchlloyd and @rwjblue!! Much appreciated. Heading over to eslint-plugin-ember.