- Does krystal-sf/ux-common work with Laravel?
- Not natively. The package is a shared artifact for Krystal's Symfony UX applications: it assumes Twig templates, Symfony bundles and DI configuration, and Turbo/Stimulus for the front end. Laravel uses Blade, service providers, Livewire or Alpine, and Vite, so the two rendering contracts do not line up. Treat it as a framework-bound artifact rather than a portable utility, and do not plan a Twig-to-Blade adapter layer to bridge the gap.
- Can I composer require krystal-sf/ux-common in a Laravel project?
- Composer may resolve and install it, but it drags in symfony/framework-bundle, twig/twig and symfony/ux-* transitive dependencies alongside the container, view engine and asset pipeline Laravel already ships. That is redundant surface area at best and a dependency conflict at worst, with no offsetting benefit. If you only want the front-end pieces, vendor the JS and CSS instead of adding the dependency.
- How do I use the Stimulus controllers and CSS from krystal-sf/ux-common in a Laravel app?
- Copy the Stimulus controllers and stylesheets out of the package tarball into resources/js and resources/css under your own Vite build and versioning. Pin the upstream commit hash in your repository README purely for provenance so future maintainers can diff against it. This is a fork-and-own decision and should be scoped and staffed as one, not ticketed as a simple dependency addition.
- Can I convert the Twig components in krystal-sf/ux-common to Blade?
- You can translate them one to one, but only for components that genuinely earn their keep in your UI. Twig templates, PHP view models, the bundle class, DI extension and Symfony event subscribers are non-portable glue that should be discarded rather than ported. A permanent Twig-to-Blade adapter is a maintenance tax with no product payoff, so rebuild the portable slice directly in Blade instead.
- Is krystal-sf/ux-common safe to use in production?
- The technical risk is high, driven by maturity signals: zero stars, zero dependents, an intentionally terse description and no observable release cadence. That profile suggests an internal extraction published for the maintaining organisation's CI convenience, so assume no semver contract, no documented public API, no deprecation policy and a single-maintainer bus factor. Fork it into a private repository you control rather than depending on it live.
- Does krystal-sf/ux-common conflict with Livewire or Alpine.js?
- There is no hard runtime conflict by default, but Turbo's navigation model overlaps with Livewire's SPA-style navigation. Running both tends to produce intermittent, hard-to-reproduce UI defects that are expensive to diagnose. In a Laravel app, Alpine and Livewire already cover the interaction patterns these controllers provide, so the safer choice is to skip Turbo entirely.
- What PHP, Symfony and Twig versions does krystal-sf/ux-common require?
- The published constraints are not documented in the description, so check composer.json in the tarball before writing any code. Verify the pinned PHP, Symfony, Twig and Stimulus versions and confirm none of them collide with your Laravel version or existing front-end toolchain. With no tagged releases it is also worth confirming whether the world is consuming dev-main rather than a stable branch.
- Is krystal-sf/ux-common actively maintained?
- There is no observable release cadence, no deprecation policy and no documented security response process, and the repository sits at zero stars and zero dependents. Assume it is maintained only as far as Krystal's own applications need it. Before committing, ask whether they will accept upstream patches or whether you are signing up for a permanent internal fork.
- What is the license for krystal-sf/ux-common and can we fork it?
- The license is not stated in the available overview, so confirm it directly in the repository before any engineering spend. You need explicit permission to fork, modify and redistribute it internally, especially if the fork will be consumed by multiple teams. Put that answer in writing alongside the fork's README and upstream commit hash.
- What are the best alternatives to krystal-sf/ux-common for Laravel UX primitives?
- First check whether your organisation already has a design system or component package that makes this redundant before spending a day on it. Within the Laravel ecosystem, Blade components, Livewire, Alpine.js and a Tailwind-based token set cover the same feedback, layout and interaction patterns with first-class framework support. Those give you accessibility conventions, documented APIs and an actual release cadence without a fork obligation.