Ux Filemanager Laravel Package

Technical Evaluation

Delta in 0.1.7. The release adds Symfony 8 and PHP 8.5 support (feat: Symfony 8 + PHP 8.5 support). It is a compatibility-window release — no new features, no security fix, no API change called out. It does not alter the core finding: mezcalito/ux-filemanager is a Symfony UX bundle, not a Laravel package. It sharpens three details that matter to us: the PHP floor, the Symfony component alignment, and how far the frontend glue has drifted from Laravel conventions.

Architecture fit — the headline risk, unchanged. The package's value is split across two layers with very different portability:

• Backend layer (file listing, upload, delete, path resolution, Flysystem-backed storage) — conceptually portable. Laravel's Storage facade is itself a Flysystem v3 wrapper, so the domain problem is shared.
• Presentation layer (Twig components, Stimulus controllers, Symfony UX Turbo/AssetMapper conventions) — not portable. Laravel has no Twig rendering pipeline, no Symfony DI extension loading, and no native Stimulus integration. Blade + Vite + Alpine/Livewire is a different mental model. Targeting Symfony 8 moves this layer further from our stack, not closer — the 8.x line is where Symfony UX's AssetMapper and Turbo conventions are most opinionated.

Net: what you'd actually reuse is a few hundred lines of service logic and a set of UI patterns — not the package as shipped.

Integration feasibility. Three viable paths, in descending order of effort:

1. Sidecar service. Stand up a small Symfony app hosting the bundle, expose a thin internal HTTP API, consume from Laravel. Clean isolation, but you now operate two runtimes, two deploy pipelines, and a cross-service auth boundary — a heavy tax for a file browser. Note 0.1.7 makes the sidecar marginally more attractive in one narrow sense: it is now a supported, current Symfony target. Still not worth the operational tax.
2. Port into Laravel. Lift the service/domain classes, re-home under app/Services, re-implement templates in Blade, and pull the Stimulus controllers into the Vite build (Stimulus works fine under Vite; it's Twig that doesn't). This is a fork, not an install. New wrinkle: code shaped for PHP 8.5 may use syntax (property hooks, asymmetric visibility, newer typed-constant idioms) our runtime can't parse — downleveling is now a line item.
3. Reference implementation. Read it for UX and edge-case handling, build native. Often the right call at 22 stars, and 0.1.7 does not change that math.

Technical risk. Several compounding signals, one of them newly sharpened:

• 0 dependents / 22 stars — no downstream production validation to lean on. You would be the most serious consumer.
• Opportunity score 16.21 — low; treat as "niche utility," not a strategic dependency.
• Effective bus factor 1 — single-vendor (Mezcalito), single contributor on the release. 0.1.7 is genuine evidence of life, which is the one risk it reduces.
• Still pre-1.0 (0.1.7) — no semver stability contract. Symfony 8 support arriving before a 1.0 tag tells you the API is still fluid and breaking changes ship in patch releases.
• Widening gap to Laravel's Symfony components — Laravel 12 ships the Symfony 7.x line. A package pinning Symfony 8 components would be literally unresolvable alongside a current Laravel app in the same composer.json. This is a fork-and-extract package either way, but it removes any residual "just try composer require and see" option.
• Silent breakage surface — Symfony UX and Stimulus conventions shift between minor versions; asset mapper assumptions are implicit and undocumented for non-Symfony hosts. The 8.x jump is exactly the kind of move that invalidates copied Stimulus DOM contracts.
• Security-sensitive domain — file upload/browse handlers carry path traversal, MIME sniffing, and arbitrary-write risk. 0.1.7 contains no security fix, so the upload validation path remains unaudited.

Key questions before committing:

• Does 0.1.7 pin Symfony 8 only, or widen to ^7.0|^8.0? A narrow pin confirms it can never co-exist with Laravel's dependency graph; a wide constraint keeps the sidecar path cheap and makes the extracted code easier to read.
• What PHP floor and composer.json require set does 0.1.7 declare? If it's >=8.4, assume 8.4/8.5 syntax in the domain classes and budget a downlevel pass.
• Did 0.1.7 drop Symfony 6/7 and older PHP from the matrix? That's a de facto breaking change for the code you'd fork, and it means the branch you read is the only maintained one.
• Is the storage layer abstracted behind an interface (swap-in for Laravel's Storage), or hard-wired to a Symfony Flysystem service?
• Does the bundle ship the JS as a prebuilt asset, or require AssetMapper? Prebuilt widens the port path considerably.
• What's the actual LOC of domain logic vs. Twig/Stimulus glue? If it's 80/20 toward glue, path 3 wins immediately.
• Has anyone audited the upload validation path? (0.1.7 says nothing about it.)

Integration Approach

Stack fit. The genuine overlap is at storage: Laravel Storage → Flysystem 3 → local/S3. If the package's file operations sit on an injectable filesystem interface, a Laravel adapter is a bounded task. The UI layer has no overlap — plan for a full rebuild in Blade + Vite, reusing the Stimulus controllers only if their DOM contracts are clean. Treat 0.1.7's Symfony 8 alignment as a signal that those contracts are still moving.

Migration path. Realistically: extract, don't install. 0.1.7 reinforces this — with a Symfony 8 pin, composer require into a Laravel app is not merely unwise, it likely won't resolve.

1. Vendor or fork the package read-only; do not add it to composer.json in a Laravel app.
2. Pin your read to the 0.1.7 tag (the Symfony 8 / PHP 8.5 line), and record the tag in the ADR so future readers know which branch the extraction came from.
3. Map the domain services onto Laravel contracts — Storage, Validator, Gate/Policy for per-file authorization.
4. Rewrite routes onto Laravel controllers; replace Symfony DI wiring with a service provider.
5. Downlevel any PHP 8.4/8.5 syntax to the runtime we actually ship on — small but non-zero, and easy to underestimate in a spike estimate.
6. Rebuild views in Blade; keep Stimulus via Vite if the controllers are self-contained, otherwise Alpine.
7. Add the security layer the package almost certainly lacks: path canonicalization, extension + MIME allowlists, per-user quota, signed URLs for delivery.

Compatibility. Expect friction at the container boundary — Symfony bundle Extension classes and services.yaml don't load under Laravel's container. 0.1.7 makes version alignment the first thing to check, not the last: confirm the PHP floor against your runtime and confirm whether the package assumes symfony/ux-turbo at the HTTP layer (it may return Turbo Stream responses, which your Laravel endpoints won't produce without work).

Sequencing.

1. Spike (2–3 days): read composer.json, service definitions, and the upload handler at tag 0.1.7. Produce an LOC-split estimate and an 8.4+/8.5-syntax inventory.
2. Go/no-go: if domain logic is thin, pivot to native build and stop.
3. PoC: one vertical slice — list + upload + delete against Storage::disk('s3') behind a Laravel policy.
4. Harden: validation, quotas, audit trail.
5. UI: Blade rebuild, only after the backend slice is proven.

Do not sequence UI first; the tempting demo is the part you'll throw away. The 2–3 day spike estimate holds — reading composer.json is now a slightly higher-value first step than before.

Operational Impact

Maintenance. Assume you own the code the moment you integrate. With zero dependents and effectively one contributor, upstream fixes are best-effort — though 0.1.7 is a fair signal the maintainer intends to track modern Symfony/PHP, which reduces abandonment risk without eliminating it. Budget for a fork you periodically rebase — or better, budget for a permanent divergence where you stop tracking upstream entirely. The 0.1.7 constraint bump is the kind of change that creates merge pain on rebase for zero functional gain on our side; that argues for divergence. Either way, name an owner.

Support. MIT, community-only, no SLA, no commercial backing. Acceptable for internal tooling; a poor fit for anything customer-facing where a broken upload is a revenue event. The 8.x alignment is a maintenance signal, not a support commitment — don't read it as one.

Scaling. Unchanged, and unaffected by the release — file management scales with the storage backend, not the package:

• Upload throughput is bounded by PHP upload_max_filesize / post_max_size and request timeouts — plan direct-to-S3 presigned uploads rather than proxying bytes through PHP-FPM.
• Listing large directories is the classic failure point; confirm pagination exists or add it.
• Thumbnail/preview generation is CPU-bound and belongs in a queue, not the request cycle.

Failure modes to instrument explicitly:

• Path traversal / arbitrary write — canonicalize and reject .. after resolution, not before. Still unaudited in 0.1.7.
• MIME spoofing — trust content sniffing, not Content-Type or extension alone.
• Orphaned objects — deletes that succeed in DB but fail in storage (or vice versa); needs reconciliation.
• Quota exhaustion — no per-tenant limit means one user fills the bucket.
• Silent asset breakage — if you port Stimulus controllers, a Vite config change can kill the UI with no server-side error. Higher risk if you copy controllers written against Symfony 8 UX conventions.
• Downlevel drift — extracted code silently diverging from upstream because it was back-ported to an older PHP; document the mapping.

Ramp-up. Two audiences, two costs:

• Backend devs — low cost; the file operations are familiar Laravel/Flysystem work. Add a small allowance for reading Symfony 8-era PHP.
• Frontend devs — moderate to high. Symfony UX/Stimulus conventions are learnable but unfamiliar to a Laravel-only team, and the package's templates encode assumptions that won't survive translation. 0.1.7 does not narrow this gap; if anything the Symfony 8 UI conventions are a moving target. Keep the 20–30% buffer on the first integration.

Verdict. Not an installable dependency for a Laravel stack — it's a reference implementation and partial extraction source. 0.1.7 is a positive maintenance signal and a negative integration signal: it confirms the project is alive while pushing its compatibility window (Symfony 8, PHP 8.5) further from a current Laravel app. Worth a bounded 2–3 day spike given the overlap at the Flysystem layer and the security-checklist value of reading a working implementation. Not worth a sidecar service. Recommend: spike at tag 0.1.7, then very likely build native with this as a spec.