Suggestion: false positive of `no-invalid-this` rule on event handlers
See original GitHub issueWhat rule do you want to change? no-invalid-this Does this change cause the rule to produce more or fewer warnings? fewer How will the change be implemented? (New option, new default behavior, etc.)? new default behavior Please provide some example code that this change will affect:
'use strict';
process.on('exit', function(){ console.log(this.argv); });
the same with addListener()
What does the rule currently do for this code?
Rule complains on invalid this
What will the rule do after it’s changed?
Rule must consider EventEmitter
interface (on()
and addListener()
methods) and allow this
in event handlers
Are you willing to submit a pull request to implement this change?
I’ve no required knowledge
Issue Analytics
- State:
- Created 5 years ago
- Comments:12 (8 by maintainers)
Top Results From Across the Web
no-invalid-this - Pluggable JavaScript Linter - ESLint
For this inside functions, this rule basically checks whether or not the function containing this keyword is a constructor or a method.
Read more >Detect other items with same class other than with not(this)
1 Answer 1 ... Ok, so your js looks valid. What I would suggest is to put 'e' or 'event' as the parameter...
Read more >Medical Review Officer Manual - SAMHSA
A positive laboratory test result does not automatically identify an employee or job applicant as an illegal drug user, nor does a laboratory...
Read more >XSL Transformations (XSLT) Version 3.0 - W3C
Abstract. This specification defines the syntax and semantics of XSLT 3.0, a language designed primarily for transforming XML documents into ...
Read more >Hooks FAQ - React
We recognize this heuristic isn't perfect and there may be some false positives, but without an ecosystem-wide convention there is just no way...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
it seems a node-specific change. Generally we don’t want to make change for specific libs/runtime, so I’m not sure this could be in the core rule. Personally it might be a good idea to be in a third-party plugin.
Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.
Thanks for contributing to ESLint and we appreciate your understanding.