Neura Kit Laravel Package

Technical Evaluation

Architecture fit. neura-ui/neura-kit is a Composer-installed frontend package: the PHP surface is a service provider, a config publish, and an neura-kit:install Artisan command, while the substance is Blade components, Alpine behaviour, Tailwind classes, and canvas-rendered visuals. It slots into the presentation layer of a Laravel app and stays out of the domain, persistence, and queue layers. That is a good fit if the team already runs Blade + Tailwind + Alpine; it is a poor fit if the product is Inertia/React/Vue-first, since the component API is Blade-tag based (neura::action-button, neura::split-button, neura::json-viewer, etc.).

Integration feasibility. Installation is genuinely low-ceremony: composer require neura-ui/neura-kit:^3.0, then php artisan neura-kit:install, which patches the first Vite config it finds (.js/.mjs/.ts/.mts) and appends a Tailwind @source line to resources/css/app.css. app.js is deliberately untouched, so the installer will not clobber existing bootstrap code. MIT with no license key removes procurement friction. The main feasibility question is version alignment — Tailwind 4's @source directive, the Alpine build the app already ships, and Livewire 3 binding behaviour all need to line up before the first component renders.

Technical risk. v3.0.0 is a major release and the risk is concentrated in the visual layer, not in data or runtime correctness. The neuraKit({ appearance }) surface ramp (hue, style of neutral/muted/tint/vivid, light/dark intensities) means any app-level CSS that overrides background, border, or text tokens will drift out of step. The unified popup morph and the toast restack (now registered via onAlpineInit, with drag-to-dismiss and stacking) change timing and layering behaviour for dialogs, dropdowns, selects, and toasts — the components most likely to have app-specific workarounds. A cluster of new interactive widgets (signature pad, time dial, date reel, activity rings, mention input, number field) are custom-drawn and therefore carry keyboard/screen-reader and pointer-precision risk that Blade wrappers alone will not solve. The 2.1.10 date-picker fix (UTC new Date('YYYY-MM-DD') parsing causing label/highlight disagreement) is a useful signal that date semantics have been fragile and deserve explicit regression tests.

Key questions.

• Which Tailwind, Alpine, Livewire, and Vite versions are officially supported, and is there a version matrix for 3.x?
• Does the installer patch fail loudly or silently when the Vite config is non-standard (custom build.rollupOptions, monorepo layout, .mts with ESM-only config)?
• Is there a Blade-only path, or does any component assume Livewire (wire:model, x-modelable, $wire.set)?
• What is the accessibility posture for the canvas widgets — documented keyboard maps, ARIA roles, and screen-reader behaviour — and is it covered by the maintainer's test suite or left to consumers?
• What is the support model behind an MIT, no-license-key package: maintainer responsiveness, release cadence, security disclosure channel?
• Which surfaces changed visually in 3.0.0 (table, kanban, flow, dropzone, calendar, editor syntax colours, orb) and is there a published visual diff or upgrade guide beyond the changelog?

Integration Approach

Stack fit. Target a Laravel app on Blade with Tailwind (v4 assumed, given @source) and Alpine, optionally Livewire for stateful forms. Components compose into existing screens without touching routing, controllers, or Eloquent models. If the app uses a JS framework for the shell, the value drops sharply — the package would only be usable in embedded Blade islands.

Migration path. Treat this as a greenfield adoption at ^3.0 rather than an upgrade, since no prior assessment or installed version exists. Sequence: (1) branch and install, (2) run the installer command and inspect the diff it produces to vite.config.* and app.css before committing — this is the one step that auto-edits tracked files, (3) pin the resolved versions of Tailwind/Alpine/Livewire in the lockfile, (4) adopt one low-risk component (a button variant or neura::json-viewer) to prove the token ramp and Alpine boot work end-to-end, then (5) expand.

Compatibility. The appearance API is the integration contract: define hue, style, and light/dark intensity once in neuraKit() and let components inherit rather than overriding per-component. Verify global CSS for any hardcoded hex values or token overrides that would fight the new ramp; the release explicitly calls out table, kanban, flow, dropzone, calendar, and editor colour changes, which is where custom overrides are most likely to break. Confirm reduced-motion handling in both paths — the CSS rule collapses animation-duration/transition-duration, but element.animate() is unaffected and scripted motion now checks prefersReducedMotion() itself, so app-authored animation must follow the same convention.

Sequencing. Land the dependency and build wiring first (no UI change), then theming, then components in ascending risk: buttons and button groups → number field, mention input, date reel → date picker/calendar and table → canvas widgets (charts, activity rings, time dial) → signature pad last, since it carries the highest a11y and data-handling scrutiny. Ship a visual regression baseline before step three so the token-driven restyle of table/kanban/flow is measurable rather than subjective.

Operational Impact

Maintenance. No server-side runtime cost, no migrations, no background jobs — operational load is entirely build-time and upgrade-time. The recurring cost is visual QA on every major: 3.0.0 touched nearly every themed surface plus popup timing, so a minor-looking bump can produce broad pixel churn. Budget for a component-level visual regression suite (Playwright screenshots per component in light/dark and reduced-motion) as a prerequisite, not an afterthought.

Support. MIT with no license key means no commercial SLA. The maintainer's changelog quality is high — detailed, Keep-a-Changelog formatted, with named fixes — which is a positive signal, but the team should assume self-support: pin the version, read changelogs before bumping, and be prepared to patch or vendor a component if a widget bug blocks a release. Establish an internal owner for the design-token layer so theming drift does not accumulate.

Scaling. Scales well horizontally because nothing runs server-side. The scaling concerns are bundle size and team consistency: the 3.0.0 surface adds a dozen component families plus canvas chart types, motion tokens, and i18n strings, so confirm the components are tree-shaken/registrable per-use rather than all loaded. On the human side, appearance and the motion token set (duration-fast through duration-spring, ease-standard/ease-enter/ease-spring) need enforcement — otherwise each squad hand-rolls transitions and the shared tokens stop meaning anything. i18n currently covers EN/FR only; any other locale means contributing strings or accepting English fallbacks in the JSON viewer and new form controls.

Failure modes. (1) Installer patches the wrong Vite config or a non-standard one — build breaks or the @source line lands in the wrong stylesheet, producing unstyled components at runtime. (2) Missing @source globs cause Tailwind to purge classes used only inside vendor Blade views, giving partial styling that looks like a CSS bug. (3) Alpine boot ordering — the toast factory previously missed Alpine's first walk and now uses onAlpineInit; any app bootstrapping Alpine manually can still race, so verify toasts render after livewire:navigated. (4) Token-ramp assumptions — hardcoded colours in app CSS silently override appearance, yielding inconsistent borders and text in dark mode. (5) Date handling regressions, as seen in 2.1.10; lock behaviour with tests around timezone and YYYY-MM-DD normalisation. (6) Canvas widgets render blank or unresponsive under SSR, test environments, or restrictive CSP without a fallback. (7) Reduced-motion gaps for scripted animations that bypass the CSS rule.

Ramp-up. Low for developers: Blade tags with declarative props and sensible packs (size, variant, colour, rounded) are learnable in an afternoon, and the installer removes setup guesswork. Moderate for designers and reviewers, who must internalise the appearance ramp and motion tokens to review against intent. Highest for QA, who now own visual regression across two themes, reduced-motion, keyboard navigation on five new canvas widgets, and the popup/toast timing changes. Plan roughly a sprint of enablement — one integration spike, one theming pass, and a screenshot baseline — before treating the kit as a standard dependency.