Run linter on all files in a workspace, even the unopened ones

[addisonElliott]

Environment data

• VS Code version: 1.30.1
• Extension version (available under the Extensions sidebar): 2018.12.1
• OS and version: Windows_NT x64 10.0.17134
• Python version (& distribution if applicable, e.g. Anaconda): 3.7 with Anaconda
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda

Feature

Add an option to run linting on entire workspace and populate problems for all files in the workspace. Currently, there is a "Run Linting option" which only works on a file-by-file basis. I propose adding a new option titled something like "Run Linting on Entire Workspace".

Note: Yes, this feature can be done by using the command line to call the script but the command-line arguments and settings in the User Settings can be tedious to copy/paste into the terminal.

[d3r3kk]

Duplicate of #82

[addisonElliott]

@d3r3kk After reading the thread, I see that it was closed due to support being added in Python Language Server. I have that enabled and I am unable to get it to report LS problems in files that I don't have open. Is there something else I need to do?

Additionally, there is still no way to run linters on the entire workspace. That problem was not resolved.

[d3r3kk]

I see, yes in that thread there is discussion about linting all files but it doesn't appear to be resolved. Reopening for discussion with the team.

[addisonElliott]

Thank you!

I'm a bit confused as to what the future plan for python language server is. Is the goal to include linting capabilities in the language server and to enable that by default instead of using pylint?

How do you go about having LS lint all files in the workspace? Is this enabled by default?

[DonJayamanne]

@d3r3kk the original issue was closed so it was decided as not being required.
Closing as a duplicate, and we didn't see any value at that point. Users can always add stars to the original issue

[addisonElliott]

@DonJayamanne I am unable to star the original issue because it is locked.

Can you explain why it is deemed as not being required? The comments of #82, just seem to say that it is already implemented in language server without addressing the other linters.

[DonJayamanne]

Please star this issue.
The reason would most likely have been, it was deemed not required as there was not to much interest in it..

[addisonElliott]

@DonJayamanne I think there is quite a bit of interest in it. As you stated in #82, vscode even has this problem with other languages and being able to lint all files. You saw how many people commented on the original issue. Plus, with the issue being closed then I don't know how many people can find it.

I also think it is an extremely useful feature that could save people time. After I finish working on a PR or some changes for a Python project, I typically want to do a full-project lint of it to see if I missed anything.

This can be done from the command-line but then there are three problems:

1. The results are not put in the problem pane. This means the user cannot click on an issue and be directed to where the linting issue occurs.
2. Command-line arguments for the linters are not saved. The user must copy the command-line arguments to the command-line.
   • In my case, I have a .pylintrc file in Windows that I give as an argument. Each time I run the full project lint, I need to find the additional arguments and include them when typing the command pylint --config <LONG_PATH_HERE>
3. If multiple linters are being used, then the user has to type multiple commands with different arguments typically.

I can understand that the feature may not be top priority for the team. However, I think this issue should still be open and it should have a tag of volunteer.

Note: If this issue is opened and a PR would be accepted for it, I would be interested in submitting one. I've already looked at the code and thought it over. Hoping to get more involved in the community here.

What does everyone else think?

[addisonElliott]

Any comments or points about my above post?

[brettcannon]

Unlocking to see if this gets any upvotes over the next 28 days.

[brettcannon]

@michellequack our integrations are in no way special, so you may want to consider running your linters manually while you wait for us to a make decision about this feature request.

[brettcannon]

One benefit to implementing this is we could execute a linter once and not per-file to save on perf overhead as in #4236.

[valentijnscholten]

It's also very useful to cleanup an old project that has some history of linting errors that you'd like to cleanup. Running the command line flake8 does give me all the errors, but having it run by vscode would give me an easy "point-and-click" to jump to the relevant code to fix it.

[markchagers]

I would definitely love to see this implemented for all languages (well ok, for typescript at least).

[jaraqueffdc]

I would love to see this and I am surprised this was not here. I just assumed I did not know how to run it, I went looking for it and found this open issue. It is a bit of pain to think about opening a PR, go to problems to check whether you have missed some flake8 issue and realised you need to run it from the terminal because VSCode does not have that information :(

[piotrgredowski]

@markchagers, @jaraqueffdc, @valentijnscholten
For now it seems that you have to run a task which will lint every file. I created such task and described it in this post.

[chrissyast]

For now it seems that you have to run a task which will lint every file. I created such task and described it in this post.

@piotrgredowski Would this work for mypy too?

[brettcannon]

@chrissyast it could. You can write a task to launch something like mypyd in the background and write the appropriate problem matcher to parse the output

[piotrgredowski]

@chrissyast exactly like @brettcannon wrote. With correct problem matcher you can do whatever you want with output from any tool.
In my blog post I've added mypy configuration with problem matcher if you'll be interested.

[chrissyast]

@piotrgredowski Many thanks for the updated blogpost :)

[ybonda]

+1 for the feature

[cali-llama]

+1 please!

[AshleyT3]

+1 as well, I added to both thumbs up and rocket-emoji in OP. In the meantime, I'll try out the task def workaround in issue #82.

[ronaldevers]

I'm now using this task for Python to run mypy on an entire project. Gets me highlights in the file explorer tree. I love it! Only downside of course is having to manually run the task.

1. put this snippet in .vscode/tasks.json
2. Run the command Tasks: Run Task
3. Select the new task to run mypy.

Replace --package $YOUR_PACKAGE appropriately for your situation. You can change presentation if you don't want the output to pop up as well.

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Python: lint entire project with mypy",
            "type": "shell",
            "command": "mypy --no-pretty --show-column-numbers --package $YOUR_PACKAGE",
            "group": "test",
            "presentation": {"reveal": "always", "panel": "new"},
            "problemMatcher": {
                "owner": "python",
                "fileLocation": ["relative", "${workspaceFolder}"],
                "pattern": {"regexp": "^(.+):(\\d+):(\\d+): (\\w+): (.*)$", "file": 1, "line": 2, "column": 3, "severity": 4, "message": 5}
            }
        }
    ]
}

[jakemayfield]

+1 for this feature.

[brettcannon]

Please leave a 👍 on the original message to upvote this idea; "+1" comments and the like are a bit noisy for the 18 folks subscribed to this issue and actually don't help with prioritization.

[karthiknadig]

This is supported for mypy via the mypy extension, using the reportingScope setting.

For pylint please track this issue: microsoft/vscode-pylint#79
For flake8 please track this issue: microsoft/vscode-flake8#244

[sshishov]

What is about ruff? The issue is opened on ruff side: astral-sh/ruff-vscode#145

[brettcannon]

What is about ruff? The issue is opened on ruff side: astral-sh/ruff-vscode#145

Ruff is maintained by Astral themselves, so we don't have any control of their support.