Filament Json Yaml Editor Laravel Package

Product Decisions This Supports

• Build vs. buy for config authoring. The package covers the full loop — editing (JsonEditor, YamlEditor), parsing (Yaml::parse(), Yaml::decodeToArrays()), and validation (YamlRule, JsonSchemaRule::yaml()) — so "we'll just build a textarea with a lint check" should be treated as the more expensive option, not the cheaper one. The v1.1.0 fixes are exactly the category of edge cases (key order, big integers, 1.0 rendering, quote/comment parsing) that in-house editors accumulate bugs on for quarters.
• Where YAML/JSON config lives. Because validation is server-side and schema-driven, this package supports shipping admin-facing config editing (feature flags, workflow definitions, integration mappings, prompt/policy files) without giving operators raw DB access.
• Security sign-off for user-supplied YAML. The headline item is a DoS fix: an alias bomb combined with a merge key in a flow map could previously exhaust memory, and the expansion guard now also covers the fallback parse paths (Yaml::parse(), Yaml::decodeToArrays(), YamlRule, JsonSchemaRule::yaml()). For any product where YAML is authored by customers or non-engineering admins, this is the item that unblocks a security review.
• Reduced support load as a roadmap input. "A top-level string stored by an array cast is shown as text and saved back as the same string" and "the error line is no longer garbled by $& / $' in the parser message" are both silent-failure-class bugs: the user sees something wrong and files a ticket rather than reporting a defect. Fixing them is worth more than it looks in a changelog.
• Data fidelity as a product guarantee. The Format button only re-indents — big integers, 1.0, duplicate keys, and key order are preserved as written. That makes the editor safe to point at files where byte-level round-trip matters (signed configs, generated manifests, diffs in review).

When to Consider This Package

Adopt when:

• You are on Laravel and need to store and edit structured YAML/JSON configuration, particularly behind an admin panel.
• Untrusted or semi-trusted users author the YAML/JSON — the alias-bomb guard and the JsonSchemaRule behavior of turning unresolvable $refs and malformed schema keywords into validation errors instead of 500s are the deciding features.
• You want schema validation with bounded error output (maxErrors()) rather than an all-or-nothing pass/fail.
• Round-trip fidelity matters — you need the editor to not silently rewrite integers, floats, key order, or duplicate keys.

Look elsewhere or plan around it when:

• You depend on YAML beyond the core schema. js-yaml 5 is now bundled and !!set and other non-core tags are no longer accepted by default. If your users' documents use custom tags, this release changes behavior for them.
• You depend on implicit timestamp typing. YAML timestamps now load as strings, and unquoted date keys (2024-12-25: x) stay strings instead of becoming unix timestamps. Correct, but a behavior change for anything downstream that expected a datetime.
• You need full date-key coverage in flow maps. A date key inside a flow map ({2024-01-01: a}) is still rejected when parsing without PARSE_DATETIME. Known gap — do not promise users otherwise.
• You are not on Laravel, or you need a headless parser only (the editor assets, including the jsdom dev dependency, are dead weight).

How to Pitch It (Stakeholders)

To executives: This release is a security and quality release, not a feature release. It closes a denial-of-service vector in YAML parsing that could be triggered by user-authored configuration, and it extends that protection to every parse path in the package rather than just the main one — meaning the fix cannot be bypassed by calling a fallback API. Alongside it, a set of fixes removes the cases where the editor silently corrupted or misreported what a user typed. No new surfaces to sell, but it materially lowers the risk of shipping config editing to customers and reduces a class of bug reports.

To engineering: Upgrade is low-risk on the PHP side — no API changes to Yaml::parse(), Yaml::decodeToArrays(), YamlRule, or JsonSchemaRule::yaml(), and JsonSchemaRule now degrades to a validation error rather than a 500 on bad schemas or unresolvable $refs. The real risk sits in the bundled JS: js-yaml 4→5 means YAML timestamps deserialize as strings and non-core tags (!!set, etc.) are rejected by default, and unquoted date keys no longer become unix timestamps. Audit any consumer that expects datetimes or custom tags out of stored YAML before rolling this out. The Format button is now genuinely non-destructive, so it is safe to expose to users who previously avoided it.