- How do I install hungnm28/livewire-form in a Laravel app?
- Run composer require hungnm28/livewire-form. Laravel auto-discovers the service provider, which registers anonymous Blade components under the lf:: prefix. You can then use components such as <x-lf::form.input name="email" label="Email" /> right away, provided PHP 8.3+, Laravel 10-13, Livewire 3/4, Tailwind, and Alpine are already present in the host app.
- Which Laravel and Livewire versions does this package support?
- It requires PHP 8.3 or newer, Laravel 10, 11, 12, or 13, and Livewire 3 or 4. These are hard prerequisites rather than a graceful degradation curve, so partial compliance typically means a non-working install. Tailwind CSS and Alpine.js must also be available in the host application.
- Why are my livewire-form components rendering unstyled in production?
- The usual cause is that your Tailwind content paths do not include vendor/hungnm28/livewire-form/resources/views/**/*.blade.php, so the component classes get purged in the production build. Add that glob to tailwind.config.js and rebuild your assets. This can also break in CI pipelines where vendor/ is installed after the asset build step.
- Do I need Tailwind and Alpine.js to use these Blade components?
- Yes. The components are styled with Tailwind utilities and expect a primary-* color palette to be defined or mapped in your theme. Alpine.js powers modals, asides, fullscreen toggling, and theme cycling. Livewire ships Alpine in the common setup, but if you override Livewire's frontend assets you must make sure Alpine stays available.
- How do I publish the config, views, and assets for livewire-form?
- Use php artisan vendor:publish with the tags livewire-form-config, livewire-form-views, or livewire-form-assets. Assets publish to resources/js/vendor/livewire-form, which you then import from your app entrypoint. Publishing views lets you override markup, but remember you are then maintaining a fork of those templates across upgrades.
- What components does hungnm28/livewire-form actually provide?
- It ships form inputs (input, select, textarea, checkbox, toggle), buttons, modals, asides, a layout shell, and a theme setting component, all under the lf:: prefix. There is also table chrome and theme-switching support. These are anonymous Blade components with no backing PHP classes, so they carry markup and styling rather than behavior.
- Does this package handle form validation and submission?
- No. State, validation, submission, authorization, and error rendering all stay in your Livewire component or application code. The package is a view-layer veneer for markup and styling, so any claim about faster form development should be scoped to templates, not form logic.
- Can I self-host Tabler Icons instead of loading them from the CDN?
- By default the icon components load the Tabler Icons webfont from a CDN, which is an external runtime dependency and a CSP and privacy review item. Set use_cdn_icons to false in the published config and host the webfont yourself if you need offline support or a strict content security policy. Confirm the approach with your security team before rollout.
- Is hungnm28/livewire-form actively maintained and production ready?
- The package has 0 stars and 0 dependents, so there is no ecosystem validation or public record of anyone running it in production. Release notes carry version numbers with no changelog content, which makes upgrade cost hard to estimate, and the published API keeps the form.toogle and theme.toogle typos for backwards compatibility. Treat your team as the first substantive adopter and pin versions deliberately.
- How should I test components built with livewire-form?
- Because the components are anonymous Blade templates with no PHP classes, there is no type surface and a misspelled prop fails silently at render time instead of erroring. Plan for visual or Dusk-style tests rather than unit tests. Add a visual regression check that covers the styled versus purged-CSS state of your production build.