File Converter Laravel Package

Technical Evaluation

Architecture fit. fragosoftware/file-converter is a standalone PHP library, not a Laravel package. There is no evidence of a service provider, facade, config publish, or queue-aware API in the description — it advertises "conversion and manipulation of files between formats" with no Laravel idiom. In our stack that means it would sit below our framework layer, requiring us to build the integration surface (provider, config, disk-awareness) ourselves. Treat it as a library to wrap, not a package to install.

Integration feasibility. MIT license removes legal friction, and Composer distribution makes adoption mechanically easy — which is precisely the trap. The real feasibility question is what backs the conversions: pure-PHP encoders, PHP extensions (imagick, gd), or exec() calls into ImageMagick / LibreOffice / ffmpeg. Each has a materially different operational profile. A thin exec() wrapper over user-supplied paths is a command-injection and path-traversal surface; a pure-PHP implementation is safer but slower and format-limited. We cannot answer this from the README — it requires reading the source.

Technical risk — high. The adoption signals are effectively zero: 1 star, 0 dependents, composite score 0.005. That is not "early," it is "unvalidated." Concretely:

Key questions for the maintainer / source audit.

1. What are the conversion backends per format — extensions, CLI binaries, or pure PHP?
2. Are file paths and arguments escaped/validated before any shell invocation?
3. Is there a Laravel service provider, or only framework-agnostic classes?
4. Which PHP and Laravel versions are supported, and what are the transitive constraints?
5. Is there CI, a test suite, or a documented mime/format support matrix?
6. Does it accept untrusted uploads, and does it enforce size/time limits?
7. Is there a SECURITY.md and a release history beyond the initial commit?

Integration Approach

Stack fit. Composer install works, but framework ergonomics are absent. We would author: a FileConverterServiceProvider, a config file declaring allowed formats and size ceilings, a Converter contract in our domain layer, and a StorageDiskConverter adapter that bridges Laravel's Storage abstraction to whatever local-path API the library exposes. That adapter layer is non-negotiable — it is what keeps the vendor choice reversible.

Migration path. Do not migrate any existing pipeline. Run a time-boxed spike in a scratch branch, invoked from a queued job, converting one low-risk format pair (e.g., CSV→XLSX or a document-to-PDF internal report). Establish a working baseline before committing to anything broader.

Compatibility. Verify the PHP constraint against our Laravel version, scan for deprecated or removed functions, and confirm no conflicting transitive pins. Because the library has no dependents, Composer's conflict graph will not have surfaced these issues for us.

Sequencing.

1. Source-level security and quality audit (read the code, not the README) — gate for everything else.
2. Define the Converter contract and adapter interface first, so the library is an implementation detail from day one.
3. Spike: queued job, containerized binary set, one format pair.
4. Wrap with timeouts, size caps, mime sniffing on both input and output, and temp-file cleanup.
5. Pilot internally for 30 days with output validated against a known-good baseline.
6. Decide at day 30: keep, fork-and-vendor (MIT permits it), or replace with an established backend (Intervention Image, LibreOffice headless, or a managed API) behind the same contract.

Operational Impact

Maintenance. We would own this outright. With zero dependents there is no community backpressure to keep it current, so upstream fixes may never arrive. Budget for a vendored fork under our namespace with our own patch queue — the MIT license makes this cheap and should be assumed rather than avoided.

Support. No commercial support, no community, no documentation depth. An internal owner must be named and a runbook written before the pilot ends, or the pilot becomes an undocumented dependency.

Scaling. Conversion is CPU- and memory-bound and blocking — it must never run in the request path. Run it in dedicated queue workers with per-tenant concurrency limits, hard timeouts, and a max-input-size gate. If the backends are CLI binaries, they must be baked into a dedicated container image, which adds image size and an ongoing CVE-patching obligation for tools like ImageMagick and LibreOffice that have non-trivial vulnerability histories.

Failure modes to design against.

• Shell injection or path traversal from unescaped user filenames.
• Zip bombs / decompression bombs and OOM on large inputs.
• Non-zero exit codes swallowed, yielding empty or truncated output that passes downstream.
• Temp-file accumulation filling a worker's disk.
• Malicious inputs exploiting the converter binary itself — isolate workers, run as non-root, no outbound network.

Mitigations are standard but must be built, not assumed: sandboxed workers, output validation via mime sniff plus re-render check, dead-letter queue for repeated failures, and alerting on conversion failure rate.

Ramp-up. The library's own API is small — learning it is a day. The actual ramp-up is the surrounding safety rail: sandboxing, queue topology, validation, and observability. Estimate 3–5 engineering days for audit, wrapper, and pilot; the durable cost is ongoing ownership of an unmaintained dependency.

Recommendation. Proceed only as a bounded, contract-isolated spike — not as a production dependency. The opportunity score and adoption signals do not support a direct commitment, but the adapter pattern makes the experiment cheap and fully reversible if the source audit comes back clean.