golangci-lint icon indicating copy to clipboard operation
golangci-lint copied to clipboard

megacheck, unused, gosimple had been deprecated in favor of staticcheck

Open lopezator opened this issue 6 years ago • 11 comments

Megacheck, unused and gosimple had been deprecated in favor of staticcheck.

https://github.com/dominikh/go-tools/tree/master/cmd/gosimple
https://github.com/dominikh/go-tools/tree/master/cmd/megacheck
https://github.com/dominikh/go-tools/tree/master/cmd/unused

So I think it makes sense that we remove them in golangci-lint and go through staticcheck implementation to update it and check if we need to add or fix something.

CC/ @jirfag

lopezator avatar Jan 16 '19 10:01 lopezator

Related issues:

https://github.com/golangci/golangci-lint/issues/314 https://github.com/golangci/golangci-lint/issues/355

lopezator avatar Jan 16 '19 10:01 lopezator

@lopezator thank you, I know and I've already updated megacheck code recently to the latest version.

But I decided to not replace gosimple, staticcheck, unused and megacheck by staticcheck because this renaming wasn't backward compatible. Some users enabled only staticcheck in config and don't want gosimple to be enabled in a new release.

Maybe you have ideas how to rename it without breaking configuration of existing users?

jirfag avatar Jan 20 '19 19:01 jirfag

The easy path is to follow semver rules (see point 2) MAJOR version when you make incompatible API changes.

And go for a new major version v2.0.0. That doesn't mean we have to stop new features (or patch fixes) in v1, but it will freeze at one point.

There two different strategies to follow here:

  1. Be as close as posible as the individual check usage, but grouped here (naming, flags, configuration...).
  2. Diverge in some points of add/remove specific things in order to provide backwards compatibility to users, but it's a tricky path to follow as in some point in time we will have to come back, and then, the jump will have to be higher.

Both have it's pros and cons.

Posible middle solutions I can think of are hard to write and maintain:

  1. Go for a version property in the yaml (as docker-compose does):

https://docs.docker.com/compose/compose-file/compose-versioning/

  1. Detect automatically divergences on config on first run (maybe easier, but would require a lot of work also).

lopezator avatar Jan 21 '19 08:01 lopezator

The links for those linters in the enabled by default section are broken.

marctc avatar Jul 26 '19 12:07 marctc

Hello @jirfag any news on this?

What would be the plan on this? just updating staticcheck to latest version?

In that case I think we should add a note that the recommended usage from now is staticcheck and that megacheck, gosimple, unused are deprecated although you keep them also for compatibility reasons.

Related:

https://twitter.com/dominikhonnef/status/1155646606940803072

Would yo accept a PR updating the statickcheck to latest 2019.2.2?

https://github.com/dominikh/go-tools/releases

Thanks.

lopezator avatar Aug 07 '19 07:08 lopezator

An idea to do not break backwards compatibility and do not deprecate older tools might be adding a property to staticcheck config, called, for example:

gte_2019_1: true

This flag (false by default) would enable the possibility to use the new staticcheck (gosimple, megacheck, unused are now called simply staticcheck from this version).

https://staticcheck.io/changes/2019.1

lopezator avatar Aug 13 '19 08:08 lopezator

Now that you are back @jirfag, I am still interested on moving this forward, and could take this.

Just need some feedback on the proposed design.

lopezator avatar Sep 09 '19 15:09 lopezator

Is this issue already solved? It seems like staticcheck is already available. Just double-checking...

glerchundi avatar Sep 09 '20 15:09 glerchundi

staticcheck is up-to-date in golangci-lint, and we update the dependency automatically via dependabot.

The issue is still opened because the merge of the 4 linters is breaking, so it will be done in the next major version (v2).

ldez avatar May 16 '21 17:05 ldez

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Jul 10 '22 18:07 stale[bot]

Hi, is this still going to be taken care of? What is the ETA of v2?

mvrahden avatar Aug 10 '22 12:08 mvrahden