Skip to content
This repository has been archived by the owner on Aug 7, 2023. It is now read-only.

Linter silently fails with config issue #212

Closed
andyburke opened this issue Feb 16, 2016 · 4 comments
Closed

Linter silently fails with config issue #212

andyburke opened this issue Feb 16, 2016 · 4 comments
Labels

Comments

@andyburke
Copy link

The linter is silently failing (showing 'No issues') even when there are issues due to a config issue. The actual error I am seeing inside the debugger is:

[ { file: '...',
    error: 
     { scope: '(main)',
       raw: 'Incompatible values for the \'{a}\' and \'{b}\' linting options.',
       code: 'E059',
       reason: 'Incompatible values for the \'strict\' and \'globalstrict\' linting options. (0% scanned).',
       line: 0,
       character: 0 } } ]

This, however, hits this code path, which ignores the issue:

 for (const entry of parsed.result) {
          if (!entry.error.id) {
            continue
          }

(The error has no id.)

@Arcanemagus
Copy link
Member

Honestly I'm not entirely sure why that check was in there, and the original authors have long since stopped maintaining this. If you want to put together a PR that removes that check, handles these style of messages properly, and has tests that would be amazing!

@luscus
Copy link

luscus commented Mar 14, 2016

+1

@mavaa
Copy link

mavaa commented Apr 25, 2016

Not sure if I am having the same issue. After upgrading to 1.7.2 no javascript files are ever marked with errors, even if I write invalid code on purpose.
The diffrence is, I don't get any errors at all in the debugger..

Am I right in understanding that no one is working on this module any more?

EDIT:
Nope, sorry, pebkac! I have a git repo in my home directory for dotfiles, which ignores almost all sub-folders. And in the main linter-module, I had "Do not lint files ignored by VCS" checked...

Arcanemagus added a commit that referenced this issue May 8, 2017
Remove the check that a entry have an ID. There is a report of where
this was causing issues in #212, and I see no reason why it was there in
the first place.
@Arcanemagus
Copy link
Member

Note: Although I'm removing the check in #390, I can't actually reproduce the original reported reproduction case with the current JSHint.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants