Filechunk Bundle Laravel Package

Technical Evaluation

Architecture fit — Poor, unchanged. makinacorpus/filechunk-bundle remains a Symfony bundle, not a Laravel package, and a 2.0 line does not alter that: the integration surface is still an HttpKernel bundle class, a DI extension, a Symfony Form type, Twig templates, and a bundled JS chunking widget. Laravel has no bundle registry, no Form component, and no Twig by default. The Form type — the package's primary value proposition — still has no Laravel analogue. The new directory-listing feature adds a controller/route surface, which if anything deepens the Symfony HttpKernel coupling rather than reducing it.

Integration feasibility — Low as-is, moderate if reduced to a reference implementation. Of the three assets in the package — (1) the client-side chunking widget, (2) server-side chunk assembly logic, (3) Symfony Form/DI plumbing — only (2) has portable value, and that assessment is unchanged by this release. Porting remains ~5–8 engineer-days against ~3–5 days to build chunked upload natively on a maintained foundation. The alpha release does not improve portability; it adds new server-side surface (directory listing) that we would have to either port or explicitly strip, increasing scope.

Technical risk — Still High, but the axes have shifted. The prior assessment's single largest objection — a dead project — is now materially weakened; two objections are unchanged; one is new.

• Maintenance (materially improved, but replaced by a different risk): The project is clearly not abandoned. A 2.0.0-alpha11 implies sustained development and, by implication, a modernized PHP/Symfony baseline (a major bump from a 2019-era 1.x almost certainly drops PHP 5.6/7.x and Symfony 2/3 constraints). However, alpha11 means eleven pre-release iterations and no stable API. We would be pinning a moving target. Adopting an alpha upload path means upgrade churn, undocumented breaking changes between alphas, and no semver guarantee — for a component that gates customer data ingestion. "Actively developed" and "safe to depend on" are not the same claim.
• License (unchanged, unverified): Nothing in the release notes indicates a license change; GPL-2.0 should still be assumed. The copyleft analysis stands — network-use question for SaaS, near-disqualifying for distributed/on-prem. Legal review is still mandatory before any PoC. Do not let the renewed activity create pressure to skip this.
• Validation (unchanged, still unverified): No updated community metrics were supplied with this release. The prior read — 1 star, 0 dependents, quality score 0.035 — should be treated as the last known state, not as improved. Eleven alphas with no evidence of downstream adoption is not a healthy signal; a pre-1.0-user package churning through alphas typically indicates a small maintainer team iterating without production feedback.
• Domain sensitivity (unchanged and now expanded): File upload remains a top-tier attack surface. The new directory listing feature is the most notable part of this release from a risk standpoint: a listing endpoint over upload storage is a classic information-disclosure and file-enumeration vector, and it widens the blast radius of any path-traversal or authorization defect in the upload path. A single-line release note ("adding directory listing") gives us no basis to assess how it is scoped, authorized, or sandboxed. In a maintained package this would be a routine review item; in an alpha upload component with no downstream users to surface defects, it is unquantified.
• Release hygiene (new): The release note is one line for a feature with clear security and API implications. There is no changelog context on what else moved between alphas, whether the Form type changed, or what the 2.0 migration entails. That documentation posture is itself a risk input.

Key questions

1. Is chunked/resumable upload a real requirement, or does simple large-file upload with upload_max_filesize tuning suffice? (Unchanged — still the highest-leverage question, and still the one most likely to make this entire evaluation moot.)
2. What are the hard constraints — max file size, expected concurrency, resumability across network loss, mobile background uploads?
3. Has Legal ruled on GPL-2.0 in our distribution model? Confirm the 2.0 line has not relicensed.
4. New: What is the 2.0.0 stable timeline, and what is the API-stability contract between alphas? Is alpha11 close to RC, or is this the start of a long series?
5. New: What does "directory listing" actually do — enumerate uploaded files to the end user, or browsing of the server's chunk/temp storage? Who authorizes it, and is it path-sandboxed? This needs a security read before it influences any decision.
6. New: Does 2.0 assume PHP 8.x and Symfony 6/7, and did the Form type or client widget change in a way that alters the porting estimate?
7. Would the team accept a hard fork? If so, we inherit GPL obligations and the burden of tracking an alpha upstream.
8. Are we optimizing for the Symfony asset or the technique? If the latter, still evaluate pion/laravel-chunk-upload, Uppy + Companion, or the tus protocol.

Integration Approach

Stack fit — Mismatched at every layer, unchanged. Symfony HttpKernel, DI semantics, Form component, Twig, jQuery. A compatibility shim remains technically possible and remains a bad trade: a permanent dual-framework seam for one feature. The 2.0 modernization, if it modernizes toward Symfony 6/7, moves the package further from Laravel's idioms, not closer.

Migration path — Do not install the bundle. Treat it as reference material only, and now with slightly better reference value since the 2.0 code is presumably modern PHP:

• Client: replace the bundled widget with Uppy (maintained, tus-capable, framework-agnostic) or an in-house component. Avoid copying GPL JS.
• Server: implement a Laravel-native chunk endpoint (POST /uploads/{id}/chunks/{index}), idempotent by chunk hash, assembling via S3 multipart upload where possible — S3 multipart removes the assembly loop entirely.
• Validation: FormRequest rules for size/MIME/extension plus server-side content sniffing (finfo) and per-user quota checks.
• Directory listing: if we need an upload index, build it as an Eloquent-backed resource scoped to the authenticated owner. Do not port the bundle's listing endpoint; do not expose filesystem enumeration.

Compatibility — Improved on paper: 2.0 almost certainly targets a supported PHP/Symfony baseline, removing the EOL-runtime objection that was previously decisive. But that improvement accrues to Symfony consumers, not to us. For Laravel, the forward-compatibility problem is unchanged, and it is now compounded by an unstable pre-release API. There is still no path that does not involve either a fork or a rewrite.

Sequencing

1. Week 1 — Requirements spike on actual file-size/resumability needs; Legal ruling on GPL-2.0 (including confirmation for the 2.0 line); select alternative (tus vs. S3 multipart vs. library). Do not start a bundle PoC on an alpha.
2. Week 2 — PoC of the chosen alternative against a 2 GB upload over a flaky connection; measure temp storage and reassembly time.
3. Week 3 — Security review (path traversal, MIME spoofing, quota abuse, orphan cleanup, listing/enumeration) and threat-model sign-off.
4. Week 4 — Productionize with monitoring, cleanup jobs, rate limits.
5. Standing item — Re-evaluate this package only if it reaches a 2.0.0 stable release and Legal clears GPL-2.0 and the requirements spike shows a genuine chunking need. All three, not any one.

Operational Impact

Maintenance — Better than the prior read, but not good enough to change the decision. The project is alive, which removes the "unbounded orphaned-code obligation" framing — we would at least have an upstream to track. But upstream is an alpha series: no stability guarantee, no LTS, breaking changes plausible between alpha11 and alpha12. A fork is still strictly worse — GPL obligations plus the burden of rebasing against a moving pre-release upstream. A native/alternative implementation remains ordinary product code we already know how to maintain.

Support — Marginally improved via an active maintainer, but still effectively none. No evidence of downstream adoption means no Stack Overflow corpus, no issue history to mine, no vendor. Every incident remains first-principles debugging. For a feature that gates customer data ingestion, that is still an unacceptable support posture — and "the maintainer is active on GitHub" is not a support contract.

Scaling — Unchanged and still the sharpest architectural objection. The package's model assumes local temp storage for chunk parts: multi-node deployments need sticky sessions or a shared volume, and horizontal autoscaling breaks silently. The 2.0 directory-listing feature does nothing to address this and may add another filesystem-coupled read path. Contrast with S3 multipart / tus, which are stateless per-request and scale horizontally by construction. Reassembly still concentrates memory and disk I/O on the app tier.

Failure modes

• Silent corruption: partial/misordered chunk assembly yielding a file that passes size checks but is invalid — worst case, discovered downstream.
• Orphaned temp files: aborted uploads with no GC path; disk fills, app tier dies.
• Race conditions: concurrent retries of the same chunk index without an idempotency key producing duplicated or truncated parts.
• Security — uploads: path traversal via client-supplied filename, MIME spoofing, quota bypass.
• Security — directory listing (new): enumeration/information disclosure over upload or temp storage; authorization gaps on a newly added read path; a broader blast radius for any traversal defect. Untested by any known downstream user.
• Pre-release instability (new): behavior changing between alphas, undocumented in one-line release notes, surfacing as regressions after a routine composer update. The runtime-incompatibility failure mode from PHP 5.6/7.x is likely retired by 2.0 — that specific risk is genuinely reduced.

Ramp-up — Deceptively low for a demo, deceptively high for production, and the gap is now wider rather than narrower: the code is modern enough to look trustworthy at a glance, while the alpha status, absent community validation, and new listing surface mean the hardening work is not smaller than it was. The knowledge required to harden it is still exactly the knowledge required to rewrite it. Recommendation: reject — unchanged in direction, updated in reasoning. The project is no longer dead, which removes the strongest single argument against it, but that argument is replaced by "pre-release, unvalidated, GPL, wrong framework." Build on a maintained primitive; the effort delta remains near zero and the risk reduction substantial. Revisit only on a 2.0.0 stable release with Legal clearance.