Errors in .jshintrc fail in a bad way

[EvHaus]

Having incorrect variables in the in the .jshintrc file currently cause errors to be thrown into the Brackets console and the Linting API to fail.

Here is an example .jshintrc that will cause an issue.

{
    "foo": true
}

In this example, the failure occurs due to the incorrect "foo" variable. Brackets will report the error as: "Uncaught TypeError: Cannot read property 'length' of undefined". But looking into it further, the failure actually happens inside JSHint which states: "Bad option: 'foo'." as part of the "messageOb" variable in the extension.

Such errors should be reported back to the user in a friendly way without breaking the Brackets linting API.

Additionally, the "es5" option is also complaining - even though it's a valid JSHint option.

{
    "es5": true
}

The response from JSHint is: ES5 option is now set per default.

I believe that should be handled as a warning and not cause bracket-jshint to break.

[BrandonJF]

+1 on this! When I place a console.log messageOb right after "var messageOb = errors[i];" in camden.jshint/main.js, on output, the first set of logs actually pertain to the parsing errors in my .jshintrc file, not the actual file being linted. Reading this console output I was able to correct the issues in my .jshintrc file, but these should definitely be displayed to the user in a user friendly fashion.

TL;DR;
For those who can't get their custom jshint file working, console.log messageOb and you'll be able to see what the problem is as far as bad options in your file. Hope this helps someone!

Thanks @globexdesigns, your lead really helped me hack Brackets a bit, I was getting frustrated!

[busykai]

Starting sprint 36, these error will be reported in the problem panel. It's been fixed in adobe/brackets#6442