Mimey Laravel Package

Product Decisions This Supports

• Upload & download feature plumbing. Any roadmap item that touches file handling — avatar uploads, document attachments, media libraries, invoice/report exports, CSV imports, email attachments — needs an extension↔MIME mapping somewhere. This package is one small, replaceable component of those features, not a feature in itself.
• Build vs. buy (vs. reuse). The decision is not "build a MIME mapper" — it's "do we add a 33-star dependency, reuse symfony/mime which Laravel already pulls in, or write ~40 lines of our own?" Because the scope is so narrow, the honest framing is: buy only if it saves more review time than it costs in supply-chain and maintenance risk.
• Content-Type correctness for customers and integrations. Setting the right Content-Type on downloads, API file responses, and outbound mail attachments affects whether browsers preview vs. download files and whether third-party systems (CRMs, ERPs, email clients) accept our payloads. This is a small but real source of support tickets.
• Custom/proprietary file formats. If a roadmap bet involves domain-specific files (.dwg, .heic, .glb, .epub, internal export formats, vendor-specific data interchange formats), runtime registration of custom MIME types is the one genuinely differentiating capability here.
• Prioritisation signal, not a feature bet. This should never appear on a roadmap as its own line item. It's an implementation detail inside an estimated story — worth a spike, not a quarter.
• Explicit non-decision: it is not a security control. Extension-derived MIME types are trivially spoofable. If the underlying feature is "validate uploads," the real decision is content sniffing (finfo/fileinfo, getimagesize, AV scanning, allow-lists), and this package is at best a cheap pre-filter. Do not let it become the answer to a compliance or abuse question.

When to Consider This Package

Reasonable fit when:

• You need both directions (extension → MIME and MIME → extension) in a Laravel codebase and want a facade-style API rather than raw arrays.
• You have a small, stable set of custom or proprietary extensions to register at runtime, and that capability is a hard requirement.
• You value zero external dependencies and a tiny surface area — easy to read, audit, and vendor into the repo if needed.
• The usage is non-critical: cosmetic Content-Type hints, demo/seed data generation, filename-based type guesses for display icons, dev tooling.
• You're willing to accept that you may end up forking it — which, given the size, is a genuinely low-cost fallback.

Look elsewhere when:

• Maintenance matters. Last release is June 2021, 33 stars, unclear maintainer activity. PHP 8.2/8.3 and Laravel 10/11 compatibility is unverified. For a dependency that will sit in a long-lived product, this is a one-way door into "we own this now."
• symfony/mime is already installed — and in a Laravel app it almost certainly is. That component is battle-tested, actively maintained, and gives you MimeTypes::getDefault(), getExtensions(), and registration. Choosing this package means carrying a second, less-maintained implementation of the same data.
• Security or compliance is in scope. Use finfo_file() / mime_content_type() for anything user-supplied. Extension guessing must not be the gate.
• You need authoritative, frequently updated mapping data (new or niche formats, per-OS variance, RFC alignment). The mapping is only as fresh as the last release, and that release is years old.
• Your team has a "no unmaintained transitive deps" policy or an SBOM/security review gate — this will trip it, and winning that argument isn't worth the ~40 lines saved.

Recommendation to weigh in the room: default to symfony/mime (already on the dependency tree, zero new risk). Adopt xantios/mimey only if the custom-registration ergonomics are materially nicer for your use case and you're comfortable pinning to a version you may have to fork.

How to Pitch It (Stakeholders)

For executives (30 seconds). This is a very small, free, MIT-licensed utility that turns file extensions into MIME types and back. It would save an engineer a few hours inside a file-handling feature we've already planned — it is not a feature, not a differentiator, and not on the roadmap. The trade-off is supply-chain risk: 33 GitHub stars, one release in 2021, no verified support for current PHP/Laravel versions. My recommendation is to use the equivalent component that already ships with Laravel rather than add a new dependency. If we do adopt it, the realistic cost is low and the worst case is that we fork and maintain ~40 lines ourselves — a bounded, unexciting downside, not a strategic risk. Either way, it does not change scope, timeline, or budget.

For engineering leads. Narrow API, PSR-4, no dependencies, optional service provider and facade — integration is under an hour, and migration away is under a day. Two caveats to accept explicitly: (1) it's unmaintained since 2021 and we should pin the version and vendor it if adopted; (2) extension-based MIME resolution must never be the security boundary for user uploads — pair it with finfo-based content validation and an allow-list. Given symfony/mime is already in the tree, the default engineering answer should be "reuse what we have"; the exception is if runtime registration of proprietary extensions is a real requirement, in which case this package's ergonomics justify the dependency and the small fork risk is acceptable.