Is it possible to ignore specific warnings with Visual Studio Code's linter?

Question

Our company is thinking about switching from Sublime to Visual Studio Code.

With SublimeLinter it's possible to use ignore_match statements in the preferences file to ignore specific warnings. This lets us hide false positives such as tracking tags in URLs.

I've tried to find an equivalent function in VSC but to no avail. Can anyone tell me if this can be achieved?

Thanks

We'll be using it to develop emails so there are a lot of hacky bits of code and tracking tags flagged as warnings. Hiding these lets us scan more efficiently for errors which need attention. — user9891601, Jun 05 '18 at 11:38
Linters are language-specific (and often provided by third-party tools). You'll probably have to analyse it in a per-case basis. Are you talking about HTML? — Álvaro González, Jun 05 '18 at 17:39
HTML and CSS. User preferences allow some control over linters but only from a very broad level - e.g. hiding all unknown properties. This is along the right lines of what we're trying to accomplish but we'd only want to hide particular properties. — user9891601, Jun 06 '18 at 09:24

score 5 · Answer 1 · answered Oct 31 '18 at 22:04

I think that your linter's configuration is going to be very language specific - this is an answer for Golang, and it's probably going to be very different depending on the language you're using.

Working with Golang in VSCode, you can set the linter that you use. There are several choices, including (as of 2018-10-31) gometalinter. gometalinter provides the --exclude flag that can be used to ignore specific warning text.

For example, my current project has the following warnings from golint:

> golint ./...
internalapi/types.go:39:2: exported const Foo should have comment (or a comment on this block) or be unexported
internalapi/types.go:263:6: exported type Foo should have comment or be unexported
internalprovider/providerprovider.go:489:22: method Foo should be FOO
internalprovider/providerprovider.go:541:22: method Foo should be FOO
internalprovider/providerprovider.go:552:22: method Foo should be FOO
internalprovider/providerprovider_test.go:514:2: var Foo should be FOO
internalprovider/providerprovider_test.go:514:12: var Foo should be FOO
internalprovider/types.go:26:6: exported type Foo should have comment or be unexported
internalprovider/types.go:31:6: exported type Foo should have comment or be unexported
internalprovider/types.go:32:2: struct field Foo should be FOO
internalprovider/types.go:36:2: struct field Foo should be FOO
internalcfg/internalcfg.go:283:1: exported method internalCfg.Cfg should have comment or be unexported
internalsetup/internalsetup.go:47:29: error strings should not be capitalized or end with punctuation or a newline
internalsetup/internalsetup.go:65:29: error strings should not be capitalized or end with punctuation or a newline
internalsetup/internalsetup.go:73:29: error strings should not be capitalized or end with punctuation or a newline
internalsetup/internalsetup.go:249:21: error strings should not be capitalized or end with punctuation or a newline
internalsetup/internalsetup.go:266:21: error strings should not be capitalized or end with punctuation or a newline
internalsetup/internalsetup.go:281:21: error strings should not be capitalized or end with punctuation or a newline
internalutil/internalinput.go:49:1: exported function Foo should have comment or be unexported
internalutil/internalinput.go:54:1: exported function Foo should have comment or be unexported
internalutil/internalinput.go:70:1: exported function Foo should have comment or be unexported
internalutil/types.go:18:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:20:2: exported const Foo should have comment (or a comment on this block) or be unexported
internalutil/types.go:36:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:42:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:47:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:55:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:61:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:65:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:70:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:88:2: const Foo should be FOO
internalutil/types.go:97:2: const Foo should be FOO
cmd/launch_provider_instance.go:31:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:31:2: exported const Foo should have comment (or a comment on this block) or be unexported
cmd/launch_provider_instance.go:32:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:33:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:34:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:35:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:36:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:37:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:38:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:39:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:40:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:241:6: func Foo should be FOO

If I change my VSCode Go Linter settings to be this:

{
    ...
    "go.lintTool": "gometalinter",
    "go.lintFlags": [
        "--disable-all",
        "--enable=golint",
        "--exclude=exported (const|type|method|function) [\\w.]+ should have comment (\\(or a comment on this block\\) )?or be unexported",
        "--exclude=don't use ALL_CAPS in Go names; use CamelCase",
        "--exclude=(func|const|struct field|) \\w+ should be \\w+"
    ]
}

Then all of the warnings I was seeing earlier are squashed. To read more about gometalinter, check out the main GitHub page of the project.

I think that depends on the specific linter that you're using and how that sort of thing is surfaced in VSCode. Check out the message-control page on PyLint's documentation (http://pylint.pycqa.org/en/latest/user_guide/message-control.html) and read the plugin's docs inside of VS Code. Hope this helps. :) — distortedsignal, Jan 22 '20 at 00:10

score 3 · Answer 2 · answered Dec 22 '20 at 06:42

3

This works for me -

//nolint:gosec

answered Dec 22 '20 at 06:42

Kshateesh

571
1
8
21

score 1 · Answer 3 · answered Jul 25 '21 at 15:07

1

You can use a module for that:

import warnings
warnings.filterwarnings( 'ignore' )

answered Jul 25 '21 at 15:07

shahar_m

3,461
5
41
61

Evandro Pomatti · Answer 4 · 2023-04-27T17:41:55.663

0

One way of hiding specific warnings is using linter directives:

//lint:ignore S1001 <your reason here>

S1001 will be the warning code, and the reason should be provided as well.

edited Apr 27 '23 at 17:41

answered Apr 25 '23 at 23:13

Evandro Pomatti

13,341
16
97
165

Is it possible to ignore specific warnings with Visual Studio Code's linter?

4 Answers4

Linked