Why disable typecheck is not useful?

[yudidi]

I tried two ways to disable typecheck, on my ubuntu computer:

1. The first way:

linters-settings:
  typecheck:
    enabled: false

2. The second way:

hello@hello:~/ydd_go/lint-test$ golangci-lint run --disable-all -E typecheck

But they both failed, I got follow output on my shell:

hello@hello:~/ydd_go/lint-test$ golangci-lint run --disable-all -E typecheck
main.go:8:11: invalid operation: division by zero (typecheck)
        i := 5 / 0
                 ^
hello@hello:~/ydd_go/lint-test$ 

[ldez]

Hello,

this configuration does nothing because typecheck doesn't have configuration.

typecheck is not a real linter it's just a way to parse/display "compilation" and linters errors (linter reports are not errors).
It cannot be disabled because of that.

https://golangci-lint.run/usage/faq/#why-do-you-have-typecheck-errors

[jokil123]

Thanks for this @0x416e746f6e , I have been trying to find a solution for hours but couldn't find any because it's always "typecheck is not a real linter and cant have false positives" repeated everywhere.

[bombsimon]

I don't know if I should answer because it's just keeping this discussion alive, but I think this is just a way of wording things.

In the sense of how golangci-lint works, typecheck isn't a linter. It doesn't work the same way and doesn't analyze the code the same way at all which means that the statement of typecheck is not a real linter is true.

However, it's not very useful because it doesn't help anyone understand why the reports are there and how to solve them. This has, as you state yourself, been brought up multiple times to the point where #3460 was created because we had to do something about it. To solve that issue, @ldez made an (in my opinion) very good improvement on describing what typecheck actually means, removed it from the list of linters and added a guide to troubleshoot here: https://golangci-lint.run/usage/faq/#why-do-you-have-typecheck-errors

For some reason, this doesn't seem to help people understand and I personally don't know how to explain this further either. The example used in this discussion is like saying "I can't use ls to list files in a directory that doesn't exist". That's a bit weird, the ls command works just fine if you try to target an existing directory but you can't run ls on a directory that doesn't exist - you'll get an error. The same goes for golangci-lint; if you run golangci-lint /path/to/only/one/file.go and that's not the only file in the package, the analysis might fail and golangci-lint will report them as typecheck messages. The thing is, this is exactly the same as running go build /path/to/only/one/file.go that will also fail. For some reason however, I don't see issues in the Go issue tracker to add support to build a program from only one file, instead, people figure out that they need to run golangci-lint /path/to/package.

The only thing that can be improved here is how to explain why it has to be made this way and potentially improve the way it's reported. Before typecheck was introduced this wasn't reported at all and users were generally even more confused about why the linting didn't work because golangci-lint simply didn't run if the code could not be analyzed.

So to summarize, the solution isn't to configure golangci-lint or add support to disable typecheck, the solution is to use golangci-lint as intended and the improvement is to clarify how to do that. I opened #4303 to add a step ensuring that single files are not targeted.

[ikanadev]

I understand that there is no way to disable typecheck and why it produces errors for a single file, it's okay, that's how it work. But, there is a difference between building (go build) and linting, when you build, all the modules are involved, but when you lint, you just want to see the warnings in the file you're working on.

golangci-lint was meant to be used in CI pipelines (I mean it's in the name), but the Integrations section in the docs gives the sensation that it will work with no issues in your code editor/IDE, but that's now true, a simple struct usage from other file in the same package will raise an undefined: SomeStruct (typecheck) error.

Given that context, I don't see a reason to integrate golangci-lint into my code editor, hence I don't see a reason to have a Integrations section at all, after hours diving into issue comments, I fount no fix for that, and again, if it is a software/behavior limitation, it's okay, maybe would be good to give up into the code editor integration, or at least add a big warning in the docs section.

[bombsimon]

I'm not sure I follow, it works very well in any/most IDEs/editors - you will just have to reference more than one file. Me and thousands of others have been using it in IntelliJ (or this), the Go VS Code extension, as a language server in any editors that supports LSPs, vim/neovim (built-in in versions like SpaceVim or LunarVim) etc for years.

The only thing is that the same holds true in this case, you can't configure the way of running golangci-lint in your editor to only target a single file, you must run it at package level. And all the examples I mentioned above supports that.

The lintOnSave option in VS Code is a common term across multiple languages and linters and thus the options to set file has spilled over to Go and golangci-lint even though it may not be useful (remember it still can be). But there are other linters and tools that you can use the same setting for where it might make more sense.

I don't know about other integrations and how they can be configured but if you think having file as an option because it's confusing and that package would work in all cases file does I would recommend filing an issue in the vscode-go repository to improve the documentation or maybe comment on this issue that is related: golang/vscode-go#2110.

[ikanadev]

My setup is neovim + nvim_lspconfig , my first attempt, as the Vim integration shows, was to run it with ALE. There, I faced the undefined errors, and there was no way to fix it. Running it as a language server works perfectly. If you hadn't mentioned it, I wouldn't have been able to find it. Thanks!