Media Bundle Laravel Package

Technical Evaluation

Architecture fit. This package is not a Laravel package. enhavo/media-bundle is a Symfony bundle — a subtree split of the Enhavo CMS monorepo — and its service definitions, configuration tree, and entity model assume the Symfony full-stack runtime (HttpKernel, DependencyInjection, Doctrine ORM, Form, Routing) plus a family of sibling Enhavo bundles (EnhavoCoreBundle, the resource/Grid abstractions) that are not published as standalone units. Dropping it into a Laravel application would mean running two container paradigms side by side with no service-provider bridge, no publishable config, and no Eloquent mapping. There is no architecture fit with a Laravel stack; there is a partial fit with a Symfony stack that is already committed to Enhavo.

Integration feasibility. Low. The realistic paths are (a) adopt Enhavo CMS wholesale as the Symfony application and consume media through it, or (b) treat this bundle as a reference implementation and reimplement its media domain model in Laravel. A hybrid "install the bundle into Laravel" path is not viable — Composer will resolve the split package, but the container will fail on missing parent bundle services before the first request.

Technical risk. High. The bundle is read-only, has 2 stars and zero dependents, and its only documentation is a logo and a pointer to the main repository. That signals: no bundle-level issue tracker, no independent test signal, no versioned support policy beyond monorepo tags, and effectively a single-vendor bus factor. Media handling is also a security-sensitive surface — upload validation, MIME sniffing, path traversal, SVG/script payloads, and storage ACLs — and a CMS-oriented uploader carrying unknown validation depth is a poor place to accept inherited risk. Coupling to monorepo branch aliases means a force-push or re-split upstream can break your lockfile.

Key questions.

• What is the actual requirement: media storage/variants/transformations in Laravel, or a full CMS?
• Does any part of the estate already run Symfony, or Enhavo specifically?
• Which Enhavo core bundles and which Symfony/Doctrine major versions does this split require at the tag we'd pin?
• Is the media domain model (Media entity, renditions/formats, folders, storage abstraction) separable from Enhavo's resource layer, or is it welded to it?
• Is there a maintained fork, and who owns patching if upstream stalls?

Integration Approach

Stack fit. Poor for Laravel. The idiomatic Laravel answer to the same problem is a Flysystem-backed media library (spatie/laravel-medialibrary) with intervention/image for conversions and Laravel's queue for derivative generation. That stack is container-native, has publishable migrations and config, and carries an order of magnitude more dependents and maintenance signal. Recommend that as the default and treat Enhavo as an evaluated-and-rejected alternative unless the CMS requirement is real.

Migration path. There is no migration path for code; there is a path for design. Run a short Symfony sandbox spike (stand up Enhavo, upload assets, inspect the media tables and rendition pipeline), extract the useful concepts — media record vs. file record separation, named conversion sets, folder/taxonomy model, storage adapter boundary — and reimplement them as Laravel migrations and models. Port the schema shape, not the bundle.

Compatibility. Expect PHP and Symfony major-version constraints tied to a monorepo branch, Doctrine entity mapping incompatible with Eloquent, no service provider, no config publishing, no Laravel-visible migrations, and template helpers written for Twig rather than Blade. None of these are bridgeable without a maintained adapter, which does not exist.

Sequencing.

1. Confirm whether the business requirement is media management or CMS authoring.
2. Cap the evaluation at a 2–3 day sandbox spike; no application integration.
3. If the concepts hold value, design Laravel-native schema (media, media_conversions, media_folders) and storage boundaries.
4. Implement on laravel-medialibrary + intervention/image + queued conversions.
5. Park the Enhavo/CMS decision as a separate, architecture-level evaluation with its own business case — do not let it ride in on a media ticket.

Operational Impact

Maintenance. Subtree-split packages are downstream artifacts: fixes and PRs must land in the monorepo and be re-split, so your patch latency is upstream's release cadence plus a re-split. If upstream stalls, the only option is forking and maintaining the split yourself — for a 2-star, zero-dependent package that is an unshared cost. Any local patches will conflict on every sync.

Support. No bundle documentation, no issue tracker at this level, no Stack Overflow corpus, no Laravel-side community at all. Onboarding and troubleshooting fall entirely on internal Symfony expertise or on reading the monorepo source.

Scaling. Media workloads are I/O- and CPU-bound rather than request-bound. A CMS-oriented bundle will likely assume local filesystem storage and Doctrine transactions; moving to S3/CDN, multi-region reads, or signed URLs means replacing the storage layer. Image derivative generation must go to background workers or it becomes a request-latency and timeout problem under bulk upload. Orphaned files from failed transactions and unbounded upload concurrency are the two scaling cliffs to design around.

Failure modes.

• Container boot failure from unresolved parent-bundle service dependencies — fails fast and loudly, which is at least honest.
• Composer lockfile drift when upstream re-splits a branch.
• Schema/entity drift between the bundle's Doctrine mapping and any hand-written Laravel tables if a hybrid is attempted.
• Failed or partial rendition generation surfacing as broken images with no retry path.
• Upload validation gaps turning into stored-XSS or path-traversal exposure.
• Storage growth without lifecycle/GC policy on replaced or deleted assets.

Ramp-up. Even for a read-only concept port, engineers need working Symfony fluency — bundles, DI compiler passes, Doctrine mapping, Twig — to read the source with confidence. Budget one to two weeks before a mid-level Laravel developer is productive in that codebase. Learning Laravel's media stack instead is measured in hours, which is itself a strong argument for the reimplementation path.