Filament Placeholder Input Laravel Package

Product Decisions This Supports

• Self-serve template authoring in the admin panel. The concrete use case is letting non-engineers edit content that contains variables — transactional emails, notification copy, SMS templates, CMS snippets, contract/merge fields, saved replies. Instead of hand-typing {{ customer.first_name }}, an operator picks a token from a controlled list. That turns "ask an engineer to change the copy" into "ops edits it themselves."
• Roadmap sequencing for a template/messaging surface. If template editing is on the roadmap, this package covers the input half of the problem cheaply. It does not cover rendering, validation, or variable resolution — those still need a backend resolver, and that's the larger piece of work. Budget accordingly; don't let a one-star form field create the impression the feature is "mostly done."
• Build vs. buy (really: adopt vs. fork vs. build). Scope here is a Filament form field — roughly a day or two of engineering to reimplement minimally. That makes this a low-stakes decision, not an architecture decision. Recommended framing: adopt as a reference implementation, fork if we ship it, and never treat it as a load-bearing dependency.
• Support-cost reduction. A meaningful share of template-related tickets are "what variables can I use?" and "I broke the email." A constrained token-insertion UI removes a class of user error and a class of tickets. That's the ROI case, and it's measurable.
• Signal quality caveat for the roadmap. 1 star, 0 dependents, single maintainer, opportunity score 28.1. This is a component candidate, not a strategic bet. It should enter the backlog as a timeboxed spike, not as a committed dependency in a quarterly plan.

When to Consider This Package

Consider it when:

• You are already on Filament (Laravel/TALL stack) and the need is a field-level affordance inside an existing form — no new UI paradigm required.
• The requirement is genuinely narrow: insert a predefined piece of text into another field. If you can describe the feature in one sentence to a stakeholder and they nod, you're in scope.
• You have an engineer who can pin the version, vendor or fork it, and own it — including adding the tests the package may not ship with.
• You want a fast prototype to validate whether self-serve template editing actually reduces tickets before investing in a proper template engine.
• License and footprint matter and MIT with no transitive dependency tree is attractive (verify composer.json before assuming).

Look elsewhere when:

• You're not on Filament, or you're on a Filament major version this package hasn't caught up to. Filament majors move fast; a single-maintainer package is the most likely thing in your stack to lag. Confirm compatibility in the version matrix, not the README.
• You need anything beyond text insertion: rich-text editing, conditional blocks, loops, placeholder validation, preview rendering, or per-tenant/per-role placeholder catalogs with permissions and audit trails. Those are backend concerns and this package is input-side only.
• Placeholders resolve to PII or anything security-sensitive. You want your own resolver and your own allow-list regardless of what the input widget is.
• You require vendor support, an SLA, a security-response process, or a track record. One recent tag is not a track record — check the actual commit and release history before trusting the date.
• Accessibility and i18n are hard requirements and you can't absorb the work of patching them yourself.

How to Pitch It (Stakeholders)

For executives (one paragraph):

Ops and marketing currently file tickets to change templated emails and notifications. A small MIT-licensed UI component would let them insert approved variables themselves, cutting a recurring class of tickets and typos. Cost to trial is about one engineer-day; there is no license cost. The caveat is maturity — the package is a single-maintainer project with essentially no adoption, so we would not depend on it as-is. The recommendation is a one-day spike, then fork and own the small amount of code if it proves useful. This is a workflow improvement, not a platform investment, and it does not by itself deliver a template engine.

For engineering (the actual ask):

• Drop-in Filament field, MIT, small surface area. Proposed handling: vendor or fork, pin the version, add a smoke test, and treat upstream as a reference rather than a dependency.
• Confirm Filament major-version compatibility and check composer.json for transitive requirements before we commit.
• Estimate the in-house alternative at 1–2 days for a minimal token-insertion field. If the fork friction exceeds that, build it — the build/buy line is that close.
• Pair it with a server-side resolver and allow-list; the widget must not be the only thing standing between a user and a malformed template.

Decision requested: approve a one-day evaluation spike with a go/no-go gate. Success criteria: works on our Filament version, passes a basic insert-and-save test, and an ops user can author a template without engineering help. If any of those fail, we build the field ourselves and keep this repo as the design reference.