Refactor inline config comment processing out of lib/eslint.js
See original GitHub issueI’ve mentioned this in a couple of different issues (#6435, #6190), but I think we should consider moving inline configuration comment processing out of lib/eslint.js. This will make consideration of those other issues a little easier.
The main purpose of this issue (at time of posting) is to lay out a proposal and hopefully get an idea of when it will land on the roadmap. I’m aware that we have other items on the roadmap that may have higher priority. This issue is just so that when we decide we want to do it, we have some concrete notes and discussion that will help. (That said, I’m also interested in implementing if it might make it happen sooner.)
Proposal:
- Create new ReportFilter module which will take responsibility for filtering lint reports (determined by config comments).
- Extract lib/eslint.js’
disableReporting
into a ReportFilter API which would create an unbounded report disable range for each specified rule. (No real change in functionality) - Extract lib/eslint.js’
enableReporting
into a ReportFilter API which would add an end range to the latest-in-file report disable range last created for each specified rule. (No real change in functionality) - Extract lib/eslint.js’
isDisabledByReportingConfig
into a ReportFilter API which would check the rule ID and location against disable ranges for the file and return a boolean. (No real change in functionality) - Add unit tests for the same.
Goal is to try to do this in such a way that we can also track uses of those disable ranges and have the code be transparent and maintainable, while reducing the complexity and responsibilities of lib/eslint.js.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:3
- Comments:10 (10 by maintainers)
Top GitHub Comments
Just leaving a note here that I want to get to this pretty soon (maybe in the second half of August), but that I’m going to try to knock out a few JSCS compat issues first.
It’s somewhere on my to-do list… It might not be as big a deal anymore if we create a Linter class in its own file, so if nothing else I’ll evaluate that PR and see if this might still be needed.
On May 22, 2017 9:20 PM, “Teddy Katz” notifications@github.com wrote: