Image Conversion Laravel Package

Product Decisions This Supports

• Build vs. buy for image conversion: this is neither — it's a "don't adopt." With 6 stars, zero dependents, and a quality score of 0.57, the package carries no evidence of production use. The decision it actually supports is standardizing elsewhere (Intervention Image for Laravel, Glide, or Spatie's image tooling) and recording this as a rejected option in the ADR.
• Vendor-risk and license triage. NOASSERTION means automated license detection failed — for a dependency that would sit in your supply chain, that's a legal review item before it's even a technical one. A PM decision to exclude it from the approved-dependency list is a legitimate, low-cost outcome.
• Legacy migration scoping. Zeta Components (formerly eZ Components) is a pre-Composer-era PHP library. If your estate still runs eZ Publish/eZ Platform-adjacent code, this repo is a scoping artifact: it tells you which subsystems depend on a backend-agnostic GD/ImageMagick converter interface, and therefore what a migration to a maintained library will cost.
• Architecture reference, not dependency. The one durable asset here is the pattern: a driver abstraction over GD vs. ImageMagick with a uniform conversion API. That's useful input if you're designing your own image pipeline or evaluating whether a candidate library's backend-swapping story is adequate — read the source, don't import it.
• Roadmap de-prioritization. The opportunity score (42.74) and absent maintenance signal mean any roadmap item phrased as "adopt Zeta ImageConversion" should be re-scoped to "select and adopt a maintained image library," with this package noted as considered-and-rejected.
• Not a signal for investment. Zero dependents is the decisive datapoint: there is no community to inherit fixes from, so every future CVE or PHP-version break becomes fully your team's cost.

When to Consider This Package

Consider it only under narrow conditions:

• You are maintaining an existing Zeta/eZ Components codebase where it is already a transitive dependency and removing it is a larger change than keeping it temporarily. Even then, the correct move is a documented exit plan, not a new integration.
• You need a reference implementation of a backend-agnostic image conversion interface (GD and ImageMagick drivers, lazy loading, format/quality options) and want to compare designs before committing to a library. Read-only use.
• You are doing due-diligence evidence-gathering — e.g., documenting that you evaluated multiple options before selecting Intervention Image or Glide. Retaining it in the comparison matrix is defensible; shipping it is not.
• Your environment is pinned to legacy PHP (5.x-era) and no modern alternative is installable yet. Treat as a stopgap with an owner and a removal date.

Look elsewhere — decisively — when:

• You're building on Laravel. There is no service provider, facade, or framework integration here. You'd be writing the wiring yourself for a library with no upstream support.
• You need maintained code. No recent release cadence, no issue triage, no security response process. Modern PHP (8.2/8.3) compatibility is unverified.
• License clarity matters. NOASSERTION must be resolved by counsel (the upstream Zeta Components projects were generally Apache‑2.0, but you should not assume that in a procurement document) before any use.
• You need a supported community. Zero dependents means zero external bug reports, zero Stack Overflow corpus, zero third-party tutorials — your onboarding cost is entirely internal.
• Your roadmap includes image optimization, responsive derivatives, or CDN-backed transforms. Nothing here addresses modern pipeline concerns; you'd be building those layers from scratch on an unsupported base.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated zetacomponents/image-conversion for image handling and are recommending against adoption. It is an unmaintained legacy PHP library with negligible community adoption (6 stars, zero dependent projects), an unresolved license classification, and unverified compatibility with our PHP runtime. Adopting it would create a dependency our team alone would have to patch and support. The recommended path is a maintained, actively released alternative — Intervention Image for Laravel work, or Glide for URL-driven derivative pipelines — which lowers long-term maintenance cost and removes a legal-review blocker before it reaches procurement.

To engineering leadership: The package's genuine value is conceptual — its driver abstraction over GD and ImageMagick is a reasonable design reference and useful input when we compare candidate libraries. We propose logging it as evaluated and rejected in the architecture decision record, with a short note on why, so the question doesn't resurface next quarter. If any legacy service already depends on it, we need that inventory now so we can size an exit plan rather than discover it during a PHP upgrade.

To the engineering team: Do not add this as a dependency in new work. If you find it in a legacy path, flag it — don't remove it unilaterally, since it may be load-bearing. If you're evaluating image libraries, read this repo's driver interface for design ideas, then benchmark Intervention Image, Glide, and Spatie's image package against our actual requirements: format coverage, quality control, memory behavior on large uploads, queue/async support, and storage abstraction fit. Bring a one-page comparison to the next technical review; that comparison, not this package, is the deliverable.