refactor: avoid using file name to determine class identity.

[alexlafroscia]

Since a LOT of files changed here, to add the import to all of the test cases that now actually resolve identifiers rather than make an assumption based on its name, I would suggest looking at the commits one-at-a-time to review. The updated tests pass before and after the change to how isEmberCoreModule works. If this is just too much to review at once, I'm happy to break it up.

Todo

• Determine if we want to attempt to resolve Identifier source back to an Ember module across file boundaries (see Add import validation on existing rules #590 (comment))
• Remove use of file name in isDSModel
• Remove helpers that are no longer relevant post-refactor

[bmish]

The commit refactor: remove other unused code doesn't look right, I think that code is still used.

[bmish]

We should move existing import utils to utils/import, likely in a separate PR. I'd like to have a complete and consistent suite of utils with clear APIs available for checking imports.

[alexlafroscia]

Yeah, I'm fighting to get the code coverage back to 99% -- it's currently at 98.87 🙄 let me take another stab at that

I'd be happy to do some more work to organize things and clean up, but this PR is already pretty huge!

[bmish]

We should not push this complexity (checking for extends and parents and such) into each rule. Each rule should be able to make one simple util function call to check if the node is an Ember controller/component/etc, like this:

CallExpression(node) {
  // classic class
  if (ember.isEmberController(context, node)) {
    ...
  }
},

ClassDeclaration(node) {
  // native class
  if (ember.isEmberController(context, node)) {
    ...
  }
},

[alexlafroscia]

I'm not sure I agree -- it seems like we have a specific CallExpression pattern we're looking for, which looks like

Foo.extend()

We have the ability to tell ESLint those details -- why would we want to check every call expression if we don't have to?

[bmish]

To my knowledge, there's no actual difference between using the more-specific selector vs. doing it ourselves: either eslint does the checks or we do the checks. In general, I would agree with you that it's nice to take advantage of using more-specific selectors, but I don't think that's appropriate here, because:

1. Using both the selector matching and util function unnecessarily splits the logic for detecting components/controllers/etc into two separate places instead of consolidating the logic fully inside a single util function (and maybe this util function could even come from a third-party library someday).
2. Using the selector matching duplicates part of the detection logic across countless rules, which increases the chance for typos and inconsistencies between rules.
3. Encapsulating all of the logic in a util function makes it easy to unit test it in its entirety.
4. The rule code is simpler when the detection details are delegated to the util function. We should optimize for simplicity and readability, and make it as easy to write rules as possible (which includes providing extremely simple util function APIs).

[Turbo87]

what about export default Ember.Controller.extend(...)?