Mary Laravel Package

Technical Evaluation

Architecture fit

• mary is a Blade component library for Livewire, not a framework or backend dependency. It sits purely in the presentation layer: <x-mary-input>, <x-mary-table>, <x-mary-modal> compile to Blade/HTML and interact with Livewire via wire:model and Alpine directives. There is no service provider logic in the request path, no database surface, no queue/event integration, so architectural blast radius is deliberately small.
• Coupling is to three moving front-end dependencies rather than to Laravel internals: Livewire (state/events), daisyUI (semantic class layer), Tailwind (build). Our Laravel version is largely irrelevant; our Livewire and Tailwind/daisyUI versions are the real compatibility contract.
• Strong fit if our admin/back-office UI is Livewire-based and currently hand-rolled. Poor fit if the product surface is Inertia/Vue/React, or if we already standardize on Filament or another Blade kit — mixing two component kits produces divergent form semantics, validation display, and theme tokens.

Integration feasibility

• Low effort to prove out. Composer require, run the installer/config publish, add mary's vendor views to Tailwind content globs, register daisyUI in tailwind.config.js, pick a theme. A working page inside a day; a coherent design system in weeks.
• The installer locks dependency versions (added in 1.41.6), which is a positive signal for reproducibility but means a fresh install may pin us to a daisyUI/Tailwind combination we must verify against our existing build.
• Risk concentrates in the components that ship third-party JS: Editor (TinyMCE), Choices/ChoicesOffline, Datepicker, Signature, File/ImageLibrary (cropper), Carousel. Each adds bundle weight, own a11y behavior, and its own upgrade cadence.

Technical risk

• Semver discipline is weak. 2.3.0 renamed enabled → hidden on Menu/MenuItem/MenuSub inside a minor release. 2.0.0 required a dedicated upgrade guide. Treat any minor bump as potentially breaking and pin exactly.
• License ambiguity. Packagist reports NOASSERTION while the README and /license.md state MIT. Low actual risk, but we should get legal to confirm the LICENSE file text before this lands in a distributed product. Separately, TinyMCE (Editor component) carries GPL implications — the package added a gpl-license attribute in 1.41.2 for exactly this reason. Do not ship the Editor component without a licensing decision.
• Theme collision. daisyUI introduces its own semantic token set (primary, base-100, border variables). If we have an established Tailwind palette or a brand design system, we either map daisyUI themes onto our tokens or accept two parallel systems.
• Patch cadence with UI-only fixes. Recent releases are dominated by small regressions: Tab badge prefix, Tabs refresh, ImageGallery CSS, Drawer id(), Menu horizontal. Evidence of active maintenance and of a surface that changes often enough to break pixel-level expectations between patches.
• Adoption signal is thin. ~1.5k stars, and the reported dependent count is zero — treat this as a metadata limitation rather than proof of no usage, but it does mean we are unlikely to find many public war stories for edge cases.

Key questions

1. Which Livewire major are we on, and is mary's current branch validated against it? What about daisyUI v4 vs v5 and Tailwind v3 vs v4?
2. Do we have an existing design token system, and can daisyUI themes be mapped onto it without a parallel palette?
3. Who owns accessibility sign-off, and does mary's modal focus trap, RTL support, and keyboard nav in Choices meet our bar (WCAG 2.1 AA plus our own audit tooling)?
4. Is the TinyMCE-based Editor in scope, and if so, what is our licensing position?
5. What is our policy on single-maintainer, sponsor-funded dependencies for a customer-facing UI layer?
6. Which components do we actually need versus which are "nice to have" bundle weight?

Integration Approach

Stack fit

• Preconditions: Laravel with Livewire and Vite; Tailwind compiled (not CDN); Alpine available (bundled with Livewire). mary is a poor fit for a no-build front end.
• Fit is best for internal tools, admin panels, and CRUD-heavy back office where form and table components dominate. For a marketing site or a highly custom consumer UI, the daisyUI aesthetic becomes a constraint rather than a lever.

Migration path

• Blade components are additive and co-exist with existing markup — no big-bang rewrite is required or advisable. Start with one internal, low-traffic module (settings, user management, reporting filters) and leave customer-facing flows for later.
• Recommended shape: adopt mary, then immediately build a thin internal wrapper layer (<x-app.input>, <x-app.table>) around the highest-churn mary components. This confines breaking renames like enabled → hidden to a handful of files instead of a repo-wide search.
• Sequence route groups rather than pages: migrate an entire vertical slice so form semantics, validation display, and flash/toast behavior are consistent within it.

Compatibility

• Build pipeline first: Tailwind content must include ./vendor/robsontenorio/mary/src/View/Components/** (or the published views path), otherwise components render unstyled in production builds while looking fine in dev.
• Pin robsontenorio/mary to an exact version in composer.json (no caret), and pin daisyUI in package.json. Record the validated triple (mary / daisyUI / Tailwind) in the repo README so the next engineer does not have to rediscover it.
• Validate dark mode and theme switching early — daisyUI theme switching interacts with any existing dark: class strategy and is easy to get subtly wrong.

Sequencing

1. Spike (1–2 days): install on a branch, render a form + table + modal, confirm build output, bundle size delta, and dark mode.
2. Foundation (1 week): theme tokens, Tailwind config, wrapper components, lint/format conventions for component usage.
3. Pilot slice (1–2 sprints): one internal module end-to-end, including a11y and browser QA.
4. Rollout: module by module, with a documented upgrade runbook (read changelog, bump, diff visually, run the pilot module's tests).
5. Guardrails: dependabot/Renovate configured to open PRs, not auto-merge for this package.

Operational Impact

Maintenance

• Effective bus factor of one. The project is actively and consistently released (frequent patches through 2.9.x), but it is a solo-maintainer, sponsor-funded effort with no foundation or corporate backing. That is acceptable for UI chrome, not acceptable for anything we cannot replace.
• Budget a recurring cost: roughly one engineer-day per quarter to evaluate upgrades, plus visual regression coverage. Without automated screenshot tests, patching this library is a manual QA exercise every time.

Support

• Community-only: docs site (mary-ui.com), Discord, GitHub issues. No commercial SLA, no security disclosure process we can point to, no enterprise support tier. Escalation for a production-blocking bug is "wait for the maintainer" or "vendor it and patch locally." The README documents a path-based Composer override for this — keep that escape hatch documented and rehearsed.
• Ensure our own dependency-vulnerability scanning covers the transitive npm assets, not just Composer.

Scaling

• No server-side scaling characteristics — no queries, no caching, no background work. Performance impact is entirely client-side bytes and DOM complexity.
• The heavy components are the scaling concern: TinyMCE, Choices, the image cropper, and signature pads. Lazy-load or route-split pages that use them; do not put the Editor on a page every user hits. Large <x-mary-table> renders with hundreds of rows should be paginated or virtualized server-side — the component is presentational and will not protect us from a big payload.
• Livewire morph behavior with deeply nested components (tabs, modals, drawers) has historically needed wire:key fixes; expect to add keys ourselves in dynamic lists.

Failure modes

• Silent visual regression on patch upgrade — most likely failure. Mitigation: pinned versions plus visual regression snapshots of the pilot slice.
• Unstyled components in production — Tailwind content glob misconfiguration. Mitigation: build a staging deploy check that asserts a known component class exists in the compiled CSS.
• daisyUI/Tailwind major upgrade lockstep — mary's version support for a new daisyUI major will lag. Mitigation: never upgrade Tailwind/daisyUI and mary in the same change.
• Abandonment — low probability given current cadence, but the mitigation is structural: the wrapper layer means we can inline the handful of components we actually depend on and drop the package within days, not months.
• Livewire upgrade incompatibility — mary's release notes are the signal; block Livewire majors until mary ships support.

Ramp-up

• Low for anyone fluent in Blade + Alpine: markup is declarative and the docs are example-driven. Expect half a day for a mid-level Laravel dev to be productive.
• Higher for designers: they must learn daisyUI's semantic token vocabulary rather than raw Tailwind utilities, and design against a theme rather than against our token set.
• Hidden cost: teams often over-adopt and use mary for every element, ending up with a UI whose look is dictated by an external project's taste. Set an explicit rule about where mary is allowed and where custom components are required, before the pilot, not after.