Filechunk Bundle Laravel Package

Product Decisions This Supports

• Feature scoping: chunked/resumable uploads. The underlying capability — splitting large files into chunks and reassembling server-side — is a real roadmap item for any product handling media, video, CAD, datasets, or large PDFs. This package remains a reference implementation of that feature (JS widget + Symfony form type), useful for sizing the work even if the package itself isn't adopted. The new directory listing capability extends the reference model into post-upload browsing, which is a second, separable feature decision: upload transport vs. file-management UI.
• Build vs. buy vs. borrow. The assessment outcome is still "borrow the idea, not the code" — but the shelf life of that verdict is now shorter. A 2.0 line in active alpha means the package is no longer a dead artifact; it is an in-progress rewrite. Borrowing the design is safer than adopting the alpha, and re-evaluating at 2.0 stable is a legitimate roadmap checkpoint rather than a dead end.
• Risk review for existing Symfony estates. Dependency-audit triage changes character: "unmaintained since 2019" was a simple rejection; a 2.0.0-alpha11 is an open, unstable development branch. Alpha software in a production dependency graph is a separate, equally firm rejection, and upgrading 1.x → 2.0 will be a breaking migration rather than a no-op.
• Security review input for file-management features. "Directory listing" is a server-side browsing surface. Any team scoping a file browser should treat path traversal, symlink following, authorization scoping, and enumeration/disclosure as design requirements, not implementation details. This release is useful as a prompt for that threat model regardless of adoption.
• Buy-in framing for engineering. Still concretely answers "why don't we just drop in the library?" with licensing, framework-fit, and release-stability evidence rather than opinion — now with the added nuance that "it's abandoned" is no longer the strongest argument, so the argument must rest on licensing, stack fit, and alpha stability.
• Not a decision input for Laravel products. The package is a Symfony bundle with a Symfony form type; Laravel has no Symfony Form component, so there is no drop-in path. The 2.0 alpha does not change this. Treat Laravel adoption as closed and move to alternatives (Uppy, FilePond, tus, or native S3 multipart).

When to Consider This Package

Consider it only under a narrow set of conditions:

• You are on an existing Symfony application (not Laravel, not framework-agnostic PHP) with a legacy constraint that makes a full front-end upload rewrite expensive right now.
• The project is internal or otherwise GPL-compatible — copyleft obligations are a hard blocker for proprietary or SaaS products that cannot redistribute source, so legal sign-off is a prerequisite, not a formality.
• You are explicitly willing to track a pre-release branch or vendor/fork the code and own it. 2.0.0-alpha11 is an alpha: no backward-compatibility guarantee between alphas, no stability commitment, and an implied breaking change from any 1.x usage. Pin nothing you can't patch.
• You have verified PHP 8.x / current Symfony compatibility yourself, against the 2.0 branch specifically — assume the 1.x line is unverified on modern runtimes.
• Conditional, forward-looking: you have a Symfony file-management use case and want to re-open the evaluation when 2.0 reaches stable with a published changelog, upgrade notes, and evidence of sustained maintainer activity across the alpha series.

Look elsewhere — decisively — when any of the following is true:

• You are on Laravel or a non-Symfony stack. There is no integration; porting a Symfony form type buys you almost nothing, and 2.0 does not add one.
• You need a stable, maintained dependency. An eleventh alpha is evidence of activity, not of stability. Production dependencies should not sit on an unreleased major version.
• Licensing is unresolved. GPL-family licensing in a commercial product triggers legal review with a predictable "no."
• You want modern upload ergonomics. Direct-to-storage uploads (S3/GCS multipart), the tus resumable protocol, Uppy or FilePond on the client, and server-side chunk-manifest validation give you the same UX with active maintenance and permissive licensing — typically days of work, not a quarter.
• You need a file browser / directory listing. Pair a maintained storage abstraction with your own authorization-scoped listing endpoint; don't inherit an alpha's filesystem semantics into a customer-facing surface.
• Large files are a core product surface (video, genomics, design files). Core surfaces deserve maintained infrastructure, not a pre-release bundle.

How to Pitch It (Stakeholders)

For executives: We re-reviewed the library that implements chunked file uploads after a new pre-release. The headline has changed slightly: the project is no longer dormant — there is an active 2.0 rewrite, now at its eleventh alpha, adding a directory-listing feature. That does not change our recommendation. It is still a Symfony component with no path into our Laravel stack, the licensing still creates exposure for a commercial product, and the new work is pre-release software with no stability or compatibility guarantee. Recommendation remains: do not adopt. The capability — resumable uploads for large files, plus a scoped file browser — is achievable in days with actively maintained, permissively licensed components. Net: small engineering cost, avoided licensing and dependency risk, with a cheap calendar reminder to revisit only if and when 2.0 ships stable.

For engineering: Update to the prior guidance. This is a Symfony bundle (JS widget + Symfony form type), not a Laravel package — still no integration path. The new 2.0.0-alpha11 release adds directory listing and revises the maintenance picture: the project is in active development on a new major line rather than abandoned. That changes the reason to decline, not the decision. New signals against: alpha stability with no BC guarantee across alphas, an implied breaking change from 1.x, GPL licensing, and an unvetted new filesystem surface — directory listing brings path-traversal, symlink, authorization-scoping, and enumeration risks that must be threat-modelled before anything ships. Do not add it to the dependency graph. Implement chunked upload against a maintained client (Uppy/FilePond) with a resumable protocol (tus) or native object-storage multipart, chunk-manifest validation and checksum verification server-side, and a separate, authorization-scoped listing endpoint for browsing. Budget it as a small contained sprint, and treat this package as prior art to read — and possibly as a design reference for the browser UX — not code to ship.