riverpod_devtools v1.1.2

riverpod_devtools 1.1.2

Patch release: one performance fix and one compatibility fix. No API changes.

• Perf: dart run riverpod_devtools:analyze is dramatically faster on large projects. The CLI resolved every file semantically (AnalysisContextCollection + getResolvedUnit), which re-resolves each file's transitive imports — near "files × whole program" work, taking minutes on provider-heavy apps. But the extraction is purely syntactic (provider patterns, ref.watch/read/listen by name, @riverpod by annotation name) and never used the resolution, so the analyzer now does a plain syntax-only parse per file (parseFile). Cost is proportional to source size only — typically minutes → well under a second — and the generated riverpod_dependencies.json is identical. --watch re-analysis gets the same speedup. (#117)

• Fix: dart run riverpod_devtools:analyze no longer fails to compile on analyzer 14+. ArgumentList.arguments's element type changed from NodeList<Expression> to NodeList<Argument> (a new sealed interface implemented by both Expression and the new NamedArgument; the old NamedExpression was removed) — a genuine breaking type change that can't be bridged with a single static type. The ref.watch/read/listen argument extractor now resolves the argument's expression dynamically instead of relying on either shape, restoring compatibility across the package's full declared analyzer: >=6.0.0 <15.0.0 range. (#118)

Published to pub.dev: https://pub.dev/packages/riverpod_devtools/versions/1.1.2

riverpod_devtools v1.1.1

Patch release: two crash/correctness fixes plus documentation improvements. No API changes.

• Fix: non-finite numbers no longer crash the observer. A provider value containing double.infinity, double.negativeInfinity, or double.nan could throw an uncaught Converting object to an encodable object failed: Infinity from developer.postEvent, because those are valid nums that Dart's json.encode (with no toEncodable fallback) rejects. Both routes that let a non-finite number reach the payload are now sealed: the toJson() sanitizer (_jsonSafe) rewrites non-finite doubles to their string form ("Infinity"/"-Infinity"/"NaN"), and the toString() parser no longer turns num.tryParse('Infinity') into a live non-finite double (it keeps the original string). Finite numbers are unaffected. (#111)

• Fix: dart run riverpod_devtools:analyze now detects @riverpod code-generated providers. The analyzer previously only recognized hand-written final xProvider = SomeProvider(...) top-level declarations. Apps using riverpod_generator (@riverpod functions/classes) got zero matching static metadata for those providers — even though riverpod_dependencies.json loaded successfully, every runtime event for them reported dependenciesSource: 'name_mismatch', since the generated provider variable (in the excluded .g.dart file) never appeared in the analyzer's output. @riverpod/@Riverpod(...)-annotated functions and classes are now recognized in the source file, and named using riverpod_generator's own convention (<lowerCamelCase(name)>Provider), so their static dependencies attach correctly at runtime. (#105)

• Docs: MCP setup for monorepo / subdirectory / FVM Flutter apps. MCP.md now documents the shell-wrapper .mcp.json config needed when the Flutter package (the one depending on riverpod_devtools) lives below the directory .mcp.json is read from — a common monorepo layout — including an FVM example (fvm dart run ...). (#106)

• Docs: MCP connection diagnostics. TROUBLESHOOTING.md's MCP Issues section now leads with a quick diagnostic checklist (debug mode, observer registered, curl .../ping health check with the expected response shape, running from the right package directory, MCP client restarted after .mcp.json changes) so a broken setup can be isolated to app-side vs. MCP-client-side without guesswork. MCP.md now calls out that most MCP clients only read .mcp.json at startup, so tools added mid-session need a client restart/reload. (#107)

Published to pub.dev: https://pub.dev/packages/riverpod_devtools/versions/1.1.1

riverpod_devtools v1.1.0

riverpod_devtools 1.1.0

Reliability and lightness release: bounded serialization cost for large state, faster MCP tool calls, a snappier extension under event bursts, and setup failures that explain themselves instead of degrading silently.

• Serialization is now bounded at the source. serializeValue previously capped only recursion depth; a provider holding a huge List/Map/Set (or an object with a very long toString()) was fully re-serialized on every update, on both the DevTools and MCP paths. Collections now serialize only their first 100 elements — flagged with truncated: true and the true totalItems — and the stored string form is capped at 4000 chars. Anything trimmed carries the existing lossy: true marker, and MCP compact summaries report the true (pre-cap) collection size. Large-state apps can keep the observer enabled without paying an unbounded per-event cost.

• Dependency-JSON load failures are now visible everywhere. A broken riverpod_dependencies.json used to degrade silently to "no dependencies":

  • The registry retains the parse error (RiverpodDevToolsRegistry.loadError).
  • get_dependency_graph returns a dedicated edgesNote with the actual parse error (distinct from "never loaded" and "name mismatch").
  • Events carry dependenciesSource: 'load_error' plus the reason (dependenciesLoadError), and the DevTools extension's Dependencies section shows a "Dependency Data Failed to Load" panel with the error and the fix command — instead of the generic setup instructions.
  • The README / doc-comment setup snippet now logs the load failure reason instead of recommending an empty catch (_) {}.

• MCP: app discovery is cached (~5s). Tool calls that omit port no longer re-ping all 10 ports (1s timeout each) on every call; a failed request to a cached port invalidates the cache so a restarted app on a new port is re-discovered automatically. One HttpClient is used per scan instead of one per port. list_riverpod_apps always scans fresh.

• MCP: get_dependency_graph explains an empty edges — when no static dependency data is loaded (or none of the running providers match it by name), the response carries an edgesNote describing why edges is empty and how to fix it, instead of being indistinguishable from "no dependencies". The note survives the compact view.

• MCP: the server reports its real version in the initialize handshake (was hardcoded to 0.1.0); tool/release.sh keeps it in sync.

• Extension: smoother under event bursts. The event list is rebuilt in a single pass per event (previously a full copy plus a head insert), and the per-provider stats recompute is throttled to at most once per 250ms with a trailing pass so the final state after a burst is never stale.

• Reliability fixes:

  • The ext.riverpod_devtools.command service extension is only marked registered after registration actually succeeds, so a transient failure no longer permanently disables DevTools Invalidate/Refresh for the rest of the isolate's life.
  • The POST /commands invalid-body error message no longer contains a truncated placeholder ("value"?: } → "value"?: <primitive>}), so an AI reading it can self-correct against valid JSON.

• Examples build from a fresh clone — the generated riverpod_dependencies.json is now committed for both example apps, so flutter run works immediately and the dependency-graph demo is live out of the box.

• Docs: TROUBLESHOOTING.md gained an MCP section covering the real failure modes (app not found / port forwarding, first-launch compile timeout, empty graph edges, ambiguous: true, supported: false, multi-app port selection); MCP.md links to it and notes the one-time ~10–20s first-launch compile of the MCP server.

Published to pub.dev: https://pub.dev/packages/riverpod_devtools/versions/1.1.0

riverpod_devtools v1.0.0

riverpod_devtools 1.0.0

First stable release. This milestone makes the bundled MCP server a first-class, token-efficient interface for AI coding tools — reading live provider state and driving it — and rounds out the DevTools extension with an interactive dependency graph and a per-provider performance dashboard. The public API (RiverpodDevToolsObserver, the analyzer CLI, the MCP server) is now stable and follows semantic versioning.

Published to pub.dev: https://pub.dev/packages/riverpod_devtools/versions/1.0.0

MCP: a first-class AI interface

• set_provider_value — set a provider's state to a specific primitive value (int/double/bool/String/null) for providers with a writable notifier (StateProvider, NotifierProvider); unsupported providers are rejected with supported: false. Complements invalidate_provider (reset to build()).
• Token-efficient responses — logs/state/graph/stats are compact by default (a realistic log payload is ~¼ the raw size), with a view parameter (compact/summary/full), since/until windowing on logs, and tool descriptions tightened ~50% (fixed per-session saving).
• Robust provider identity — every provider gets a stable, session-unique instanceId and a nameIsUnique flag, so same-named providers no longer collide; commands accept a name or an exact instanceId and reject ambiguous names with the candidate ids.
• In-band uncertainty — cyclic / depth-truncated serialized values now carry lossy: true, so an AI can tell a placeholder from an accurate reading.
• Health stats over MCP — get_provider_stats (and GET /stats) returns per-provider update rate, async load duration, and dispose→re-create churn.
• Multi-app support — the in-app HTTP server binds the first free port in 8788–8797; list_riverpod_apps reports each running app so tools can target one with port.

DevTools extension

• Interactive dependency graph — layered DAG with watch/read/listen edge styling, status coloring, cycle highlighting, click-to-focus, and pan/zoom.
• Performance Stats tab — per-provider update rate (with sparkline), load duration, and churn, flagging hot/slow providers.
• Invalidate / Refresh from the Provider Details panel (and a service extension so it works on any platform).
• Unified selection across Inspector / Graph / Stats, family-instance grouping, session export/import, and event value diffs, plus a batch of click-reliability and layout fixes.

Compatibility

• Supports Riverpod 2.x and 3.x (CI matrix tests both).
• Requires Dart ^3.7.0 and Flutter >=3.32.0.

Full changelog: https://github.com/yutsuki3/riverpod_devtools/blob/main/packages/riverpod_devtools/CHANGELOG.md
Full diff: v0.6.1...v1.0.0

riverpod_devtools v0.6.1

riverpod_devtools 0.6.1

Published to pub.dev: https://pub.dev/packages/riverpod_devtools/versions/0.6.1

Dependencies

• Widened the analyzer constraint from ^6.0.0 to >=6.0.0 <15.0.0 to cover the current latest analyzer release and improve the pub.dev "Support up-to-date dependencies" score.

Example

• Replaced StateProvider with NotifierProvider/Notifier in the bundled example so it keeps compiling across the full supported flutter_riverpod range (2.3.0–4.0.0), including when resolved to Riverpod 3.x.

Full diff: v0.6.0...v0.6.1

riverpod_devtools v0.6.0

riverpod_devtools 0.6.0

Published to pub.dev: https://pub.dev/packages/riverpod_devtools/versions/0.6.0

MCP Integration

• Added a bundled MCP server (dart run riverpod_devtools:riverpod_devtools_mcp) so AI tools like Claude Code can read live Riverpod provider event logs from a running app. See MCP.md.
• RiverpodDevToolsObserver now starts a local, debug-only HTTP server (localhost:8788) that the MCP server reads from.
• HTTP server start failures are now logged via dart:developer instead of being silently swallowed.

Breaking Changes

• Raised minimum SDKs to Dart ^3.7.0 and Flutter >=3.32.0 to accommodate the MCP server's dart_mcp dependency. If you can't upgrade yet, stay on riverpod_devtools: ^0.5.0.

Other

• Added tool/release.sh to automate version sync across the package, the DevTools extension config, and the extension source package, plus the extension build/copy step.

Full diff: v0.4.4...v0.6.0