Statamic Bard Text Align Laravel Package

Technical Evaluation

Architecture fit

• Statamic addon packaged as a Laravel package: service provider registration, control-panel asset injection, and a Bard/TipTap editor extension. No migrations, routes, models, or persistence layer — it is a pure presentation-layer extension to the existing Bard fieldtype.
• This matches Statamic's intended extension model cleanly. Blast radius on the host application is small and reversible at the package level.
• The one architectural dependency that matters: alignment in TipTap is stored as an attribute on nodes/blocks inside the Bard ProseMirror JSON. The addon therefore has two responsibilities — editor UI and output rendering — and only the first is guaranteed by the description.

Integration feasibility

• Mechanically trivial: composer require, Laravel package discovery, optionally publish assets, then expose the align buttons in the Bard fieldset configuration.
• The real feasibility question is end-to-end: does the addon also register a server-side mark/node renderer (or ship CSS classes) so textAlign is emitted in the rendered HTML? If it only ships the editor extension, editors will see centered text in the CP and readers will not — a silent, high-visibility defect.
• Secondary checks: whether alignment survives Bard's HTML sanitization on save, whether it works in markdown-mode Bard, and whether it double-registers inside nested Bard instances (Replicator/Grid sets).

Technical risk

• High relative to the value delivered. Zero stars, zero dependents, no visible test suite or version matrix, and a single maintainer — this is effectively an unmaintained snippet published as a package.
• Statamic ships a bundled TipTap/ProseMirror version that moves with each release. A stale extension can throw at registration and take down the entire Bard fieldtype in the CP, blocking all content editing, not just alignment.
• Inline style attributes are a common casualty of HTML sanitizers; if either save-time or render-time sanitization strips them, the feature is cosmetic-only.
• Accessibility/i18n exposure: alignment is often misused for layout, and text-align interacts with RTL. No guardrails are provided.

Key questions

• Which Statamic, Laravel, and PHP versions are supported, and is that constraint encoded in composer.json?
• Does it ship a frontend renderer, or only the CP extension? Inline style or CSS class?
• Is the extension compatible with the TipTap version bundled in our target Statamic release?
• License terms and any security/ disclosure process?
• Behavior in nested Bard fields and in markdown-mode Bard?
• Build vs. buy: an in-house TipTap alignment extension plus a renderer is on the order of tens of lines and removes the dependency entirely — why not own it?

Integration Approach

Stack fit

• Compatible with any Laravel application running Statamic 3+. No new services, infrastructure, queue workers, or data model changes. Composer install plus the existing CP asset pipeline is the entire footprint.
• No interaction with the application's own domain code, which keeps the change auditable and easy to ring-fence.

Migration path

• Timebox a spike on a branch against a single low-traffic Bard field: confirm the toolbar buttons appear, confirm textAlign lands in the saved JSON, and confirm the rendered HTML carries the alignment.
• If the render path is missing, the cheapest remediation is a small renderer hook (Antlers/Blade post-processing or a custom mark renderer) rather than patching the package — but that remediation cost must be counted as part of adoption.
• Exit is low-risk structurally: unknown attributes in stored Bard JSON are ignored, so uninstalling breaks nothing. Content authored with alignment silently loses it, so a content inventory/snapshot before removal is prudent.

Compatibility

• Pin the exact version and gate Statamic minor upgrades behind a smoke test that opens and saves a Bard field in the CP. This is the single most likely breakage vector.
• Strongly consider vendoring or forking the JS extension into the application's own Vite build. It decouples us from upstream's release cadence at near-zero cost given the code volume, and converts an unmaintained dependency into internal code we already control.

Sequencing

1. Technical spike and go/no-go against the render-path question.
2. Decide consume-as-is vs. fork-and-own; default to fork given upstream signals.
3. Pilot on one fieldset with a named content owner.
4. Add a CI/manual regression check covering CP load, save, and render for that field.
5. Roll out to remaining fieldsets with authoring guidance; document the fork and its owner.

Operational Impact

Maintenance

• Treat as internal code from day one. Expect no upstream fixes; the package is small enough that patching is cheap, but it requires someone comfortable with TipTap/ProseMirror rather than general Laravel work.
• Budget a recurring line item for "re-validate on Statamic upgrade" — small, but permanent.

Support

• No vendor, SLA, or security disclosure channel. Incidents route to the internal team that adopted it. Any CVE or breaking change is discovered, triaged, and patched by us.
• Document the fork's provenance and divergence so future maintainers know it is not a normal dependency.

Scaling

• Negligible. Client-side only: a small JS payload added to the CP bundle per editor session, no server rendering cost, no effect on request throughput, storage growth, or horizontal scaling.
• The only scaling-adjacent concern is CP bundle bloat if many similar micro-addons are adopted — a governance point, not a performance one.

Failure modes

• Highest severity: CP Bard field breaks after a Statamic or TipTap upgrade, blocking all content editing for all editors — not just alignment.
• Silent data loss: alignment written in the editor but stripped on save or omitted at render, producing content that looks correct to authors and wrong to readers.
• Editor/renderer drift: inline style in the CP but no equivalent in the frontend, or vice versa after a sanitizer change.
• Nested context: duplicate extension registration inside Replicator/Grid Bard sets causing JS errors or duplicated toolbar buttons.
• Each of these is detectable with a three-step smoke test, which should be automated before broad rollout.

Ramp-up

• Developer: under a day to install and wire up; one to three days to validate the render path and, if needed, fork and own the extension.
• Content editors: minutes of guidance, but include a short policy on when alignment is appropriate (avoid layout-via-alignment; check RTL and accessibility implications).
• Overall: low integration cost, moderate ongoing ownership cost, and a value proposition that is real but narrow — justify adoption on the basis of owning a small piece of code, not on the package's maturity.