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

Garris

Why would you ignore warnings? They are there for a reason. – Block

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. – Garris

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? – Sacksen

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. – Garris

Answer 1

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.

Intelligent

Is there a way for python? – Mislay

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 (pylint.pycqa.org/en/latest/user_guide/message-control.html) and read the plugin's docs inside of VS Code. Hope this helps. :) – Intelligent

Answer 2

This works for me -

//nolint:gosec

Silicle

Answer 3

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.

Ishii

Not sure why this doesn't have more upvotes; it's an excellent solution. Note that the reason must be provided... You can get away with //lint:ignore S1001 - but //lint:ignore S1001 won't work. – Disinfect

Thanks! I was looking for: //lint:file-ignore U1000 Ignore all unused code, it's generated Because I wanted to ignore all warnings from Golang is VSCode in test code. – Defence

Answer 4

You can use a module for that:

import warnings
warnings.filterwarnings( 'ignore' )

Andraandrade