Filament Code Field Laravel Package

Technical Evaluation

Architecture fit

• Leaf-node dependency: one PHP field class extending Filament's Field, plus pre-compiled CodeMirror JS/CSS shipped in the package. No service provider to register, no config to publish, no migrations, no queue workers, no API surface. It renders inside the Livewire form tree and binds a single model attribute like any other field.
• Fit is therefore binary and cheap to decide: does the target screen live in a Filament 3 panel, and is the payload a modest blob of structured text (JSON config, template, snippet, snippet-of-SQL)? If yes, it is a drop-in. If the requirement is a read-only infolist viewer, a diff view, a full IDE, or a code editor on a non-Filament Blade form, the architecture does not fit and no configuration closes that gap.
• The package is presentation-only. It provides syntax highlighting and autocompletion; it provides no correctness guarantee. "Is this valid JSON / does this PHP parse / is this SQL safe" is your application's job via Laravel validation rules or a rules() closure. A TPM must spec "invalid code is rejected at save" as a separate line item with its own estimate — it is not something this dependency delivers.

Integration feasibility

• Mechanically trivial: composer require creagia/filament-code-field, then CodeField::make('settings_json') in a schema. Language via setLanguage() or helpers (->jsField(), ->htmlField()), plus withLineNumbers(), disableAutocompletion(), disabled() for read-only, and all inherited Filament methods (label(), hint(), helper()). The entire public API fits in the README — a good sign at this size.
• The real integration cost is version pinning, not code. The matrix is inverted relative to convention: ^3.0 requires Filament 3 and Laravel 11; ^2.0 is the correct choice for Filament 3 on Laravel 10–12; ^1.0 is Filament 2. A team on Laravel 12 that naively takes the newest tag will fail resolution or hit runtime breakage. Verify against the actual composer.json before the spike, not during it.
• Documentation drift is a small known risk: the changelog records SQL language support in 1.0.2, while the README's supported-language list stops at JSON/PHP/HTML/XML/JS. Any language-dependent feature must be proven in your pinned version rather than assumed.
• Asset delivery is the one genuinely uncertain area. The package ships compiled assets that interact with Filament's asset loading, dark-mode detection, and RTL handling. Whether that survives your Vite build, vendor publish step, CDN caching, and CSP (inline style injection) is worth a half-day spike rather than a post-merge surprise.

Technical risk

• Abandonment / bus factor — medium. 57 stars, zero dependents, one principal maintainer, MIT, and a changelog dominated by Dependabot and CI-action bumps rather than feature work. Normal profile for a Filament utility field; acceptable for internal admin tooling, not acceptable in a customer-facing or revenue-critical path.
• Upgrade coupling — medium. Because it extends Filament's Field and ships JS that hooks Filament's asset and theming behaviour, a Filament major (v3 → v4) is the breakage trigger, and your remediation schedule depends on a third party's release timing. Budget a lag on every Filament major.
• Blast radius is contained — low. The failure mode is a degraded form input, not data corruption or an outage — provided server-side validation exists and the field is wrapped behind a thin internal subclass so reverting to a plain Textarea is a one-file change.
• No runtime services. No telemetry, no external calls, no licence server. Nothing to firewall, nothing to monitor, nothing that phones home. Security review is composer audit plus a read of the compiled bundle.

Key questions to resolve before commitment

1. What exact Filament and Laravel versions are pinned in the target panel, and which package major does that map to?
2. Who owns server-side validation of the payload, and is that rule in the same ticket as the field?
3. What is the maximum number of code fields on any single screen? (Cap at two or three — each mounts an independent CodeMirror instance, and multi-editor height behaviour was only stabilised in 1.0.11.)
4. Is the surface strictly internal admin, or does any customer-facing path render it?
5. Do we accept the small maintenance burden of a thin internal wrapper subclass, or use the vendor class directly and accept a wider revert?
6. Does our deployment satisfy the asset assumptions (compiled assets present under vendor/, no CDN dependency, CSP permits its style injection)?

Integration Approach

Stack fit. Prerequisites are a Filament 3 panel on PHP 8.1–8.4 with Laravel 10–12 (pin ^2.0) or Laravel 11 with ^3.0. Note that the ^2.0 branch is the broader compatibility line for Filament 3 — this inverts the default "always latest" instinct and must be written into the ticket so Composer does not silently resolve the wrong major.

Migration path. There is nothing to migrate. Existing plain Textarea / KeyValue fields are replaced one at a time by swapping the field class in the schema; the underlying column and model are untouched, so the change is reversible per-screen with no data migration. Introduce it through a thin internal wrapper (e.g. App\Filament\Fields\CodeField extends Creagia\...\CodeField) that pins the language defaults and any house styling, so an upstream break or abandonment becomes a one-file swap back to Textarea rather than a hunt across schemas.

Compatibility. Treat three axes independently: (a) Composer resolution against the pinned Laravel/Filament versions, (b) asset delivery in the real deployment pipeline (staging, behind your CDN and CSP), (c) behavioural fit — dark mode, RTL locales if you ship them, and multiple editors per page. (c) is where every historical bug in this changelog lived, so prove it on a real screen rather than in isolation.

Sequencing.

1. Spike (0.5–1 day): install on a throwaway branch at the correct major, render one JSON field and one PHP field on a staging panel, confirm assets load under CSP and that dark mode/RTL behave. Exit criterion: field renders and saves.
2. Validation design (0.5 day): define per-field rules (json, custom PHP-parse closure, length caps via the 3.0.2 min/max length API) and a clear user-facing error message.
3. Wrapper + pilot (1 day): build the internal subclass, convert one low-traffic internal screen, ship, and observe for a sprint.
4. Rollout (batched): convert remaining screens in small batches, two or three fields per page maximum, with a per-screen revert path documented.
5. Guardrails (ongoing): a composer audit step in CI, Dependabot watching the package, and a written note in the ADR that Filament v4 will require a compatibility check here.

Operational Impact

Maintenance. Low ongoing effort in steady state: no config, no migrations, no background jobs, no infrastructure. The recurring cost is version babysitting at two boundaries — Laravel/Filament upgrades and PHP upgrades — plus periodic composer audit follow-through on the bundled JS dev-dependency chain (several recent releases were security bumps to dev dependencies only, which do not affect the published artifact but do generate noise). Assign a named owner for the wrapper class; treat it as a small internal library, not a fire-and-forget require.

Support. Support load should be near zero if you set expectations up front: this is a text box with colours, not a linter. Pre-empt the predictable tickets — "it says my JSON is invalid but it looks fine" (that is your validation rule, route it accordingly), "autocomplete is wrong" (CodeMirror defaults, disable per-field if it misleads), "it looks small on my laptop" (min/max height settings, stabilised in 1.0.11). Publish a one-paragraph internal note on the field's scope. Because the vendor is a small shop with 57 stars, do not route user tickets upstream; assume you own first-line support and that upstream fixes are best-effort.

Scaling. Vertically trivial — the component costs one CodeMirror instance per rendered field on the client and essentially nothing server-side. The only scaling constraint is per-page editor count: mount one or two, not five; each is an independent JS instance with its own height and theming logic, and that is historically the buggiest area of this package. Payload size should be bounded by a validation max (a code field is for snippets, not for 2 MB documents) to protect Livewire request payloads. There is no horizontal scaling, licensing, or per-seat dimension at all.

Failure modes and responses.

• Assets fail to load after deploy (build/cache/CSP change) → field renders as a broken or plain textarea. Detection: smoke test on the pilot screen post-deploy. Response: verify vendor asset publishing and CSP; fall back to Textarea via the wrapper.
• Filament major upgrade → class or JS incompatibility surfaces as a broken field, not an app error. Response: pin the vendor major, gate the Filament upgrade on a code-field check.
• Upstream abandonment → no new releases, security bumps stop. Response: the MIT licence and thin wrapper mean you can fork or vendor the class; a 200-line field is a realistic in-house replacement. This is why the wrapper exists.
• Invalid code saved → data-quality issue, not an outage. Response: this is entirely your validation's responsibility; if it is absent, that is the actual defect, not the package.
• Single-editor edge cases (RTL, dark mode, multi-editor height) → cosmetic, contained, and already covered by upstream fixes in 1.0.11; verify on the pinned version.

Ramp-up. Dev ramp-up is roughly an hour: any developer who has written a Filament form field already knows the API, and the README is complete. No new infrastructure, no new language, no new operational surface for on-call. The more important ramp-up is product: stakeholders should hear explicitly that this gives syntax colouring and completion, and that validation, diffing, and execution safety are separate features with separate estimates. Setting that expectation at kickoff is the highest-leverage thing a TPM does for this dependency.