Eliminate total error count #238

Closed
ChrisTorng opened this Issue Feb 9, 2014 · 11 comments

Projects

None yet

5 participants

@ChrisTorng

Bigger js may generate too many errors. Hope to have a limit, even better to have a config.

@am11 am11 referenced this issue in madskristensen/WebEssentials2013 Feb 9, 2014
Merged

Combine JsHint and JSCS rule, hack to stop errors #637

@ChrisTorng ChrisTorng referenced this issue in ChrisTorng/WebEssentials2013 Feb 9, 2014
@ChrisTorng ChrisTorng Combine JsHint and JSCS rule, hack to stop errors
Combine JsHint and JSCS rule and cleanup excludeFiles. Hack to stop <xml
and more than 500 errors. Revert Regex.
da5538a
@jzaefferer
Contributor

Could you provide some more details? What exactly is the problem you'd like to see addressed? What would a limit do, what should the limit configuration look like?

@ChrisTorng ChrisTorng referenced this issue in madskristensen/WebEssentials2013 Feb 26, 2014
Closed

JSHint/JSCS Errors on .min files and others? #603

@ChrisTorng

JSJint has maxerr http://jshint.com/docs/options/#maxerr, just hope to work as it. I think this is a common feature, for any linters... Don't understand what you don't understand?

@jzaefferer
Contributor

maxerr ala jshint seems reasonable. Thanks for the link.

@mikesherov mikesherov added this to the 1.6 milestone Jun 24, 2014
@mikesherov mikesherov removed the cli label Jun 24, 2014
@mikesherov mikesherov modified the milestone: 1.6 Jun 24, 2014
@martinambrus

+1 to this, I ran out of memory on a 2GB Continuous Integration Ubuntu machine while accidentally scanning external libraries (jquery and the such), which kept killing the machine completely

@mikesherov mikesherov modified the milestone: 1.6, 1.7 Aug 29, 2014
@mrjoelkemp
Member

@mikesherov Would this be supported via a cli option or via the config? I'd think the former to avoid complicating config parsing.

@jzaefferer
Contributor

Whatever it is, there should be a default for this to be useful. Jshint has 50.

@mikesherov
Contributor

Default 50, supplied by either config or command line.

@mrjoelkemp mrjoelkemp self-assigned this Sep 28, 2014
@mrjoelkemp
Member

Some thoughts after digging into this:

  1. A lib/errors object could have a clause in add that prevents a new rule from being added if the maxErrors limit is hit. This would help the RAM issue by reducing the number of error objects kept in memory within _errorlist; though, I'm not entirely convinced that's the cause of the memory bloat.
  2. Checker should avoid checking the file against the next rule if the error limit has been hit. This will avoid further, unnecessary processing of the current file.
  3. checkString should (abruptly) return an empty list if the error limit has been hit. This should avoid esprima-parsing files unnecessarily once the limit is hit.

The only problem is that once we're in the execution context of rule.check(file, errors), it's not possible to halt processing without modifying rules. With (1), we can avoid additional errors from being added past the maxErrors limit, but we can't stop rule checking abruptly. Not being able to halt processing is only an issue for a processor-heavy rule checking a large file before hitting the maxErrors limit.

Any objections/thoughts on these points?

@mikesherov
Contributor

Implementing 1 & 2 seems good for now. Let someone complain about 3 before we fix it. Mike Sherov

On Tue, Sep 30, 2014 at 11:17 PM, Joel Kemp notifications@github.com
wrote:

Some thoughts after digging into this:

  1. An Errors object could have a clause in add that prevents a new rule from being added if the maxErrors limit is hit. This would help the RAM issue by reducing the number of error objects kept in memory within _errorlist; though, I'm not entirely convinced that's the cause of the memory bloat.
  2. Checker should avoid checking the file against the next rule if the error limit has been hit. This will avoid further, unnecessary processing of the current file.
  3. checkString should (abruptly) return an empty list if the error limit has been hit. This should avoid esprima-parsing files unnecessarily once the limit is hit.
    The only problem is that once we're in the execution context of rule.check(file, errors), it's not possible to halt processing without modifying rules. With (1), we can avoid additional errors from being added past the maxErrors limit, but we can't stop rule checking abruptly. Not being able to halt processing is only an issue for a processor-heavy rule checking a large file before hitting the maxErrors limit.

Any objections/thoughts on these points?

Reply to this email directly or view it on GitHub:
#238 (comment)

@mikesherov
Contributor

Actually, much simpler: keep a static running tally of errors, and when the max is reached, throw inside errors.add and catch the error outside. This takes care of 1,2,3. Mike Sherov

On Wed, Oct 1, 2014 at 7:12 AM, Mike Sherov mike.sherov@gmail.com wrote:

Implementing 1 & 2 seems good for now. Let someone complain about 3 before we fix it. Mike Sherov
On Tue, Sep 30, 2014 at 11:17 PM, Joel Kemp notifications@github.com
wrote:

Some thoughts after digging into this:

  1. An Errors object could have a clause in add that prevents a new rule from being added if the maxErrors limit is hit. This would help the RAM issue by reducing the number of error objects kept in memory within _errorlist; though, I'm not entirely convinced that's the cause of the memory bloat.
  2. Checker should avoid checking the file against the next rule if the error limit has been hit. This will avoid further, unnecessary processing of the current file.
  3. checkString should (abruptly) return an empty list if the error limit has been hit. This should avoid esprima-parsing files unnecessarily once the limit is hit.
    The only problem is that once we're in the execution context of rule.check(file, errors), it's not possible to halt processing without modifying rules. With (1), we can avoid additional errors from being added past the maxErrors limit, but we can't stop rule checking abruptly. Not being able to halt processing is only an issue for a processor-heavy rule checking a large file before hitting the maxErrors limit.

Any objections/thoughts on these points?

Reply to this email directly or view it on GitHub:
#238 (comment)

@mrjoelkemp
Member

Great idea!
On Oct 1, 2014 7:36 AM, "Mike Sherov" notifications@github.com wrote:

Actually, much simpler: keep a static running tally of errors, and when
the max is reached, throw inside errors.add and catch the error
outside. This takes care of 1,2,3. Mike Sherov

On Wed, Oct 1, 2014 at 7:12 AM, Mike Sherov mike.sherov@gmail.com
wrote:

Implementing 1 & 2 seems good for now. Let someone complain about 3
before we fix it. Mike Sherov
On Tue, Sep 30, 2014 at 11:17 PM, Joel Kemp notifications@github.com
wrote:

Some thoughts after digging into this:

  1. An Errors object could have a clause in add that prevents a new
    rule from being added if the maxErrors limit is hit. This would help the
    RAM issue

    by reducing the number of error objects kept in memory within _errorlist;
    though, I'm not entirely convinced that's the cause of the memory bloat.
  2. Checker should avoid checking the file against the next rule if the
    error limit has been hit. This will avoid further, unnecessary processing
    of the current file.
  3. checkString should (abruptly) return an empty list if the error
    limit has been hit. This should avoid esprima-parsing files unnecessarily
    once the limit is hit.
    The only problem is that once we're in the execution context of
    rule.check(file, errors),
    it's not possible to halt processing without modifying rules. With (1), we
    can avoid additional errors from being added past the maxErrors limit, but
    we can't stop rule checking abruptly. Not being able to halt processing is
    only an issue for a processor-heavy rule checking a large file before
    hitting the maxErrors limit.

Any objections/thoughts on these points?

Reply to this email directly or view it on GitHub:
#238 (comment)


Reply to this email directly or view it on GitHub
#238 (comment).

@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 2, 2014
@mrjoelkemp mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-662
Fixes #238
68fe47e
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 2, 2014
@mrjoelkemp mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
2d57926
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 2, 2014
@mrjoelkemp mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
2ab790f
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 2, 2014
@mrjoelkemp mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
55af334
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 2, 2014
@mrjoelkemp mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
de54830
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 6, 2014
@mrjoelkemp @mrjoelkemp mrjoelkemp + mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
900dc7c
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 6, 2014
@mrjoelkemp @mrjoelkemp mrjoelkemp + mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
ef14073
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 6, 2014
@mrjoelkemp @mrjoelkemp mrjoelkemp + mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
098de85
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 6, 2014
@mrjoelkemp @mrjoelkemp mrjoelkemp + mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
a590786
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 6, 2014
@mrjoelkemp @mrjoelkemp mrjoelkemp + mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
1b2b7a4
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 6, 2014
@mrjoelkemp @mrjoelkemp mrjoelkemp + mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
2483648
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 6, 2014
@mrjoelkemp @mrjoelkemp mrjoelkemp + mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
238f38b
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 7, 2014
@mrjoelkemp mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
c923dd5
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 7, 2014
@mrjoelkemp mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
aa8ba0b
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 7, 2014
@mrjoelkemp mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
6de72ad
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 7, 2014
@mrjoelkemp mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
9b03b19
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 8, 2014
@mrjoelkemp mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
e46328b
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 8, 2014
@mrjoelkemp mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
0d2573c
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 8, 2014
@mrjoelkemp mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
b7e77dc
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 8, 2014
@mrjoelkemp mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
6433230
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 8, 2014
@mrjoelkemp mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
25cf02c
@mrjoelkemp mrjoelkemp added a commit to mrjoelkemp/node-jscs that referenced this issue Oct 8, 2014
@mrjoelkemp @mrjoelkemp mrjoelkemp + mrjoelkemp CLI: Support a maxErrors option to limit the number of reported errors
Closes gh-664
Fixes #238
b56cb22
@mdevils mdevils closed this in bbf85df Oct 10, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment