# BladewindUI: a Laravel component library where every component is its own package > BladewindUI is an open source UI component library for Laravel and Tailwind that ships each component, and each group of components, as its own Composer package, so an application installs only the parts it uses and then publishes the assets with artisan. It suits a Laravel team that wants a consistent admin interface, and it does not suit a project outside Blade. **bladewindui/ui** — BladewindUI is an open-source UI component library focused on helping developers build clean, modern, and responsive web applications faster. It provides a growing collection of thoughtfully designed, customizable components that are simple to integrate and easy to use. - Repository: https://github.com/bladewindui/ui - Website: https://bladewindui.com - Stars: 692 · Forks: 66 - Language: JavaScript - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/bladewindui-ui ## A component library that ships in pieces BladewindUI is described as a modern, open source UI component library for building beautiful, consistent and responsive web interfaces faster, with a growing collection of components that are simple to integrate, easy to use, and flexible enough for dashboards, internal tools and full web applications. Every component ships with sensible defaults you can override per project. The unusual decision, and the one that defines the library, is at the packaging level. Every component is its own Composer package. There is a package for the button, a package for the table, a package for the datepicker, and a package for each logical group of components, plus a whole library package that pulls in everything. The motivation is straightforward. A Laravel application that needs a modal and a datepicker should not have to install a full admin template, and should not have to take every component upgrade when it takes one. The README puts it as shared dependencies such as the icon, script and spinner packages being pulled in automatically via Composer's dependency resolution, so the unit of installation is the component, not the library. That choice has consequences in both directions. You get a small dependency footprint and per component upgrades, and in exchange you get a tree of packages that has to be understood before you can predict what a version bump will do to a page. ## Three ways to install, from the whole library to one table The installation section gives three entry points, and the choice between them is a decision about how much of the library you want to own. Install everything, which the documentation calls the recommended starting point, pulls in all components: ```bash composer require bladewindui/ui ``` Install a component group when you only need a subset. Each logical group is available as its own package: ```bash composer require bladewindui/forms # all form components composer require bladewindui/content # all content & display components composer require bladewindui/navigation # all navigation components ``` And install a single component, since every component is its own Composer package: ```bash composer require bladewindui/table composer require bladewindui/accordion composer require bladewindui/datepicker ``` The documentation recommends starting with everything, and that is a reasonable default for a team that does not yet know which components it will use, because the shared dependencies are resolved for you and there is nothing to think about. Moving to groups or single packages later is a matter of removing the umbrella package and adding what you actually render. The comment in the group example is worth noting, since it is a genuine trade. The group packages are convenience bundles, so choosing one of them means accepting a set of components you may not use, while a single component package means you keep a list of dependencies in your composer.json that grows with every new component on a page. ## Publishing the assets and putting them in your layout After installing, the compiled CSS, JavaScript and language files have to be published into your project, which is two artisan commands: ```bash php artisan vendor:publish --tag=bladewind-public --force php artisan vendor:publish --tag=bladewind-lang --force ``` The public tag brings over the compiled stylesheet and the helper script, and the lang tag brings the language files. The stylesheet goes in the head of your layout, and the JavaScript goes before the closing body tag: ```html ``` ```html ``` After that a component is a Blade tag with a namespaced name: ```html Save User ``` The full installation guide is linked from bladewindui.com/install. The two publish commands are the part to get right, because the library ships compiled assets rather than asking your application to compile the library CSS, which is why the publish step exists at all. ## The standalone packages and what the groups add Components are organised into groups, and each group maps directly to a Composer package. A set of components sits outside any group because other components depend on them: Button, Modal, Alert, Bell, Notification, Table, Data Grid, Calendar and Spinner. The core package holds the shared helpers, the CSS variables and helpers.js, and the icon package is an SVG icon wrapper built on Heroicons. The modal package carries both the modal and the modal icon variant, the button package carries the button and the circle button, the spinner package covers spinner, shimmer, processing and process complete, and the table package covers the table and its icons. Data Grid and Calendar are separate packages of their own. The forms group is the larger one, and it shows how much of the library is form surface: checkbox, checkcards, colorpicker, datepicker, filepicker, which is powered by FilePond, file preview, input, which also provides the error component, inline edit, the number stepper, currency input, a password strength meter, the radio button, select with its select item variant, and the slider. The groups, forms, content and navigation, mirror the way an application is laid out. That is a sensible organisation, and it is also the reason the library works well for the dashboards and internal tools it targets, where a screen is mostly a form, a table and a set of buttons. ## The JavaScript side is a Tailwind v4 and Vite build with hardened CSS The root package.json is the interesting part of the repository, because it is the tooling for the library itself rather than for an application using it. It is a private package named bladewindui, and the scripts cover the whole loop. The dev script runs vite, the build script runs vite build and then node bin/harden-css.mjs, and there are watch and preview variants. The test scripts are two: test:js runs node bin/smoke-helpers.mjs, and test:e2e runs vendor/bin/phpunit --testsuite=fixtures and then playwright test. That last one is the detail that says something about the project. The end to end suite runs a PHP test suite and then a Playwright suite, so the library is checked at two levels, the server rendered output and the browser behaviour of the JavaScript components. The build step that hardens the CSS after the Vite build is a deliberate extra stage, and the repository root has three Tailwind entry points, tailwind.css, tailwind-shared.css and tailwind-no-preflight.css, which is how a component library deals with the preflight styles that would otherwise fight an application's own CSS. The dev dependencies are modest: Tailwind CSS v4 with the Vite plugin and the forms plugin, Vite 6, and Playwright. The PHP side has its own phpunit.xml and playwright.config.mjs at the root. The rest of the tree supports the packaging: packages/ holds the individual component packages, src/ the source, config/ the configuration, lang/ the translations, bin/ the scripts, and monorepo-builder.php, which is how a repository of many Composer packages is assembled. ## What BladewindUI is for, and what it is not for The honest scope statement is that this is a Laravel library. The components are Blade components used through the x-bladewind namespace, they are installed with Composer, they are published with artisan, and they render on the server with Tailwind classes for the styling and a small helper script for the interactive parts. That design has a strength and a limit, and they are the same thing. The strength is that the component and the application share a language. A Blade component is readable in the same file as the controller that feeds it, the markup is server rendered, and the JavaScript that is shipped is a helper rather than a framework you have to learn. For an internal tool or an admin area, that is exactly what you want. The limit is the same thing seen from the other side. A rich interactive grid or a datepicker is a component whose behaviour lives in JavaScript, and a component library that renders server side but ships behaviour in a helper file gives you less control over that behaviour than a front end framework with its own component model. If the product you are building is an application rather than a back office, that trade is worth reconsidering. The alternative worth naming is not another component library but plain Blade with Tailwind. You write your own components, you keep full control of the markup and the behaviour, and you take on the cost of a consistent set of components that somebody else maintains. The second alternative is architectural. If you serve a JSON API to a separate front end, the whole Blade approach disappears, because there is no server rendered markup to style. For a team that has already decided on a separated front end, no amount of BladewindUI helps. ## Maintenance, versioning and the licence The project is not archived, and the last push was on 2026-10-18. The release history shows a major version in flight: v5.0.0 on 2026-08-31, v5.1.0 on 2026-09-13, and 4.3.0 on 2026-08-10 just before the major bump. That v5.0.0 release is the thing to plan around, because with every component being its own package, a major version can land in one component while others stay on the old line. Nothing in the documentation promises a synchronised release across the tree, so a team that wants a consistent upgrade has to track the packages itself. The repository helps in two ways, with a COMPONENT_BACKLOG.md that shows what is planned and a RELEASING.md that documents the release process. The licence is MIT, which is the permissive end of the scale for a component library and removes most of the friction in commercial use. The topics list includes hacktoberfest, which tells you the project takes outside contributions, and the ecosystem tags confirm the stack: laravel, php, blade, tailwindcss and css. For a project whose components end up in every page of an application, the practical questions to settle early are the version policy across the packages, and how you intend to track a component that quietly depends on a newer version of the core package. ## Conclusion Adopt BladewindUI if you build Laravel applications with Blade and Tailwind and want a maintained set of admin interface components that you can install one at a time and override per project. Do not adopt it for a non Laravel stack, a front end heavy product, or a team that wants one upgrade to move every component at once. Verify first that the components you need exist as packages, since each is published separately, that the Tailwind version in your application matches what the library expects, and that the artisan publish tags bladewind-public and bladewind-lang are available in your setup before you start customising anything. ## FAQ ### How do I install BladewindUI in a Laravel project? Run composer require bladewindui/ui to pull in everything, or install a group such as bladewindui/forms, bladewindui/content or bladewindui/navigation, or a single component package such as bladewindui/table. Shared dependencies are pulled in automatically through Composer's dependency resolution. ### How do I publish the BladewindUI assets and use a component? Run php artisan vendor:publish --tag=bladewind-public --force and php artisan vendor:publish --tag=bladewind-lang --force, add the published stylesheet to the head of your layout and helpers.js before the closing body tag, then use a Blade tag such as Save User. ### Which components does BladewindUI provide? Standalone packages cover core, icon, alert, bell, button, modal, drawer, notification, spinner, table, data grid and calendar, and the forms group adds checkbox, checkcards, colorpicker, datepicker, filepicker, file preview, input, inline edit, number, currency input, password meter, radio button, select and slider. ### Does BladewindUI work outside Laravel? No. The components are Blade components installed with Composer and published with artisan, and the styling comes from Tailwind. A project that serves a JSON API to a separate front end has no server rendered markup for the library to style. ### What licence is BladewindUI released under and how often does it update? MIT. The repository is not archived and the last push was on 2026-10-18, with v5.1.0 published on 2026-09-13 after v5.0.0 on 2026-08-31, and a COMPONENT_BACKLOG.md and RELEASING.md in the tree to track planned components and the release process. ## Sources - [bladewindui/ui on GitHub](https://github.com/bladewindui/ui) - [License: MIT](https://github.com/bladewindui/ui/blob/main/LICENSE) - [Project website](https://bladewindui.com) - [README](https://github.com/bladewindui/ui/blob/main/README.md) - [Releases](https://github.com/bladewindui/ui/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bladewindui-ui