Update no-global-jquery rule to account for new modules import

[clcuevas]

This PR updates the no-global-jquery rule to not report the $ module when using the new modules import syntax.

[rwjblue]

Unfortunately, I believe you have stepped in quick sand with this one.

As I reviewed this PR I notice many issues with state management in the preexisting code that we need to address.

• ImportDeclaration -- always clobbers importAliasName (previously emberImportAliasName) even if that import has nothing to do with Ember or jquery modules
• VariableDeclaration -- when an importAliasName (previously emberImportAliasName) is set (which as you can see from above is already in a bad state) we always clobber the destructuredAssignment variable

Some illustrating failing test cases for the above:

• Using any import other than Ember or jquery breaks the rule:

import Ember from 'ember';
import Foo from 'bar';

Ember.$('.lololol');

• Destructuring anything after destructuring jQuery will not fail properly:

import Ember from 'ember';

const { $ } = Ember;
const { eq } = Ember.computed;

• Having a variable declaration for anything other than Ember.$ will not fail properly:

import Ember from 'ember';

const { $ } = Ember;
const wut = 'lolerskates';
$('.whyowhyowhy')

---

Maybe more scenarios, but I think this comment is already really long 😝

@clcuevas - Would you like to help fix these issues?

[clcuevas]

@rwjblue Thanks for looking into this and providing feedback. I'm definitely up for this task. Would you like for me to close this PR and open a new one once I've fixed the above issues/concerns you stated?

[rwjblue]

Totally up to you, I'm happy to iterate with you here or in separate more focused PRs. Whichever seems more comfortable for you...

[clcuevas]

Okay, I'll leave this PR open and see where it goes... 😄

[clcuevas]

@rwjblue I have something that I've labeled "WIP". I wanted to push it up here just so you can have a look and make sure I'm moving in the right direction. I'm still trying to figure out if there is a better way to perform the checks we need to make for this rule. But, this requires that I read a lot of documentation for ESLint and working with the rules, etc.

[rwjblue]

Yes, that’s looking much better! Thanks for working on it!

I think the next major thing to do is add the various test cases I listed above, and confirm the changes here address them (and adjust if not).

[clcuevas]

@rwjblue I think this is ready to go for a review!

[yads]

it would be great to get this merged in since the current default configuration contradicts itself.

[rwjblue]

Sorry for the delay in reviewing!

This is looking really good, and fixes all of the main state management issues I pointed out earlier.

I'm 👍 on landing, @Turbo87 any objections?

[rwjblue]

Thank you again @clcuevas!

[danwenzel]

FYI: It looks like there's one case that's still failing: #187 (comment)