Filament Code Field Laravel Package

Product Decisions This Supports

• Build vs. buy for "editable code" surfaces. Any roadmap item that asks an admin to edit JSON config, a webhook/email template, an HTML snippet, a JS tag, an XML feed mapping, or a saved SQL query needs a code editor. Building that means owning a CodeMirror integration, asset pipeline, dark-mode handling, and RTL fixes. This package collapses that to one composer require and one line in a form schema — a clear buy, because the differentiated value in these features is the workflow around the code (validation, versioning, audit, preview), not the widget itself.
• Feature scoping and estimation. It de-risks the editor portion of a ticket to near-zero, which lets you commit to these features with confidence and redirect engineering time to the parts that actually carry product risk: server-side validation, error messaging, and change history. Plan those as separate, separately-estimated line items — the package provides syntax highlighting only, never correctness.
• Defining the "invalid code" product policy. Because the field does not validate, lint, or execute anything, adopting it forces an explicit decision: can a user save malformed JSON, a PHP snippet that won't parse, or a SQL query that errors? That decision drives validation UX, save-time blocking vs. warning, and whether you need a "test/preview" affordance. Better to make it deliberately than discover it in production.
• Role and permission design. Read-only mode (disabled()) supports view-only admin surfaces for support, ops, or auditor roles who must see configuration without changing it. That's a permissions decision this package makes cheap to implement.
• Language coverage commitments. Default is JSON; PHP, HTML, XML, and JS are documented. SQL appears in the changelog (1.0.2) but not the README's supported list — do not promise SQL in a spec or a customer conversation until it's proven on the version you pin.
• Explicit non-goals. It does not support customer-facing editors, diff/merge views, linting, execution, or infolist-style read-only viewers as a first-class surface. Confirming this early prevents scope creep into "we'll just extend it."

When to Consider This Package

Consider it when all of the following hold:

• The screen lives in a Filament 3 panel and the payload is a modest blob of structured text edited by internal admins.
• Your stack maps cleanly to a package major — ^3.0 for Filament 3 on Laravel 11, ^2.0 for Filament 3 on Laravel 10–12, ^1.0 for Filament 2 — and someone has checked this against the actual composer.json before the spike. The version matrix is inverted relative to convention; taking the newest tag on Laravel 12 is the most likely failure mode.
• You'll cap code fields at two or three per screen (each mounts an independent editor instance).
• The team accepts a thin internal wrapper subclass so reverting to a plain Textarea is a one-file change, and accepts owning validation rules.
• The surface is internal admin tooling. With 57 stars, zero dependents, and a single principal maintainer, there is no ecosystem safety net — that's acceptable here, not in a revenue-critical or customer-facing path.

Look elsewhere when: you need vendor support or an SLA, you're on Filament 2 and unwilling to pin an old major, a Filament major upgrade is imminent and you can't absorb third-party release lag, you need diffing/linting/execution, you need a read-only viewer inside an infolist, you need more than a few editors on one screen, or any customer-facing path would render it. Also treat the Dependabot-dominated changelog honestly: the package is maintained, not actively developed, so don't plan a roadmap on top of new features arriving.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed, drop-in editor for our admin panel that unlocks a class of internal features — editable configuration, templates, and snippets — for roughly the cost of a dependency and a wrapper file. There's no licence fee, no vendor, no external service, and no data leaves our application. The failure mode is bounded: worst case is a degraded form input, not data loss or an outage, provided we add server-side validation. Recommend it for internal tooling; do not use it on customer-facing or revenue-critical surfaces, where its single-maintainer profile is the wrong risk.

To engineering: One field class extending Filament's Field, plus compiled CodeMirror assets. No service provider, no config to publish, no migrations, no queues, no telemetry. Public API is fully documented in the README: setLanguage() and helpers, withLineNumbers(), disableAutocompletion(), disabled(), plus inherited label()/hint()/helper(). Two asks: pin the correct major against our actual Filament/Laravel versions before estimating, and wrap it in our own subclass so a revert is one file. Add rules() validation in the same ticket — the package will happily save invalid JSON. Expect a maintenance lag on every Filament major upgrade and run composer audit as the security review.

To product and design: We get syntax highlighting, autocompletion, line numbers, light/dark integration, and read-only display for free. What we still own is the user experience of "is this code correct?" — error copy, when we block a save, and whether we offer a preview. That's the part worth designing, and it's the part users will actually judge us on.