prefer-immutable-provider-arguments

v1.31.0

effort: 3m

starter+

Warns when a Provider's argument does not have a consistent ==.

If you pass a value that doesn’t support stable equality checks, Riverpod can’t know whether the “new” argument is logically the same as the old one. As a result, you can run into subtle issues like:

Unnecessary rebuilds – your widget rebuilds even if nothing meaningful changed.
Lost caching – Riverpod thinks you’re asking for “new” data every time.
Stale data – providers don’t reuse results across identical inputs.

The rule helps you catch this early, pushing you toward safer, more predictable provider usage.

Example

❌ Bad:

// LINT: Avoid passing arguments without consistent '=='.
//  Try passing a primitive, constant or immutable object that overrides '==' and 'hashCode'.
ref.watch(someProvider(SomeClassWithoutEquals()));

// LINT: Avoid passing arguments without consistent '=='.
//  Try passing a primitive, constant or immutable object that overrides '==' and 'hashCode'.
ref.watch(someProvider([42]));

// LINT: Avoid passing arguments without consistent '=='.
//  Try passing a primitive, constant or immutable object that overrides '==' and 'hashCode'.
ref.watch(someProvider(() { ... }));

✅ Good:

ref.watch(someProvider(SomeClassWithEquals()));
ref.watch(someProvider(const SomeClass()));
ref.watch(someProvider(const Object()));
ref.watch(someProvider(const [42]));
ref.watch(someProvider(const {'string': 42}));
ref.watch(someProvider(variable));

Example​

Example