Signature Pad Laravel Package

Technical Evaluation

Architecture fit. coolsam/signature-pad is a thin Laravel/Filament wrapper over the signature_pad canvas library. Its value proposition is narrow and well-bounded: a Filament form field that captures a drawn mark as a base64 data URL, plus a Blade component for non-panel forms. It does not own identity verification, sealing, retention, or routing — those are downstream concerns the TPM must own explicitly. The right mental model is "a form widget that produces a PNG," not "an e-signature platform." Any scope framing that implies the latter is a compliance risk before a line of code ships.

Integration feasibility. Low technical friction, high governance friction. The mechanics are standard: Composer install, pin an exact version, register assets if the panel uses a custom Vite theme, add a nullable path column, and decode the payload on write. The blockers are non-technical but decisive — the Composer name (coolsam/signature-pad) does not match the repository owner (bradwarwick), there are zero stars and zero dependents, and there is no upgrade guarantee. Provenance verification (composer show --all) is a hard gate, not a checklist item. If the source URL does not resolve to the reviewed repo, vendor the code; do not pull it through Composer.

Technical risk. Three risks matter to a TPM. First, the vanishing signature: canvas state lives in the DOM and only reaches the server when Alpine syncs into Livewire; a validation failure elsewhere in a deferred-binding form can round-trip to a blank field. That is a user-visible data-loss bug in the exact flow (contract, waiver, acknowledgement) the package is sold for, and testing it must happen in the spike, not in production with a customer at a loading dock. Second, upgrade fragility: third-party Filament form fields are the most brittle surface across major versions, and the failure mode is silent — the form renders, the field is simply absent. Third, payload handling: naive inlining produces either silent truncation (varchar(255) → corrupt PNG) or query bloat (longText → every select * inflated). All three are mitigable, none are free.

Key questions. (1) Does the Composer source URL resolve to the reviewed repository, and what is the license and tag history? (2) What are the package's illuminate/* and filament/* constraints relative to our current Filament major? (3) Does signature_pad survive a deferred-binding validation round trip in our panel configuration? (4) Does it behave inside a repeater and a wizard step? (5) Which surface is the first use case — I would insist on internal acknowledgement (delivery confirmation, equipment checkout, policy sign-off), not contracts or waivers. (6) Who is the named owner for the next Filament major upgrade?

Integration Approach

Stack fit. Strong, provided the constraints align. The package targets Laravel + Filament, which is presumably our admin surface, and the underlying signature_pad library is dependency-free and well-understood. The Blade component gives us a non-panel path through the same storage contract, so we do not end up with two divergent signature implementations. The field's state is just a string, so Livewire form tests work without a canvas — this is a meaningful testability advantage over heavier canvas widgets.

Migration path. There is no migration in the conventional sense — this is net-new capability, so the path is greenfield with a spike gate. Sequence: prove provenance → pin version → read three files in vendor/ (the field class FQCN, the Blade view where x-data/x-model wire the canvas, the package's composer.json constraints) → build one field on one internal-facing form → run it on real users for a sprint → generalise. Do not ship against anything a lawyer will read in week one. The signature_path / signed_at / signed_by schema shape is the low-risk target; the artifacts table (signable morph, path, user_id, ip_address, user_agent, signed_at, content_hash) is the upgrade we should plan for from the start even if we do not build it on day one.

Compatibility. Two compatibility surfaces to pin: the package's Filament/Illuminate constraints against our Filament major, and the underlying signature_pad JS version — note it in the wrapper's docblock, because the wrapper is thin and the capability lives in that library. Custom Vite themes are the classic silent failure: the canvas renders as a static grey rectangle because the package's JS never made it into our bundle. Asset registration from the wrapper field's setUp() is the seam if auto-discovery does not cover us.

Sequencing. Wrap the vendor field on day one in an internal App\Filament\Forms\Components\Signature class that extends the vendor FQCN and owns validation rules (nullable, string, PNG data-URL prefix, size cap). Every form depends on our class, never the vendor's. This is the single highest-leverage decision in the whole integration: when the package breaks on a Filament major, or when we decide forty lines of Alpine plus a pinned signature_pad is a better bet, we edit one class and every form keeps working. Storage follows the disk-plus-path pattern from the first commit — decode on write in mutateFormDataBeforeCreate / mutateFormDataBeforeSave, validate PNG magic bytes via imagecreatefromstring, generate the filename with Str::uuid(), write to a private disk, and unset the raw payload so it never reaches the model. Accessibility is a launch gate, not a backlog item: a draw-only canvas fails keyboard and screen-reader users, and the European Accessibility Act makes a typed-name or upload alternative a requirement for EU audiences. Build it as a sibling field behind a "can't sign by drawing?" toggle writing to the same column contract.

Operational Impact

Maintenance. The package is effectively unmaintained by any measurable signal — zero stars, zero dependents, no upgrade guarantee, owner/repo mismatch. Treat it as vendored-and-owned rather than depended-on. The wrapper class absorbs breakage; a CI smoke test (assertFormExists('signature') plus a Livewire test that fills the field and asserts the file lands on the private disk) turns a silent Filament-upgrade failure into a red build. Add a named owner and a review ticket to every Filament major upgrade. Because the wrapper is thin, replacing it with ~40 lines of Alpine and a pinned signature_pad is a realistic afternoon — that is the exit option, and the wrapper is what makes it available.

Support. Support burden concentrates in three known failure modes: vanishing signature on deferred-binding validation round trips, blank-but-valid white PNGs from an accidental canvas tap, and canvas misbehaviour inside repeaters and wizard steps (Alpine re-mounts and state leaks between rows). Runbook entries for each. Language discipline is a support issue too: never call this "e-signature" in customer-facing material. It is evidence of acknowledgement — a drawn mark, a timestamp, a user ID. It does not do signer identity verification, tamper-evident sealing, multi-party routing, or retention guarantees. Write that boundary down next to the field; it is cheaper than the compliance conversation after launch.

Scaling. Storage scales cleanly on the disk-plus-path pattern: 5–50 KB per signature, private disk, temporary URLs for display. The two scaling traps are inline base64 (query bloat and hydration weight) and unconstrained canvas sizing on high-DPI tablets (payloads an order of magnitude larger than a phone). Cap the canvas around 600×200 logical pixels and cap the payload server-side regardless. Any PDF renderer, export, or list view that reads signatures must be null-safe for pre-rollout records and optional-field records.

Failure modes. In rough order of likelihood: (1) asset not compiled into a custom Vite theme → blank/dead canvas, form still renders; (2) Filament major upgrade → field silently absent; (3) deferred binding → signature lost on validation error elsewhere; (4) tampered or oversized payload reaching disk if validation is client-trusting; (5) empty canvas submitting a white PNG that passes decode; (6) ->disabled() or ->dehydrated(false)) behaving differently across Filament minors, surfacing as unexpected state in $data. Each has a cheap server-side or CI-side guard; the discipline is to build the guards in the spike, not after the first incident.

Ramp-up. Low for a Laravel/Filament developer — the integration is a form field and a storage helper, on the order of a day to first working field and a sprint to confident rollout on an internal form. The real ramp is TPM-side: provenance verification, compliance framing, accessibility alternative, and the CI smoke test. Budget that as the actual adoption cost. The code is easy; the governance is what makes it safe to ship.