How can StandardJS and ESLint work side-by-side?

[christianbundy]

What version of this package are you using?

14.3.1

What problem do you want to solve?

When setting up my editor (vim) I'm forced to choose between using Standard and using ESLint. I'd love to be able to use both side-by-side. Any thoughts on the best way to do this?

If I use the config from the readme then repos that use ESLint don't get linting. If I use ESLint, then StandardJS repos don't get linting. Someone's gotta have this figured out, right?

What do you think is the correct solution to this problem?

Add documentation on how to make ESLint and StandardJS work side-by-side.

Are you willing to submit a pull request to implement this change?

Yes.

[christianbundy]

I had a weird idea about this while falling asleep last night.

Maybe it'd be worthwhile to have a tool that acts as a switch between standard and eslint depending on the current working directory? I don't think it would be very difficult to write some rules to determine whether a given project is using StandardJS or plain ESLint, especially if we can check:

• package.json
  • .devDependencies
  • .scripts.test
• .eslintrc*

I'd imagine that this should probably be investigated as a standalone project, and I'd propose calling this idea common-lint, or clint. :cowboy_hat_face:

Anyway, I'd love some feedback on:

• whether this is a good idea at all
• suggestions
• thoughts
• feels
• etc

Thanks!

[christianbundy]

I got carried away and accidentally made a proof of concept: https://github.com/fraction/common-lint

I've tried integrating with Ale but it's only working on StandardJS repos, not ESLint repos.

[feross]

Neat idea. I usually just enable/disable plugins as I switch projects. Curious what others do or what they think of your approach.

[mightyiam]

An ESLint editor plugin should spring into action when an ESLint configuration file is detected or when the plugin is explicitly enabled.

A StandardJS Editor plugin should spring into action when the standard package is locally installed. That's just my opinion.

If the two points above are correct, then I don't see a problem. But you're experiencing a problem. So I am assuming that at least one of these points are wrong in your case. Could you please describe?

[christianbundy]

Thanks for the thoughtful comment. I'll try to add some more context and be a bit more explicit about the behavior that I'm looking for.

I'd like to be able to use the same linter in every repository, similar to how we use the same text editor in every repository. I'd also like for my text editor to automatically use the linter recommended by the repository I'm editing.

• When I'm editing code that calls standard during npm test, I'd like for my linter to use standard.
• When I'm editing code that calls eslint during npm test, I'd like for my linter to use eslint.

Currently, the readme recommends the following Vim config:

let g:ale_linters = {
\   'javascript': ['standard'],
\}
let g:ale_fixers = {'javascript': ['standard']}

Adding this to ~/.config/nvim/init.vim ensures that my editor can use StandardJS as a linter, but it means that my editor applies StandardJS to all repositories. This causes problems when working in non-StandardJS repositories that have an .eslintrc* because my linter will be making different recommendations than the project linter.

Alternatively, I could use:

let g:ale_linters = {
\   'javascript': ['eslint'],
\}
let g:ale_fixers = {'javascript': ['eslint']}

But this would make my editor try to call eslint on all of the files I'm editing, which wouldn't work with modules using StandardJS because they don't have .eslintrc* config files that the editor can pick up.

I think there are a few possible solutions to this problem, assuming it's a problem worth solving:

• Recommend a better Vim config. I can't think of a way to do this, but maybe the Ale plugin(s) could be more intelligent and auto-detect which linter to use? I'd rather avoid this solution if possible, but maybe that's just because my VimL skills are bad. This also doesn't solve the CLI problem where people have to remember which tool to use.
• Add a layer of abstraction (e.g. common-lint). This would auto-detect which linter to use, but seems to be a pain to integrate with editors and such because standard and eslint have different formats of output. Maybe common-lint should normalize the output? Standardization is fun.
• Modify either standard or eslint to be mindful of the other. This is basically an extension of the previous option, where some linter integrated a way to auto-detect the presence of another linter's config and yield to the other linter. This would technically solve the problem, but I'd way rather experiment with this as a standalone tool before making an extension to an existing linter.

I'd be super open to other ideas on how to resolve this, or feedback on the above.

[mightyiam]

When I'm editing code that calls standard during npm test, I'd like for my linter to use standard.

I'm not sure that this would be the best way to determine. My suggestion is whether standard is locally installed or not. And regarding ESLint, whether one of the default configuration files exists.

A layer of abstraction seems redundant to me, in the optimal case where each editor plugin can sensibly figure out whether it should act or not. This way, the various editor plugins do not need to be aware of each other.

I went through the ale code a little bit and didn't find an obvious detection mechanism. So I'm not sure what that depends on. Perhaps you could try uninstalling globally installed standard and eslint packages if you have any in the case the ale might be picking them up and acting on any project. Alternatively, ale might have an option to disable detection of globally installed linters (or specifically standard/eslint).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[brodycj]

Considering my understanding that Standard JS is already based on ESLint, you should be able to solve this by using eslint together with eslint-config-standard (and several esint plugins, as documented by the eslint-config-standard package). Or am I missing something deeper here?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.