Ux Common Laravel Package

Product Decisions This Supports

• Build vs. buy for the shared UI layer. This package is best read as a reference implementation of how one team factored common UX files out of a family of apps into a sibling repository — not as a product to adopt. The decision it informs is whether we build our own shared Blade/component package or lift conventions from someone else's. Given the signals here, the answer is build our own.
• Whether a shared design-system package belongs on the roadmap at all. Zero stars, zero dependents, and a score of 0 mean there is no ecosystem validation. If we want a shared component library, this package does not de-risk that bet; it only demonstrates a repo-layout pattern (ux-common as a sibling to app repos) that we can replicate in a private Composer package on our own release cadence.
• Documentation-trust and vendor-risk triage. The package metadata is internally inconsistent: the repo name and multiple evaluations describe Symfony UX (Twig, Stimulus, bundles), while the package description claims a Laravel/Blade foundation. That contradiction is itself a PM-relevant finding — it means we cannot rely on the docs to scope integration work, and any adoption estimate is speculative until the tarball is inspected. Roadmap implication: budget a read-only spike, not integration time.
• Framework-fit filtering. If the payload is genuinely Symfony UX, it is out of scope for a Laravel roadmap item as a dependency. The only plausibly portable slice is framework-agnostic front-end assets (Stimulus controllers, CSS/tokens), which is a vendoring decision, not an adoption decision.
• Use cases where it could genuinely help: standardizing base templates, asset conventions, and Stimulus controllers across multiple first-party Symfony apps; giving a new Symfony UX app a "copy this layout" starting point; serving as a structural reference before we design our own shared UI package.

Bottom line: low-signal, likely-internal artifact with conflicting documentation. The defensible PM decision is "monitor / reference only, do not adopt" — unless we are running a multi-app Symfony UX estate, in which case the value is in the pattern, not the code.

When to Consider This Package

Consider it when:

• You are running multiple Symfony UX applications under one org and are duplicating base templates, Stimulus controllers, or asset configuration across repos. The "extract common files into a shared package" structure is exactly the problem shape this solves.
• You are already a Symfony shop (Twig, Symfony UX, AssetMapper/Encore) and want a structural reference for naming and repo layout before building your own internal shared UI package.
• You are willing to treat it as read-only inspiration — no support contract, no changelog guarantees, no expectation of upstream fixes, and a willingness to own any copied code as a permanent fork.
• You have confirmed the license permits internal reuse and verified what is actually inside (assets vs. Twig templates vs. bundle wiring) — the description alone is not sufficient to size the work.

Look elsewhere when:

• You are on Laravel (the stated stack for this evaluation). Prefer Laravel-native options: Blade UI Kit, Flux/TallStack UI, Livewire component libraries, or a small first-party Blade component package with our own versioning. Even 20–40% reuse of front-end assets rarely justifies the Twig-to-Blade port and the ongoing drift.
• You need documentation, versioning discipline, security responsiveness, or a support path. Zero stars and zero dependents mean no community triage and no blast-radius evidence either way; transitive dependency CVEs in an unwatched package are a real risk.
• You need anything maintained by a third party you don't control. A package described as "common files for [Org] projects" is typically published for that org's CI convenience, not for external consumers; expect no semver contract and a single-maintainer bus factor.
• You are doing production due diligence. The cost of vetting and porting likely exceeds the cost of writing equivalent shared files ourselves.
• You require license clarity and provenance, or need to confirm whether "common files" embed Krystal-specific infrastructure assumptions (hosting, asset hosts, auth) before any reuse.

How to Pitch It (Stakeholders)

For executives (30 seconds): We evaluated krystal-sf/ux-common, a small shared-files package published for one company's own app family. It has no adoption, no community, no documentation, and its own description contradicts the repo's actual framework target (Symfony UX vs. Laravel/Blade). Recommendation: do not adopt. The only value is as a structural reference if we ever commit to a shared front-end component library across multiple apps — and at that point we build our own. Cost avoided: integration and vetting time with no offsetting benefit.

For engineering (detail):

• It's a shared-code extraction pattern, not a framework or a component library. Expect base templates, Stimulus/asset conventions, and org-specific glue — not reusable UI components. Verify by inspecting the tarball; the description is not reliable enough to scope from.
• Stack mismatch: the package targets Symfony UX (Twig, bundles, Stimulus/Turbo) while we ship Laravel (Blade, Livewire/Alpine, Vite). The portable slice is likely the framework-agnostic front-end assets; the Twig component and bundle wiring is not. If Turbo is in the payload, decide up front whether we are a Turbo shop or a Livewire shop — running both produces intermittent navigation and morphing bugs.
• Zero maintenance signals: 0 stars, 0 dependents, terse and contradictory description. No changelog, no visible tests, no consumer base to catch regressions. Treat any reuse as a fork we own outright, pinned to a commit hash for provenance.
• If we pursue a shared UI package, the takeaway to steal is the architecture: one common package consumed by N app repos, with app-specific overrides layered on top. We can implement that internally in Laravel with a private Composer package and Blade components in days, on our own release cadence, with our own docs and owner.
• Proposed next step — one-week, timeboxed, read-only spike, one named owner, hard decision gate before any code enters a production Laravel codebase: (1) pull and classify contents into portable / translatable / discard; (2) confirm license and Krystal-specific assumptions with legal; (3) port one representative Stimulus controller into a real Laravel + Blade + Vite app; (4) compare against our existing design system and decide borrow-vs-build.

Recommended status: Not adopted — logged as a pattern reference. Revisit only if we commit to a multi-app shared UI strategy, and even then, build internally.