What does Riverpod's riverpod_lint package catch in @riverpod code, and how is it enabled in current Riverpod 3 projects?

## What riverpod_lint is **riverpod_lint** is an optional developer package from the Riverpod repository — version 3.1.9 alongside Riverpod 3.4.3 — that adds Riverpod-specific warnings, quick fixes and refactoring assists to the Dart analyzer. It understands the contract riverpod_generator imposes, so many of its rules are marked as working only for providers written with `@riverpod`. ## How it runs today - Since **riverpod_lint 3.1.0** it is implemented with **analysis_server_plugin**, the analyzer's own plugin mechanism, instead of the older `custom_lint` package. - It is enabled by listing it under a top-level `plugins:` key in `analysis_options.yaml`, with `riverpod_lint:` and a version beneath it. - Once enabled, IDE diagnostics and `dart analyze` in a terminal or CI both report its warnings; no separate command is needed. - 3.1.9 requires Dart 3.13, because the analysis-server protocol it needs ships in that SDK; on older SDKs version solving now fails with a clear error instead of hanging `dart analyze`. The broader shape of `analysis_options.yaml` belongs to the analyzer topic. ## Rules that guard the codegen contract | Rule | Catches | |---|---| | `functional_ref` | a `@riverpod` function whose first positional parameter is not a `Ref` | | `notifier_extends` | a `@riverpod` class that does not extend `_$ClassName` | | `notifier_build` | a `@riverpod` class with no `build` method | | `unsupported_provider_value` | a generated provider returning a `StateNotifier`, `ChangeNotifier` or hand-made notifier without `Raw` | | `avoid_build_context_in_providers` | a `BuildContext` parameter on a provider or notifier method | | `only_use_keep_alive_inside_keep_alive` | a keepAlive provider reading an auto-dispose generated provider | | `provider_dependencies` | a `dependencies` list missing a scoped provider it uses, or listing one it should not | | `riverpod_syntax_error` | an error from the generator reported in the source file, e.g. an abstract notifier | The keepAlive rule's id in the 3.1.9 source is `only_use_keep_alive_inside_keep_alive`, although the README heading calls it `avoid_keep_alive_dependency_inside_auto_dispose`. ## Rules that apply to any Riverpod code - `missing_provider_scope`: `runApp` without a `ProviderScope` at the root. - `provider_parameters`: family arguments without a consistent `==`, such as a new list literal. - `avoid_public_notifier_properties`: public fields or getters on a Notifier, since state should flow through `state`. - `protected_notifier_properties`: one notifier touching another notifier's `state`, `future` or `ref`. - `avoid_ref_inside_state_dispose`: using `ref` inside a `ConsumerState`'s `dispose`. - `async_value_nullable_pattern`: matching `AsyncValue<int?>(:final value?)`, which skips a legitimate `null` value. ## Assists Refactorings include wrapping a widget in a `Consumer` or a `ProviderScope`, converting a widget to `ConsumerWidget` or `ConsumerStatefulWidget`, and **converting a functional `@riverpod` provider to the class variant and back** — handy when a derived value later needs a method that changes it. ## Reading a warning Each diagnostic carries the rule id, so a warning such as `notifier_extends` can be looked up in the package README, where every rule has a good and a bad example. Many rules come with a quick fix: adding the missing `extends _$ClassName` clause, adding a `build` method, adding the `Ref` parameter to a functional provider, or wrapping `runApp`'s argument in a `ProviderScope`. Because the rules run inside normal analysis, a team that already fails CI on analyzer warnings gets riverpod_lint enforcement for free once the plugin is enabled; a team that only treats errors as fatal will see these as warnings and must decide whether to make them blocking. ## Why teams adopt it 1. Mistakes in the generator's input otherwise surface only when the generator runs; the lint shows them in the editor as you type. 2. It encodes design rules — no public notifier fields, no `BuildContext` in providers — that code review would otherwise have to remember. 3. It catches lifetime and scoping mistakes, such as a keepAlive provider over an auto-dispose one or a missing `dependencies` list, that otherwise appear at runtime as memory that is never reclaimed or a `MissingScopeException`.