flutter-state-provider

Migrate per feature, never all at once. Place ProviderScope above MultiProvider at the root so both coexist, convert each ChangeNotifier to a Notifier or AsyncNotifier with immutable state, swap context.watch to ref.watch, then delete the feature's MultiProvider entry and record the migration in a note.

context.watch subscribes the widget and rebuilds it on every notifyListeners call, and is only legal inside build. context.read fetches the instance without subscribing, making it the correct choice inside callbacks like onPressed and initState.

No. Provider 6.x is in maintenance mode with no new features planned, and its author steers new work to Riverpod. New features should use Riverpod or BLoC; Provider should only be maintained where it already exists.

ProviderNotFoundException occurs when the requested provider is not an ancestor of the reading BuildContext. Common causes are reading in the same build method that creates the provider, reading above a Navigator push, or scoping the provider to the wrong route.

Unit-test the notifier as a plain Dart object by adding a listener, calling methods, and asserting state and notification counts. For widget tests, wrap the widget under test in ChangeNotifierProvider.value with a fake instance so the test owns its lifetime.

Keep Provider when the app is near end-of-life with no new features expected, or for read-only legacy screens with no planned changes. Convert a screen only when a change touches it, paying the migration cost as a per-feature tax.