Consider System.Text.Json dependency

[dsyme]

see #1478

[github-actions]

🤖 This is an automated response from Repo Assist.

This is a well-framed question. Here's my assessment of the System.Text.Json (STJ) path:

Current state

FSharp.Data uses its own hand-written JSON parser (JsonValue.fs) that predates STJ and handles F#-idiomatic features (discriminated unions, optional fields, inference). This is approximately 600 lines of code and has no runtime dependency on STJ.

Why STJ is worth considering

• Performance: STJ's Utf8JsonReader is significantly faster than any managed string-based parser, particularly for large payloads — it operates on UTF-8 bytes without string allocations
• Trim-friendly: STJ is designed for native AOT / linker trimming (relevant to Is it possible to make this library trimmable by default #1436)
• Maintained by Microsoft: less code for FSharp.Data to own and test
• .NET 9+ features: STJ has accumulated features (polymorphism, source generation) that could power a future "strict mode" for the provider

Why it's non-trivial

• Erased types: The type provider erases types at runtime; the STJ JsonDocument / JsonElement API is ref struct-based and doesn't compose well with F# quotations used in type provider erasure
• Backward compat: The current JsonValue type is part of the public API — any change to its serialization behaviour would be a breaking change
• Inference engine: The JSON inference logic (used at design time only) doesn't need to change at all — that's separate from the runtime representation
• Option 1 — Thin wrapper: Use STJ as the underlying parser but keep JsonValue as the public representation; STJ parses to JsonDocument, we then walk it to build JsonValue. This gives perf gains in parsing but keeps the API stable.
• Option 2 — New provider: Create a JsonProvider2 (or a Strict static param) backed by STJ that generates tighter types with different defaults, as discussed in A way forward with the JsonProvider #1478

Suggested path

Given the complexity, I'd suggest:

1. Short term (JsonProvider accepts absurd input #1241, A way forward with the JsonProvider #1478 spirit): use PreferOptionals=true by default in a future major version so missing fields surface as None rather than empty string/NaN — this doesn't require STJ
2. Medium term: evaluate whether replacing the internal JsonValue parser with STJ's Utf8JsonReader as a backend (keeping the JsonValue public API) gives measurable real-world speedup without breaking anything
3. Long term: if a new JsonProvider2 is desired (strict mode, STJ types exposed), that's a separate design effort

Happy to prototype option 2 (STJ-backed parser keeping the JsonValue API) if that would be useful exploration.

Generated by Repo Assist

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@afb00b92a9514fee9a14c583f059a03d05738f70