Check Format Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for document ingestion — still "build," but now for a different reason. The v2.0 release changes the maintenance objection (there is now evidence the maintainer is alive) but not the fit objection. A major version whose entire scope is "compatible with Symfony 5" tells us the package is deliberately tracking a framework generation that is already several majors behind current Symfony, and is a full generation away from what Laravel ships against. The decision it most usefully informs remains build: a thin in-house validation and path-mapping layer is cheaper to own than to adopt, adapt, and eventually rewrite.
• A concrete "do not adopt" signal, not an ambiguous one. Previously the objection was silence — no release, no dependents. Silence can be read charitably as "stable." v2.0 removes that ambiguity: the maintainer is active, and the roadmap is Symfony 5 compatibility. That is a compatibility floor being lowered, not raised. For planning purposes this is a firmer no than the 2022 state.
• Roadmap scoping for format support: unchanged and still the most valuable use. Treat the package as a requirements input — which formats must we accept, reject, or convert, and how do we map accepted files onto storage paths — rather than an implementation choice.
• Architecture fit check — confirmed, now with a version constraint. The "bundle" naming convention already indicated a Symfony bundle, not a Laravel package; v2.0 does not add a service provider, package auto-discovery, or Laravel-native config publishing. Any adoption implies an adapter layer. New this cycle: the adapter must also bridge a Symfony 5-era codebase to Symfony 6/7 components, which is a widening integration cost, not a shrinking one.
• Major-version bump as a migration risk input. v2.0 carries a breaking-change surface by definition — most likely dropped Symfony 4 support, possibly namespace or signature changes. Any team that had forked or vendored the 1.x line now owns a diff. This supports a policy decision to keep the package off the critical path regardless of maintainer activity.
• Licensing and vendoring options: MIT still permits forking and vendoring. Forking remains defensible if a team wants the specific format-mapping logic — but it must be resourced as internal code with tests, and the fork should be taken from 1.x or 2.x deliberately, not by default.

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony 5-based and pinned there. (v2.0 makes the package explicitly a worse fit for Symfony 6/7 and no better a fit for Laravel — the compatibility window narrowed rather than widened.)
• The need is genuinely limited to simple format checks plus mapping files onto storage paths — not content inspection, virus scanning, transcoding, or archival guarantees.
• The team is willing to fork, vendor, and take full maintenance ownership, including PHP version bumps, the Symfony 6/7 migration the upstream has not done, and security review of the parsing code.
• A time-boxed spike confirms the v2.0 code is tested, documented, and readable enough to own — still not evident from the release note, which is a single line with no changelog, no test evidence, and no upgrade guide.
• Someone has actually read the v2.0 diff to establish breaking changes before any downstream work is scheduled against it.

Look elsewhere when any of the following apply:

• You are on Laravel. Prefer symfony/mime (via fileinfo) for format detection and league/flysystem for filesystem abstraction. Both are actively maintained with large dependent bases and Laravel first-class support. This was the recommendation before v2.0 and it is unchanged.
• You need maintenance guarantees. The signal has improved from "no release in three years" to "one release in three years, scoped to a legacy framework version." That is still a liability for code touching uploaded files.
• You need a forward compatibility path. v2.0 targets Symfony 5 specifically; there is no stated path to Symfony 6/7. Adopting now means adopting a known-dead-end.
• You need breadth of format support or correctness guarantees. Still zero dependents, one star, single-maintainer namespace — still no community validation and no downstream usage to learn from.
• You need support, SLAs, or a security disclosure process. None is indicated.
• The work is on the critical path. Untested, thinly maintained code parsing untrusted uploads remains a poor risk profile.

How to Pitch It (Stakeholders)

For executives: This is a small open-source utility for checking file formats and mapping documents to storage. It published its first release in about three years, and the release is a compatibility update for Symfony 5 — a framework generation that is already behind current. In other words, the project is active again, but its direction is backwards-looking, and it still has no meaningful adoption. The underlying capability is commodity: mature, well-supported libraries already cover it, and a short internal build would cost little and carry far less risk. Recommendation is unchanged — do not adopt; fund a short internal build instead.

For engineering: v2.0 is a single-line release note ("Version compatible symfony 5") with no changelog. Read it as two facts: the maintainer is alive, and the package's compatibility target is Symfony 5, not Symfony 6/7 and not Laravel. That does not close the gap we flagged — no service provider, no auto-discovery, no Laravel-native config — and it adds one: an adapter would now have to span a legacy Symfony generation. Treat v2.0 as a breaking-change event if anything internal forked the 1.x line; pull the actual diff before scheduling work. Recommended path is unchanged: a thin internal service on symfony/mime for format validation and league/flysystem for path mapping — a few days of work with active upstream maintenance, tests, and security review. If a specific piece of the mapping logic is worth keeping, fork it under MIT into our own namespace, pin it deliberately, add tests, and keep it off the critical path. Re-open this assessment only if upstream ships a Laravel service provider, a Symfony 6/7 line, or a changelog demonstrating test coverage.