Why does linter-eslint use the ESLint CLI executable instead of CLIEngine?

[not-an-aardvark]

Issue Type

Question

Issue Description

This relates to @IanVS's comment at eslint/eslint#7955 (comment):

That said, we are using the cli executable directly (not using CLIEngine).

I'm interested in why linter-eslint does this. Naively, it seems like using CLIEngine to lint files would be more performant than using the executable, because running the executable requires waiting for Node to start up and for all the modules to be loaded. Is there some limitation in the CLIEngine or Atom API that prevents this from being a viable option?

[IanVS]

To be honest, we're not sure. The previous maintainer, @steelbrain, had a reason at the time he refactored the project into its current form, but that was before I joined the project and I can't remember what he told me about why he made that decision.

It has been in our plans to experiment with using CLIEngine, but this far none of us have had a chance to try it out yet. It just hasn't risen to the top of the priority list yet.

[steelbrain]

The reason we had at that time included avoiding complexity. ESLint did not have a nice interface to automatically find config etc. The config for ESLint could be in a lot of places, the configuration file, the manifest key etc. and that's not all, it also does a lot of other things that would've duplicate code to make this package work.

I am not sure of the current state of the ESLint node API but if it automates the things that ESLint does internally now then you can drop CLI engine and it directly without a worry

[tunnckoCore]

It's interesting. So until any refactor, we can introduce one interesting feature that got to my mind - detect if some of the most popular CLI linter tools (xo, standard, etc) is present in deps then use it (or resolve it and use its API) to make the lint and get autofixing.

Because currently, I neither of linter-eslint and linter-js-standard fit well in my flow. If I want autofix and fix on save, I should use linter-eslint, but then I'm forced to use eslint and eslint-config (and related things for some config) to get that. But I don't want to have tons of devDeps and eslintconfig file or field on pkg json.

If I use linter-js-standard i don't get autofix and fix on save features.

So, any ideas? The only thing i can think of is some kind of detection (behind flag/settings option, ofc). Actually, I don't think it would be hard, because when you have such linter, you have the configs installed locally.

[tunnckoCore]

Hm. Interesting, found a workaround which work, but I did't tried it to now.

When you have standard installed, you have the configs and plugins installed locally too. So it is just enough to define an eslint config it would work and you won't have many devDeps. Cool. :)