Nope. VS Code has the concept of tasks for this exact purpose of parsing compiler output.
I try not to.
Same for any editor really. Hence why I’m trying to find consensus around this idea instead of just saying, “VS Code is doing this for us and anyone who follows what we say will get support” as I feel like that’s throwing our weight around a bit too much.
So I would disagree with that characterization for two reasons. One, VS Code extensions are written in JavaScript, so you can add us to your list. Two, you’re still calling Python to run flake8, pylint, etc., so it isn’t that you have “non-Python callers”, you’re just saying “direct callers of the linters”. You could conceivably call a wrapper command/library like flake8-standardized or something, but you’re still calling Python regardless from a non-Python app probably for a decent chunk of folks.
So running a linter requires three things:
- What linters does the user want to run?
- When does the user want to run the linter(s)?
- How do you run the linter(s)?
- How do you get results from the linter(s)?
For knowing what linter(s) a user wants to be using, typically that’s done via a configuration of some sort for the editor (e.g. for VS Code it’s your settings.json
). The typically problem with that, though, is it can trip up beginners who have simply been told to “use flake8”. It’s also a nicer experience if you can just detect any and all installed linters in a virtual environment and then automatically use them.
As for when to run linters, that doesn’t necessarily plug into when you want to run a compiler. Linters usually run either manually, on every save, or on every edit. Various editors like VS Code thus have specific triggers for running linters which do not overlap with when e.g. compilers run. That also means that linters are expected to feed through a specific system which does not necessarily align with the “just give us a regex and we will automatically handle surfacing errors” system.
Assuming you do know what linter(s) you want to run and when to run them, the next question is how do you do that? Every linter has its own approach to execution. E.g. some may lint all files if you don’t specify an argument while some may require at least .
to start a linting. So even with standardized output you need to know how to execute the linter(s) appropriately.
And then there’s the suggestion of standardizing the output. That’s for obviously reasons, else we wouldn’t be having this conversation.
So to answer my own questions:
- What linters does the user want to run? Use an entry point for automatic discovery.
- When does the user want to run the linter(s)? VS Code takes care of this for me.
- How do you run the linter(s)? Standardized API which the entry point specifies the location of.
- How do you get results from the linter(s)? Standardized API unifies the results.