Add option to disable eslint if not configured/explicitly installed

[cideM]

If I use xo in a javascript project, it will install eslint as a dependency. As a result, ale will correctly identify the eslint executable in my ./node_modules/ folder, and run eslint, even though I don't have any configuration for it. This results in errors from eslint, even though the actual linter I'm using (xo) does not report any errors.

Here are some ideas how one could avoid the above issue.

• Check if eslint is installed explicitly in package.json.
• Check if there is configuration for eslint, either in one of the configuration files or through the eslintConfig key in package.json
• ???

Either of those checks would only be performed if a certain let g: option is set. If whatever check is performed concludes that eslint isn't explicitly installed/configured, it's not used.

I'm aware that I could disable eslint entirely, but I do use it for some projects, so that wouldn't solve my problem. I also checked the current options for the eslint linter but none of them appear to help.

[fabiomcosta]

I've noticed the exact same problem.
The ideal solution might be if eslint gets disabled when xo is available, given if you have xo you don't really want eslint to run.
xo is unfortunately unusable with ale at this point, unless if you disable eslint by explicitly not including eslint on g:ale_linters, but like already mentioned on this issue, some people might use xo on one project and eslint on others, so that's not generally a good setup.

[tim-phillips]

Every time I work on a project using standard, I have to edit my .vimrc to remove eslint from the list of linters, then reload vim, or else I get an error saying ESLint couldn't find a configuration file.

FYI, this has been approved in #940. Somebody so inclined can make a PR.

If you can come up with a sensible implementation with documentation, feel free to create a pull request. -w0rp #940 (comment)

[w0rp]

The main reason this hasn't been done is that it's not easy. Most answers I see involve, "Well, let's just scan this large set of different project files all in the space of a few milliseconds, which require more time than that in I/O time, and use that to determine what to run."

What I suggest for now is using the bufffer-local options to turn some linters on or off. You can use g:ale_pattern_options to set options easily based on paths on your system.

[w0rp]

What I proposed here will help with this type of problem: #2132

When that is all implemented, it will be possible to do a lot more processing of things like project settings in the background. That will mean it will still take longer to get linter results if options for enabling that type of processing are enabled, but the hard work will not block editing in Vim.

[djasnowski]

Hi @w0rp Thanks for this great project.

Quick question. has this been fixed? I still get a eslint config error (type :ALEDetail for more info) error on a project that doesn't have eslint configured. I have tried g:ale_linters_ignroe = {'javascript': ['eslint']} to no avail.

[w0rp]

g:ale_linters_ignroe contains a typo.

I'm going to close this, as I don't think it's a good idea. I don't want ALE to do any detection of projects with asynchronous jobs to determine which linters to run, as the delay will be too long. Instead I suggest configuring your settings for different projects.