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