-
Notifications
You must be signed in to change notification settings - Fork 18
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-es6-methods a bit too strict #12
Comments
I am having the same problem with The following will fail even though we are using the jQuery API and not
I ended up just setting |
I'm seeing the same thing for chained lodash methods eg.
These are false positives. |
This seems like a very difficult thing to detect with ESLint and seems like a type checker like Flow or TypeScript, since it would be hard to analyze the variable to scope to know if you're calling I tried to introduce this rule into a large codebase using jQuery and had to disable it. I'm wondering if there should be an option to ignore certain function names (like |
I'm also experiencing the same issue, and ended up using the same solution that @bzmw recommended. |
Same problem here with jQuery's find method on forms: var form = jQuery('#myForm');
var val = form.find('#myfield').val(); |
Same as above. One thing I started doing, which is far from perfect, is running something like |
While there's no simple and complete solution to this, in the case that brought me here, the ability to exempt specific methods would suffice, and would make a good addition to this plugin. |
#36 (and thus v1.5.0) made this much better, especially if naming jQuery variables with |
I stumbled on https://github.com/nkt/eslint-plugin-es5 about a year ago but it had too many false-positives when used with jQuery. Most of that (nkt/eslint-plugin-es5#12) appears to have been resolved with v1.5.0, specifically nkt/eslint-plugin-es5#36. This won't catch everything but I *think* it shouldn't have many false positives, as long as things like jQuery's `.find` are used on the same line as `$`, whether `jQuery` or as a variable name; we're inconsistent on that front, but it's not a bad idea to encourage it.
I stumbled on https://github.com/nkt/eslint-plugin-es5 about a year ago but it had too many false-positives when used with jQuery. Most of that (nkt/eslint-plugin-es5#12) appears to have been resolved with v1.5.0, specifically nkt/eslint-plugin-es5#36. This won't catch everything but I *think* it shouldn't have many false positives, as long as things like jQuery's `.find` are used on the same line as `$`, whether `jQuery` or as a variable name; we're inconsistent on that front, but it's not a bad idea to encourage it.
I stumbled on https://github.com/nkt/eslint-plugin-es5 about a year ago but it had too many false-positives when used with jQuery. Most of that (nkt/eslint-plugin-es5#12) appears to have been resolved with v1.5.0, specifically nkt/eslint-plugin-es5#36. This won't catch everything but I *think* it shouldn't have many false positives, as long as things like jQuery's `.find` are used on the same line as `$`, whether `jQuery` or as a variable name; we're inconsistent on that front, but it's not a bad idea to encourage it.
#39 adds an ability to skip methods that still don't work correctly. For example, in my project, there are a lot of jQuery variables with names without a $ sign and it could take a long time to fix and check thousands of lines (the previous PR doesn't fix it). |
I stumbled on https://github.com/nkt/eslint-plugin-es5 about a year ago but it had too many false-positives when used with jQuery. Most of that (nkt/eslint-plugin-es5#12) appears to have been resolved with v1.5.0, specifically nkt/eslint-plugin-es5#36. This won't catch everything but I *think* it shouldn't have many false positives, as long as things like jQuery's `.find` are used on the same line as `$`, whether `jQuery` or as a variable name; we're inconsistent on that front, but it's not a bad idea to encourage it.
an innocent file like this:
Will fail eslint with this error:
This is my
.eslintrc
file:In short, I think there's no easy way to tell if
x
(in the example above) is an array or something that really does have.values()
- so I propose that we drop these rules... WDYT?The text was updated successfully, but these errors were encountered: