-
-
Notifications
You must be signed in to change notification settings - Fork 198
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
no-new-mixins being flagged incorrectly #430
Comments
What's the file path? |
Ohh, is that how you're figuring it out? :(
|
Yeah the detection is based on having |
Ok. I store my mixins in directories like so:
because I have a lot, I group them by the type of thing they are mixed-in to. ...hence my need for this rule. I do not want any more new mixins :) Do you have any suggestions for me other than renaming the directories (which I don't want to do). |
You can disable the rule in |
I suppose I could do that for the time being 🙂 But I'd prefer to keep this issue open so that a better solution is found. (It seems to be a common theme, see here: #235) Cheers |
A number of the ESLint rules we have use the path on the filesystem to determine what type of class is being defined -- maybe that's something worth avoiding? We could pretty easily determine if a new Mixin is being defined by tracking the imported identifier back to the |
I noticed that #213 would help fix this. |
The original logic for determining if a Identifier was of a specific Ember class used the file name to make this decision, rather than resolving the import of the Identifier back to the Ember module it was imported from. This ended up causing a number of issues in lint rule in cases where people places a class in a location that was unexpected based on Ember’s convention. Such issues include ember-cli#601 and ember-cli#430. Making this change avoids the need for something like ember-cli#213, which adds additional logic based on file names to prevent some of these issues. Closes ember-cli#590
The original logic for determining if a Identifier was of a specific Ember class used the file name to make this decision, rather than resolving the import of the Identifier back to the Ember module it was imported from. This ended up causing a number of issues in lint rule in cases where people places a class in a location that was unexpected based on Ember’s convention. Such issues include ember-cli#601 and ember-cli#430. Making this change avoids the need for something like ember-cli#213, which adds additional logic based on file names to prevent some of these issues. Closes ember-cli#590
...I tried to write a failing test, but the above code passed :/
The text was updated successfully, but these errors were encountered: