Mimey Laravel Package

Product Decisions This Supports

• Upload acceptance rules. Mimey supplies the extension↔MIME mapping behind allowlists ("accept .pdf, .png, .docx"), file-picker filters, and user-facing copy like "Images only." It answers "what type is a .webp?" not "is this file actually a WebP?"
• Download and response headers. A dependable source for Content-Type when serving generated, renamed, or proxied files, and for naming a file from a MIME type on export.
• Build vs. buy for a boring table. The real decision is whether to own a curated MIME registry in-house. Mimey is the borrow side of that decision at near-zero cost — the alternative is a hand-maintained array that drifts between services.
• A forcing function on the security roadmap. This package makes the "extension-based mapping" path cheap and explicit, which highlights the gap it does not close: content sniffing and malware scanning for untrusted uploads. That is a separate, fundable workstream, not something Mimey can be stretched to cover.
• Standardization across services. A single mapping source shared by the API, the admin CMS media library, the document-management module, and the email-attachment handler, instead of four divergent hardcoded arrays.
• Use cases in scope: CMS/media libraries, document and records management, attachment handling, asset pipelines, import/export tooling, content-negotiation helpers, file-type icons and labels.
• Use cases out of scope: trust decisions on user-supplied files, virus scanning, format validation of file contents, deep inspection of archives.

When to Consider This Package

Consider it when:

• You are on PHP/Laravel and need conversion in both directions (extension→MIME and MIME→extension) in ordinary application code.
• The requirement is honestly presentation-layer mapping: labeling, filtering, header generation, naming — not security.
• You want a small, MIT-licensed, low-ceremony dependency rather than pulling in a larger component for two functions.
• You are willing to pin the version and wrap it behind a thin internal interface, which makes it swappable and contains the maintenance risk.

Look elsewhere when:

• Untrusted uploads are in play. Extension-derived MIME types are attacker-controlled. Use finfo/fileinfo, magic-byte sniffing, and scanning instead — Mimey should never be the gate.
• You need runtime extensibility or custom mappings. A static table you cannot extend without forking is a poor fit; Symfony Mime offers more flexibility and far more active maintenance.
• Registry currency matters. This is a static, low-activity table with a single maintainer; if IANA-registry freshness is a compliance requirement, that is a real risk.
• You are polyglot. If several non-PHP services need the same mapping, a shared mapping service or data file beats a PHP-only library.
• You are treating it as a foundation. 329 stars and a weak opportunity signal mean it is fine as a leaf dependency and wrong as load-bearing infrastructure.

How to Pitch It (Stakeholders)

For executives: A free, MIT-licensed utility that eliminates a recurring class of bugs — inconsistent file-type tables copied across the codebase — for hours of integration rather than a sprint. No procurement or licensing friction, and negligible vendor risk because the package is small enough to replace or fork outright; we contain that risk by wrapping it behind an internal interface. Be precise about the boundary: it does not secure uploads, and we should not present it as doing so. Approve it as plumbing, and keep upload security as its own line item.

For engineering: One dependency, static arrays, two lookups. Use it for presentation-layer mapping — Content-Type headers, file-picker filters, download naming, type labels — and never for trust decisions on user-supplied files. Pin the version, hide it behind a small service so a future swap to Symfony Mime is a one-file change, and route all validation of untrusted uploads through content sniffing and scanning.