[proposal] Enable evolving lints by gating expansions behind language versions

[parlough]

It's always been hard to evolve existing linter rules when wanting to fix false negatives or expand a lint, due to it being potentially breaking by triggering new diagnostics when developers update their SDK. Sometimes this has been deemed acceptable or of minimal impact. In other cases, we've up with new lints that likely are always used together (for example camel_case_extensions as a companion of camel_case_types). Other times, the change is seen as not worth it or remains unimplemented.

However, we already have a way for Dart projects to opt-in to potentially breaking changes, including new diagnostics, through language versioning. This has happened recently for diagnostics with a few changes, such as the language-versioned inference changes potentially triggering new diagnostics. Soon, changes to dart format will also be placed behind language versions, so developers are already becoming familiarized with tooling changing behavior based on language versions.

I propose we open the built-in lints, even core/recommended ones to language-version gated changes. This will help enable us to improve the consistency and quality of the built-in lints. It also helps us combine some similar or duplicative lints, reducing the amount of lints developers need to sort through and understand, as well as reducing the amount of lints to maintain.

There might be slightly more work for developers to move to new language versions, but hopefully many cases can have a dart fix, and the end result will be a better DX every day after that migration.

Rough sketch of decisions when expanding a lint

If modifying a lint to fix a false negative or trigger in new situations, consider and complete the following dependent on the state of the lint:

Internal (to SDK or google3)

1. Implement the change unversioned or versioned, but also make sure to resolve any new diagnostics.

Not yet released to stable:

1. If your change can land before or be cherrypicked into the .0 stable release, implement the change unversioned.
2. If your change can't be included in .0 stable release, treat the lint as released and follow those instructions.

Experimental:

1. If widely used or existing for a long time, consider treating the lint as stable and follow those instructions.
2. If not widely used or clearly experimental, implement the change unversioned, but add a note to pkg/linter/CHANGELOG.md.

Stable lint, released to stable:

1. Discuss with others to verify that modifying the existing lint makes for the best developer experience. Explain why in an issue on the linter repository.

• Consider how many users the lint has and how much code would now trigger the lint.
• Consider if some users of old lint might not want this new behavior.
• Consider if a dart fix can be implemented for some or all of the new cases.
• If a fix is not possible, consider how much migration work might be necessary.
• Consider if the fix could require breaking changes in the libraries of users of the lint.

2. If lint is in package:lints or package:flutter_lints, make sure to include the maintainers of those packages in the previous discussion.
3. Implement the change, gated behind the language version of the next planned minor SDK release (0.X.0).
4. Add a note to pkg/linter/CHANGELOG.md, the root CHANGELOG.md, and add it to the Breaking changes and deprecations doc yourself or inform the website team about the change. If there is no automatic dart fix or the fix is complicated, consider expanding on the necessary changes.

[bwilkerson]

Definitely an interesting idea. I probably wouldn't make it a language version, because that would impact the CFE as well, but a flag that gets flipped just before a stable release is an interesting idea.