Internet Media Type Laravel Package

Product Decisions This Supports

• Build vs. buy for media-type handling: this package covers a small but genuinely fiddly problem — parsing, validating, and comparing internet media types (MIME types), including structured-suffix handling and fixer/normalisation passes. If our product ingests uploads, webhooks, or API payloads with Content-Type headers, adopting it replaces hand-rolled regex parsing that tends to rot.
• Roadmap input for content ingestion and API hardening: reliable media-type parsing underpins decisions about accepted upload formats, webhook content negotiation, and safe response headers. This release doesn't add capability, but it signals the package is actively maintained — a positive input for keeping it on the "adopt" side of the roadmap.
• Release/pinning policy decision (the material one): 4.1 re-namespaces fixers, models, parsers, and exceptions in a minor version bump. Any use statement referencing the old namespace breaks on a ^4.0 constraint auto-upgrade. PM decision point: tighten our Composer constraint to ~4.0.0 / pin the lockfile, or schedule a deliberate upgrade task with a namespace audit.
• Upgrade scoping: the change is mechanical (import path renames) rather than behavioural, so the upgrade is a bounded ticket — good candidate for bundling with other dependency maintenance rather than a standalone sprint item.

When to Consider This Package

Adopt when:

• We parse or validate media types from untrusted input (uploads, webhook headers, proxied API calls) and want a battle-tested parser instead of our own regex.
• We need normalisation/fixer passes (e.g. consistent casing, parameter ordering) before comparisons or storage.
• The team is comfortable pinning dependency versions, since the maintainer has shipped a namespace change as a minor release.

Look elsewhere or build in-house when:

• We only ever compare a handful of hard-coded types — a small helper is cheaper than a dependency.
• We need full RFC compliance with a published stability guarantee around semver; this release's namespace change under a minor version is a real signal that minor bumps may carry source-breaking edits. Treat every 4.x bump as requiring a read of the changelog.
• We require framework-level integration — this is a framework-agnostic PHP library with no Laravel service provider or facade, so we write our own binding.

How to Pitch It (Stakeholders)

For executives: this is a small, well-scoped PHP library that handles MIME type parsing correctly so we don't ship our own error-prone version. It's low cost and low risk in itself. The one thing worth knowing: the latest version (4.1) renamed internal namespaces in what is technically a minor release, so upgrades can require code edits. We're mitigating by pinning the version and treating upgrades as planned maintenance work, not automatic.

For engineering: 4.1 is a source-breaking change shipped as a minor — fixers, models, parsers, and exceptions all moved namespace. No new features and no deprecations; behaviour is unchanged. Recommended action: pin to the current lockfile, then do a single pass updating imports if/when we move to 4.1. Don't let composer update float this dependency.