Roadmap: Revive v2 major release

[alexandear]

This issue tracks the planning, requirements, and progress for the v2 major release of Revive.

Goals

• Introduce breaking changes and improvements that require a major version bump.
• Modernize the codebase and dependencies.
• Improve extensibility for custom rules and formatters.
• Enhance configuration flexibility and documentation.
• Address long-standing issues and feature requests.

Proposed Areas of Focus

Will be updated

Packages loading

• Migrate to goanalysis
• Support Suggested Fixes (--fix) #1000

Rules Set

• Review default enabled rules and update as needed.
• Remove or refactor deprecated or redundant rules.

Extensibility

• Remove lint.Arguments from Rule.Apply feature: rule use-fmt-print #1389 (comment)

CLI API

• Refactor cli.RunRevive to avoid os.Exit #1333

Dependencies

• Enable -set_exit_status by default #1093

Documentation

• Switch to a different site generator. Hugo seems like a significantly better option these days. (This was discussed with @mgechev privately)

Backwards Compatibility

• Document all breaking changes.
• Provide migration guides where possible.

Please comment below with suggestions, requirements, or concerns for Revive v2.

[chavacava]

Some subjects/remarks (not in a particular order) for the v2:

1. No need to keep backward compatibility with golint. Revive born as a drop-in replacement of the deprecated golint but that was +8 years ago.
2. Rule.Apply: indeed, no more need for lint.Arguments but need for a mechanism to initialize rules (Rule.Setup or Rule.Init?) Rule initialization shall configure the rule (by taking lint.Arguments or equivalent) and other things like init structures and the like.
3. Failures: to ease documenting and filtering, each failure shall have an id (a code, à la statickcheck or SonarQube). There are rules that can generate different failures, failure identification shall be independent from the rule that generates it.
4. Failures: define failure categories (see Rationalize failure categories #1254)
5. Retrieval of target files: modernize
6. Type checking: fix how type-check information is calculated and provided to rules. (should rules requiring type checking need to be programmatically identifiable?)
7. Modernize: meanwhile golang.org/x/tools/go/analysis has emerged and stabilized. Revive could use it and leverage already available analysis to allow developing checks that are not currently possible in revive.
8. Configuration: migrate from TOML to YAML to allow more elegant/simple (less hacky) configurations
9. Formatters: allow streameable formatters; i.e. formatters that generate output on-the-fly (by providing them an io.Writer?)
10. Flexibility: allow loading user-defined rules at runtime. This allows users to run their own rules without need of forking revive or creating a new linter based on revivelib. (dynamic rule loading/execution could be implemented with https://pkg.go.dev/plugin or https://github.com/traefik/yaegi)

[ccoVeille]

This also

• Consider replacing hashicorp go-version by std one #1302

[ccoVeille]

revive rules should be configured easily with something like golangci-lint v2 provided

https://golangci-lint.run/usage/configuration/#linters-configuration

enable: all/none/default

With default being the default, avoiding people who enable one linter to disable all the default one

[ccoVeille]

Also, the exported rule should be split I think.

It mixes things about exported comments and real code issues.

Also this should become the default value

say-repetitive-instead-of-stutters

No one understand stutters

[chavacava]

revive rules should be configured easily with something like golangci-lint v2 provided

https://golangci-lint.run/usage/configuration/#linters-configuration

enable: all/none/default
With default being the default, avoiding people who enable one linter to disable all the default one

Currently it's possible to:

1. run all rules (enableAllRules = true) and then potentially disable some
2. run an arbitrary set of rules by config
3. run a default set of rules

The "default set" was originally defined to cover golint rules and make revive ./... the exact replacement for golint ./...

I think:
a. enable all is useful (+ it should be possible to disable some rules, as is currently possible)
b. enable none is annoying (what is the point of running the linter with all its rules disabled?) I don't see the interest/utility.
c. enable default has no more its place if revive v2 will not be a drop in replacement for golint. Defining a default set of rules is too way opinionated thus defaults will satisfy no-body needs.

[ccoVeille]

b. enable none is annoying (what is the point of running the linter with all its rules disabled?) I don't see the interest/utility.

The reply here is biased by the reply in the c point.

c. enable default has no more its place if revive v2 will not be a drop in replacement for golint. Defining a default set of rules is too way opinionated thus defaults will satisfy no-body needs.

People are lazy. They want "something that works."

• Yes, default sets of rule are opinionated.
• people who are unhappy about a default set came and will come to say "this is stupid", but they can configure it.
• the vast majority of people enabling revive in the last two years, have no idea what was golint
• most people are enabling revive via golangci-lint, it's a fact.
• most people are not configuring revive, either directly or via golangci-lint.
• they are lazy, I know it, I'm lazy too (but I know how to configure revive 😅)
• as a result, most rules of revive are not enabled by people.
• the default set of rules could/should be changed (for years)

I feel like v2 is a chance to do that.

It also match the idea you had about categories

• Rationalize failure categories #1254

( a very good candidate for v2 BTW)

So here, I'm not saying I couldn't agree about having no set or presets of rules.
But I feel like it should be discussed as a part of the v2.

Because if you expect lazy people (the vast majority of developer) to take the time to read documentation of each rules, they won't. And so, if they don't see an immediate feedback such as "oh revive helped me to spot errors in my code, great" the adoption will be low.

v2 should be a chance to enable as much rule as possible. The one that seems legitimate. Unless the plan is to enable them all by default.