Lint all files in a workspace

[borekb]

Currently, only the opened files are linted. It would be useful to have a command to lint all Markdown files in a workspace.

[DavidAnson]

The way VS Code works, I’m not sure you can report violations against documents that are not open. But I can look into this, thanks!

[DavidAnson]

I don't see a good way to implement this as a VS Code extension with the way things are today. There are two main issues:

1. There's currently no good support for listing all files in a workspace with the configured exclusions (ex: node_modules) applied so unrelated files are ignored. This issue has more detail: Revamp findFiles microsoft/vscode#48674
2. The process of linting and reporting errors is based on the TextDocument interface and the way to get an instance of that is to open the file in the VS Code editor. But we don't want to open (then close?) every Markdown file in a workspace when this command is run because that's very intrusive (and probably slow).

If/when good solutions to the above show up, I'll revisit this issue.

[lxp]

Would it be possible to lint all files for checking if they have any linting error and then only open those files in the VS Code editor that have linting errors?

[DavidAnson]

Yes, but per item 1 above, there is no easy way to know what the project exclusions are. Linting, for example, node_modules would create so much noise that nobody would ever use this feature.

Re-implementing (and maintaining) the logic VS Code uses for this is not something I’d like to sign up for.

[Kissaki]

Related/Similar ESLint ticket for linting all files rather than just open ones, which has some discussion and links that may be helpful microsoft/vscode-eslint#91. It is still unresolved as well.

[koppor]

My workaround is to use the GitHub markdown-linting-action for it:

name: Tests
on: [push, pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - name: Set up Git repository
        uses: actions/checkout@v2
      - name: Lint all files
        uses: avto-dev/markdown-lint@v1
        with:
          args: 'en/'
          config: '.markdownlint.yml'

The .markdownlint.yml is a config as outlined at https://github.com/DavidAnson/vscode-markdownlint#configure. In case the default rules are good enough, one can just omit the file. However, it may make sense to disable the line-length-check (MD013)

[OldStarchy]

ESlint does this by providing a task, and a problem matcher to scan the task output. That way you can view problems in all files, errors persist until you re-run the task.

[DavidAnson]

Thanks, @aNickzz, this looks promising!

[wolf99]

This feature would save me some time!
If I could run markdownlint on the command line I could pass it stuff via xargs.
But CLI usage requires Ruby or Yarn, neither of which I use, nor have installed, nor am familiar with - so its a high barrier to entry for some linting :(

[DavidAnson]

I have this mostly written! There will be no dependency on CLI or an installed runtime.

[wolf99]

This is excellent @DavidAnson, got around to using on a project today and it works like a charm, thank you!
Now investigating adding the markdownlint-cli2-action to a project on GitHub 😃

[OldStarchy]

This is great, the only suggestion I'd add is to include "!**/vendor" by default in "markdownlint.lintWorkspaceGlobs".

[DavidAnson]

@OldStarchy Who uses the vendor pattern? Can you point to some examples? It's easy to add, but I'd like to keep that list to the really common stuff.

[OldStarchy]

Sure, vendor is the default directory used by Composer, a package manager for PHP. It is equivalent to node_modules used by NPM/Yarn. Personally 90% of the projects I work on are in SilverSripe, the other 10% is Craft CMS, both of which use Composer and vendor.

[DavidAnson]

I added a TODO, thanks.