Proposal: errors option

[mysticatea]

Purpose: There are recoverable errors in syntax error, e.g. duplicate names, invalid escapes in RegExp, and etc. ESLint stops all linting if it encountered those recoverable errors. However, ESLint should be able to work.

Proposal: Adds errors option to espree.

const ast = espree.parse(code, { errors: true })
console.log(ast.errors) //→ Array of recoverable errors.

acorn reports errors by this.raiseRecoverable() method if the error is recoverable. If the errors:true option is given, espree collects recoverable errors into ast.errors property instead of throwing exception.

Then ESLint can report the ast.errors to users.

[not-an-aardvark]

I'm a bit concerned that this would make it more difficult to write rules, because the rules would need to have a reasonable behavior for impossible ASTs. (For example, this could create other issues like eslint/eslint#7712.)

[mysticatea]

Yes, you are right.
Using this errors option will be a breaking change for ESLint. I will make a PR to update core rules if this is accepted.

[platinumazure]

@not-an-aardvark Is that necessarily the case? Could we instead augment parseForESLint to support an AST errors property, and just report errors without linting if errors are present?

[not-an-aardvark]

We could do that. I was under the impression that the goal was to be able to run rules when there are non-fatal errors.

[platinumazure]

You might be right. I was thinking that we could at least report multiple parser errors, when they are "recoverable". We'll have to see what @mysticatea thinks. On Feb 24, 2018 13:11, "Teddy Katz" <[email protected]> wrote: We could do that.I was under the impreaaion that the goal was to be able to run rules when there are non-fatal errors. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#368 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARWerKL6myPvL9tyCrxwnJepA-2pQLwks5tYFDNgaJpZM4SGEvs> .