Filament Sql Field Laravel Package

Product Decisions This Supports

• Build vs. buy for in-panel SQL authoring. The requirement "let power users write and save SQL in our admin panel" usually forks into either standing up a BI tool (Metabase/Redash/Cube) with its own SSO, permissions, and hosting, or hand-rolling an editor. This package collapses the hand-rolled path to a composer require plus one form-schema line, which materially changes the cost comparison for an MVP. It is the cheapest credible way to test whether self-serve SQL is even a demand signal before committing to a BI contract.
• Roadmap unblocking for internal ops tooling. A recurring backlog category — ad-hoc query runners for support, saved-report editors, custom metric definitions, SQL-backed alert rules, ETL/transformation step configuration, data-quality check authoring — gets chronically deprioritized because the editor is "boring work" with no user-visible payoff. Adopting this field removes that excuse and lets those features be scoped on their actual value.
• Scope framing: the field is 10% of the project. The package is presentation-only — it renders text, it does not execute, validate, sandbox, or authorize anything. That means the PM-visible work is not the editor, it is the gateway: read-only replica credentials, statement timeouts, row caps, tenant/row scoping, statement-type allow-listing, audit logging of every execution, and role gating on who sees the field at all. Making this explicit up front prevents a "it's just a text box, why is it a quarter?" conversation later.
• Audience and surface decision. The package is a good fit for internal, technical users (ops, support engineering, data team) where syntax highlighting plus keyword/table/column autocomplete is sufficient. It is the wrong layer for a customer-facing workbench, where dialect-aware intellisense, schema browsing, error surfacing, and accessible/mobile-tolerant UX become table stakes. This package helps you decide which of those two features you are actually shipping.
• Platform lifecycle and stack standardization. Release 2.0.2 explicitly adds Filament 5 support, which flips the timing calculus for admin-panel work already on the roadmap for teams on the current Filament major. It also sets a precedent: adopting CodeMirror 5 as the admin editor baseline is a legacy-major bet, so decide deliberately whether to standardize on it, wrap it behind a form-field contract, or plan the eventual CodeMirror 6 / Monaco migration.
• Vendor and maintenance risk acceptance. MIT license, 18 stars, zero dependents, a single maintainer. That is an acceptable risk only if paired with a decision to pin and vendor the component and to keep the editor behind an interface the query service owns. The 2.0.2 release is a genuine positive maintenance signal but does not change the structural bus-factor picture — treat it as a governance call, not a technical one.

When to Consider This Package

Consider it when:

• You are already on Filament and need a SQL text input inside a form or resource. This is its precise, narrow job — no more, no less.
• You are on Filament 5, or have a committed migration to it. The compatibility objection for current-major Filament stacks is largely resolved by 2.0.2; still verify the full version matrix before scoping.
• The audience is internal and technical, where highlighting plus basic autocomplete is enough and deep intellisense is nice-to-have.
• You need a working MVP in days and have accepted that the execution layer is yours to build regardless of what you pick for the editor.
• You are comfortable owning the risk: the component surface is small enough to patch or fork in-house, and swapping editors later is a contained refactor if you keep the query service editor-agnostic.
• Your security model already gates raw SQL behind roles plus a restricted database connection — the field is only the input surface.

Look elsewhere when:

• The feature is customer-facing, or users are non-technical. You will want dialect-aware autocomplete, schema browsing, structured error surfacing, and accessible mobile UX that a highlighting-only field is not positioned to deliver.
• You need a modern editor baseline (CodeMirror 6, Monaco) or are actively standardizing away from CodeMirror 5 for longevity reasons. Nothing in the 2.x notes indicates an editor-engine change, so assume CodeMirror 5 remains the underlying bet.
• You are not on Filament, or your Filament version falls outside the support window. A major-version bump often signals a dropped-version policy — confirm rather than assume.
• You need SLAs, support commitments, or a maintenance guarantee. One maintainer, no dependents, no vendor, no backstop.
• You were hoping the package would handle execution, validation, or sandboxing. It does not; if that was the requirement, this is the wrong layer and you should be pricing a query gateway or a managed BI product instead.
• You require rigorous release notes. "Support Filament 5" and "Improving existing resources" are thin; if documented breaking changes matter to you, read the diff before pinning.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed UI component that puts a syntax-highlighted SQL editor inside our existing admin panel. It is not a reporting platform, not a security control, and not a data product — it is the text box. Its value is speed and option value: it removes roughly one to two weeks of editor integration from any internal reporting, ops-console, or custom-metrics feature, and it lets us test whether self-serve SQL reporting is worth funding before we sign a BI vendor contract. Release 2.0.2 adds Filament 5 support, so it aligns with our current admin stack rather than a legacy branch. License cost is zero and the code is small enough to fork if the maintainer stops. The real investment is not the package — it is the guardrails: read-only database access, statement timeouts, tenant scoping, query auditing, and role gating. We would need those for any SQL-authoring feature regardless of vendor, so this package lets us spend the budget on the part that actually reduces risk. Recommendation: adopt narrowly for internal, admin-only surfaces, phase-gate the release on the security gateway, and revisit the buy-a-BI-tool decision once we have usage data.

For engineering: It is a Filament form field wrapping CodeMirror 5 for SQL authoring — highlighting and input only, no execution, no dialect awareness, no parameter binding, no authorization, no auditing. Integration is a Composer install, field registration, and a form-schema entry; the blast radius is one small MIT component that is trivially forkable and replaceable behind the same form contract. Two things to verify before pinning 2.0.2: the full supported Filament/Laravel/PHP/Livewire/Alpine matrix (including whether Filament 4 is still supported after the major bump, and whether 1.x installs upgrade cleanly), and whether "improving existing resources" touches any published views or assets we may have overridden. Also validate CodeMirror asset registration under Vite and our CSP, and check read-only/disabled behavior inside modals, repeaters, and relationship contexts. Assume CodeMirror 5 is a legacy bet and keep the eventual migration cheap by putting the editor behind an interface owned by the query service. Everything security-relevant — restricted credentials, timeouts, row caps, tenant scoping, execution logging — is on us and should be specified and built as a separate, editor-agnostic layer before this field ships to any environment.