Standard Support

[hiimbex]

What's the best way to handle multiple kinda of linters? I think since we're now supporting the use of standard for all plugins, this should at least have a standard option.

Whats the best way to accomplish this?

1. Switch this app to standard and remove the current linting functionality
2. Make it an option in your config ie lint: standard
3. Create separate linting apps for different kinds of linting, ie standard-lint, eslint-lint, etc.

I think I like option 2 best, to have a one trick linting app, but I'm open to other ways of accomplishing this. I see a lot of promise in this app, so I'd love to put more time into it :D

cc/ @bkeepers

[bkeepers]

cc @lee-dohm because @AtomLinter and your experience with that community, and @maxbrunsfeld because @tree-sitter

I think since we're now supporting the use of standard for all plugins, this should at least have a standard option.

This app actually already uses standard because I assumed we'd switch to it eventually.t 😁

3. Create separate linting apps for different kinds of linting, ie standard-lint, eslint-lint, etc.

This is actually how the Atom community has solved it with the @AtomLinter org. I looked into ways of just reusing those Atom packages when I started working on this app, but they are very tightly coupled to Atom, and they all have lots of dependencies, which makes turning this into a service rather challenging.

Whats the best way to accomplish this?

Long term, I think the only sane way to do this without a lot of infrastructure and docker containers is to build a linter that is implemented entirely in one language (like JavaScript) that has a standardized way of declaring syntax rules for each language. tree-sitter is an ideal tool to build it with. This would be a huge effort.

[hiimbex]

This app actually already uses standard...

Wow I did like several hours of development on this app, and I definitely knew it used standard given I used the standard docs as a basis for my implementation 😆

Still relevant the idea of supporting other linters lol

[lee-dohm]

3. Create separate linting apps for different kinds of linting, ie standard-lint, eslint-lint, etc.

This is actually how the Atom community has solved it with the @AtomLinter org.

The @AtomLinter org contains a bunch of plugins for the https://atom.io/packages/linter Atom package. It works like this:

1. The main linter package provides an API for plugins to conform to
2. A plugin interfaces with a command-line tool which it runs when instructed, parses the output and returns the information through the API to the main package
3. The main package visualizes the information it gets back from the plugin

What this means though is that each command-line tool has to be configured to run on the machine. This would be very daunting for something that you want to run on Heroku or Now if you want to support more than just JavaScript or Node. Using something like tree-sitter would solve that problem, but all that gives you is the general parsing framework and, over time, parsers for various languages. You would have to create the rules for each yourself.

[bkeepers]

You would have to create the rules for each yourself

And/or adapters for the linter it's emulating (like the yml config for rubocop).

I'm quite interested in this...but I wonder if something like LSP support would be needed for general usage.

[macklinu]

👋 I would love to help figure out how this Probot app can support multiple linters, as I would like to be able to use ESLint for linting a pull request.