Filament Json Yaml Editor Laravel Package

Technical Evaluation

Architecture fit. The package occupies a narrow but well-defined seam in a Laravel application: a server-side YAML/JSON parsing façade (Yaml::parse(), Yaml::decodeToArrays()) paired with validation rules (YamlRule, JsonSchemaRule) and front-end editor components (JsonEditor, YamlEditor). That is a sensible layering for config-driven or content-driven Laravel apps where operators edit structured payloads, but it is not core infrastructure — it is a convenience layer that sits in front of js-yaml on the client and a PHP YAML parser on the server. Fit is strong where the product already stores YAML (pipeline definitions, CMS front-matter, deployment manifests, rule sets); it is weak-to-irrelevant for teams storing only JSON in database columns.

Integration feasibility. Low friction. The release is additive and corrective for Laravel consumers: no new service provider, config, or migration surface is implied. The two material behavioural deltas are (a) the bundled js-yaml 4→5 upgrade, which changes how YAML timestamps and non-core tags are loaded, and (b) the Format button now only re-indents rather than normalising values. Both are client-side semantics; PHP-side call sites are unaffected unless they relied on timestamp coercion or !!set/custom tags surviving a round-trip through the editor.

Technical risk. Moderate but bounded, and mostly concentrated in one area: round-trip fidelity across the JS/PHP boundary. Any stored document containing unquoted dates, !!set, duplicate keys, or large integers may now be rendered, formatted, or re-saved differently than before. The mitigation is that the changes skew toward preservation (dates stay strings, big integers and 1.0 survive Format, key order and duplicates kept), which reduces silent data loss but increases the chance that previously "cleaned" documents look unchanged to users who expected normalisation. The security fix — alias-bomb-plus-merge-key no longer exhausting memory, with the expansion guard now extended to the fallback parse path — is the strongest reason to take this release; the guard previously had a bypass on Yaml::parse() and Yaml::decodeToArrays(), which are the primary public entry points.

Secondary risk: JsonSchemaRule with opis/json-schema now caps reported messages at maxErrors() and converts unresolvable $ref / malformed schema keywords from 500s into validation errors. This is a correctness improvement but it changes error payload shape for any UI that assumed a single message or a thrown exception.

Key questions.

• Does any stored YAML in production contain unquoted timestamps or non-core tags that were previously coerced and are now preserved as strings? Who consumes those values downstream?
• Does any consumer depend on Format normalising values (e.g. a diff-based approval flow that expects canonical output)?
• Is the alias-expansion guard now enforced uniformly, and what are the memory/CPU ceilings under adversarial input — should we fuzz before rollout?
• Are the editor components the only surface, or do we expose Yaml::parse() to user-supplied input elsewhere (imports, webhooks, API payloads)?
• What is the package's release cadence and security disclosure history? This is the first assessment, so we have no baseline.

Integration Approach

Stack fit. Requires a Laravel app with a PHP YAML parser on the server and a JS bundler for the editor assets (esbuild 0.28 is a build-time dependency for the package, not for us). The jsdom 30 bump is dev-only and does not enter our runtime. The js-yaml 5 bump is bundled, meaning we inherit it without managing it ourselves — good for maintenance, but it means the parsing semantics change lands on our upgrade, not on a separate dependency review.

Migration path. Treat as a minor-version upgrade with a behavioural changelog, not a drop-in patch. Sequence: pin the current version, inventory stored YAML documents (grep for unquoted ISO dates, !!set, !! custom tags, duplicate keys, large integer literals), then upgrade in a non-production environment and diff the editor's rendered output and save-back results against the inventory. Documents that round-trip identically are safe; those that change need a product decision on whether the new behaviour is acceptable.

Compatibility. No PHP version, Laravel version, or database implications are stated — assume unchanged, but confirm against the package composer.json before scheduling. Front-end compatibility hinges on whether we use the shipped JsonEditor/YamlEditor components or our own editor wired to the package's parser; if the latter, the js-yaml 5 semantics reach us only through our own bundling and the upgrade is a no-op.

Sequencing. (1) Confirm no production data depends on timestamp coercion or non-core tags. (2) Upgrade in staging, run the document inventory diff. (3) Update any UI that surfaces JsonSchemaRule errors to handle multiple messages and the new "validation error, not 500" path. (4) If we have user-facing documentation describing Format as a normaliser, revise it. (5) Ship behind the normal release train; the security fix argues against deferring.

Operational Impact

Maintenance. Low steady-state cost. The package is bundling its own JS dependencies, which centralises upgrade work in the maintainer rather than distributing it across consumers — a net positive, but it also means upstream js-yaml breaking changes arrive as package minor versions. Budget a review each time the bundled js-yaml major moves.

Support. Expect a small volume of "the editor changed my YAML" tickets in the first weeks, specifically around dates no longer becoming timestamps and Format no longer reordering or normalising. Pre-empt with a short internal note and, if the editor is user-facing, a changelog entry. The JsonSchemaRule change may also surface as "I now see multiple validation errors" — a UX improvement that reads as a behaviour change.

Scaling. Parsing is per-request and document-scoped; no new scaling concerns. The security fix is a scaling concern in the positive direction: previously, a crafted alias bomb with a merge key in a flow map could exhaust worker memory, which on a PHP-FPM pool manifests as worker death and 502s under concurrent load. Extending the expansion guard to Yaml::parse(), Yaml::decodeToArrays(), YamlRule, and JsonSchemaRule::yaml() closes that path for every documented entry point. Confirm the guard's limits are configurable or at least documented, and that they are low enough to fail fast rather than after allocating hundreds of MB.

Failure modes. (1) Silent semantic drift — a stored date key now parsed as a string where downstream code expected a timestamp; low blast radius but hard to detect because it does not error. (2) Round-trip divergence — the editor saves back a document that differs textually from what the user submitted; the new behaviour is deliberately conservative, so expect preservation rather than loss. (3) Residual parse gap — a date key inside a flow map ({2024-01-01: a}) is still rejected when parsing without PARSE_DATETIME; this is a known, documented inconsistency and should be logged as an accepted limitation or worked around by enabling PARSE_DATETIME where flow-map dates are expected. (4) Error-shape change — downstream code catching exceptions from JsonSchemaRule must now handle returned validation errors for unresolvable $ref and malformed schema keywords. (5) Cosmetic — the fixed $&/$' mangling in editor error lines removes a real support annoyance; no action needed.

Ramp-up. Minimal for a Laravel developer already familiar with the package: the public PHP API is unchanged, and the new behaviour is concentrated in the editor and in YAML tag/timestamp handling. The one thing worth reading closely is the js-yaml 5 tag policy — anyone authoring YAML with custom tags needs to know those are now rejected by default. Estimate half a day for the inventory diff and staging validation, plus a short documentation pass.