Weave Code
Blade Laravel Package
lyra-ds/blade
Lyra DS Blade offers reusable Laravel Blade components for building consistent, accessible interfaces with the Lyra design system. Compose layouts, forms, and UI elements faster without repeating markup.
Blade components for the Lyra Design System — exact class parity with @lyra-ds/react
Frequently asked questions about Blade
- How do I install lyra-ds/blade in a Laravel application?
- Install the PHP package with composer require lyra-ds/blade, then add the matching front-end packages @lyra-ds/alpine ^1.1 and @lyra-ds/styles ^1.1 via npm. Because the components are server-rendered Blade with Alpine-driven behavior, you also need an asset pipeline such as Vite or Mix to compile and serve the styles and JavaScript. There are no database migrations or service-provider changes indicated, so the integration work is markup, CSS, and event contracts rather than PHP wiring.
- Which Laravel and PHP versions does lyra-ds/blade support?
- The package is a Blade component library rather than a service-provider package, so it depends on Blade features available in your Laravel release. The release notes do not enumerate supported Laravel or PHP ranges, so check the require block in the package composer.json before upgrading. Test the component markup on your target Laravel version, since the v1.0.0 changes are DOM and Alpine contracts, not PHP APIs.
- Do I need @lyra-ds/alpine and @lyra-ds/styles installed for the components to work?
- Yes. lyra-ds/blade has a hard runtime coupling to @lyra-ds/alpine ^1.1 and @lyra-ds/styles ^1.1, so the Composer package alone will not render a working interface. Adopting v1.0.0 means a coordinated three-artifact upgrade across Composer and npm rather than a standalone PHP bump. Plan the version alignment first, then upgrade the Blade package.
- What breaks when upgrading lyra-ds/blade to v1.0.0?
- v1.0.0 is a DOM-contract release, not a PHP-API release: breaking changes show up in markup, ARIA attributes, CSS selectors, and JavaScript events. Expect changes to toast roles, tablist ids, workspace switcher listbox semantics, breadcrumb anchors, and the container max keyword behavior. Treat the upgrade as a front-end migration with a Composer bump attached, and diff rendered output before estimating scope.
- Why do Lyra tabs render as an empty shell after upgrading?
- The tabs tablist ships hidden and carries no static role or aria-selected attribute, so it depends on Alpine to initialize the interactive shell. If @lyra-ds/alpine ^1.1 is missing, misconfigured, or the asset pipeline is not loading it, tabs fail silently instead of degrading visibly. Verify Alpine is registered and that your compiled bundle includes the Lyra Alpine package before debugging the component itself.
- How do I update Dusk or Playwright tests after upgrading lyra-ds/blade?
- Browser tests and custom CSS are the primary blast radius because selectors such as button.lyra-sbgroup__item, role=status toast rows, and the workspace switcher listbox semantics have changed. Run the upgrade in a branch, diff the rendered DOM, and update selectors and tab-order assertions before merging. Secondary components like data-table, date-range-picker, dropdown, and tooltip also changed at a level the notes only describe by headline, so budget discovery time rather than assuming no impact.
- What happened to the lyra:change event in the workspace switcher?
- Workspace switcher items are now real anchors that navigate natively instead of dispatching a lyra:change event. Any integration that intercepted that event, such as analytics, unsaved-changes guards, or SPA-style routing, will quietly stop firing. Audit those listeners and replace them with anchor navigation handling or your own wrapper logic.
- How do I share state across Lyra components now that Alpine x-data is owned by each component?
- v1.0.0 formalizes an owned-root policy: Alpine-bound components own their x-data and no longer forward consumer state. The escape hatch teams used for cross-component coordination is gone, so wrap the components in your own div with x-data and coordinate through that parent scope. This is a cleaner contract but requires updating any markup that previously passed state straight into a component.
- How do I pin Lyra DS styles if I vendor compiled CSS or use a CDN?
- Applications that vendor the compiled stylesheet or load styles from a CDN must pin @lyra-ds/styles explicitly to ^1.1 rather than floating on latest. The Blade components assume matching class names and selectors from that styles release, so a version mismatch produces visual drift that looks like a component bug. Pin the npm package, rebuild assets, and record the version alongside the Composer dependency.
- Is lyra-ds/blade accessible enough to pass a procurement or audit review?
- Accessibility improved materially in v1.0.0: overlay components restore focus, toasts use a live-region split, the workspace switcher gets disclosure semantics, navigation uses real anchors, and a skip link plus focusable main element were added. Tooltip descriptions are focusable and data-table and date-range-picker received a11y work. That is a net positive for audit review, but the changes also shift DOM contracts and tab order, so retest keyboard flows in your own app.
Weaver
How can I help you explore Laravel packages today?