Resource Bundle Laravel Package

Technical Evaluation

Architecture fit. The package is presented as a Laravel/PHP package, but Enhavo is a Symfony CMS and this is a Symfony bundle (EnhavoResourceBundle), not a Laravel package. That distinction is the whole evaluation: it registers through Symfony's Kernel/bundle system, relies on Symfony's DI container and config compiler passes, and almost certainly assumes Doctrine for persistence. There is no service provider, no facade, no Eloquent integration. In a Laravel codebase the fit is not "poor" — it is category-wrong. The "resource" abstraction it provides overlaps conceptually with Laravel API Resources, policies, and form requests, but is not interchangeable with them.

Integration feasibility. Low. The README is a single heading, stars are 0, dependents are 0, and the maturity score is "readme" — meaning there is no documentation, no usage example, no stated version support, and no evidence of anyone running this in production outside the Enhavo monorepo. Any evaluation requires reading source directly. Composer installation may technically succeed, but Laravel already ships Symfony components (console, http-foundation, http-kernel, process, etc.) at versions pinned to the Laravel release; an Enhavo bundle will constrain those same packages to a different range. A dependency-resolution conflict is the most likely first failure, before any code runs.

Technical risk. High, on four axes: (1) abandonment — zero community surface means no security patches and no upgrade path; (2) framework mismatch — bridging Symfony bundle semantics into Laravel's container is real engineering, not configuration; (3) transitive coupling — Enhavo bundles typically depend on Enhavo core abstractions, so pulling one likely pulls a slice of the CMS; (4) unknown surface — with no docs, we cannot scope what the bundle actually does (resource routing? admin CRUD? metadata?) until someone reads it. The opportunity score of 38.62 is consistent with "niche internal extraction, not a standalone library."

Key questions for the requester.

• What capability do we actually need, and why this package rather than Laravel's native resource/policy layer?
• Is there an Enhavo deployment already in the estate, or is this a fresh introduction?
• Do we have any Symfony footprint at all, or would this be the first?
• Which Symfony major and PHP version does the bundle target, and does that range intersect Laravel's symfony/* pins?
• Who owns upstream maintenance, and what is the license?
• Is the real requirement "use Enhavo" (in which case the answer is a separate service) rather than "use this bundle"?

Integration Approach

Stack fit. Treat this as a Symfony component, not a Laravel one. There is no clean in-process fit. The only coherent integration patterns are: (a) run Enhavo as a standalone Symfony application and consume it over HTTP from Laravel; or (b) extract the specific behavior we need and reimplement it natively in Laravel. Installing the bundle inside a Laravel app and shimming the container is a third option that costs more than either and buys the least.

Migration path. There is nothing to migrate to. If the driver is an existing Enhavo installation we are consolidating, the migration is outbound — expose Enhavo via API and keep Laravel as the system of record for everything else. If the driver is "this bundle looks useful," the correct path is a build decision, not an adoption decision.

Compatibility. Must be verified before any commitment: run composer why-not against the current composer.json in a throwaway branch, check the bundle's composer.json for symfony/*, doctrine/*, and php constraints, and confirm PSR-4 autoloading and license. Expect conflicts on symfony/http-kernel and symfony/console. Also confirm whether the bundle has a DependencyInjection/ extension and whether it requires Enhavo core bundles it does not declare.

Sequencing.

1. One-day spike: fork or composer require --dry-run in a sandbox, read the bundle's composer.json and service definitions, write a one-page summary of what it actually does.
2. Two-to-three day dependency probe: attempt resolution against the target Laravel version; record conflicts.
3. Go/no-go: compare the cost of bridging against the cost of reimplementing the needed abstraction in ~200 lines of Laravel-native code.
4. If go (unlikely): vendor the fork, pin the commit, and add a contract test around every entry point we touch.
5. If no-go (expected): document the decision and the native alternative so the request does not resurface.

Operational Impact

Maintenance. Effectively we would own it. Zero stars and zero dependents means no community to absorb upgrades; the fork becomes ours the moment we ship it. Upstream is maintained at the convenience of the Enhavo project, and a bundle extracted for internal CMS use can go quiet without notice.

Support. No documentation, no issue history to search, no SLA, no vendor. Internal support means at least one engineer fluent in Symfony bundle conventions — container compilation, tagged services, config trees — which is a different skill set from typical Laravel work. That is a hiring and on-call consideration, not just a learning one.

Scaling. Runtime performance is not the primary concern; Symfony bundles are conventional PHP and will scale like any Laravel app. The scaling risk is upgrade scaling: every Laravel major bump drags symfony/* forward, and an Enhavo-pinned transitive dependency can freeze the whole application on an old framework release. That is a slow, expensive failure mode — discoverable only when a security patch requires an upgrade we cannot perform.

Failure modes. Ranked by likelihood: composer resolution conflict at install; container boot failure from unmet Symfony/Enhavo service assumptions; silent behavioral divergence from Laravel conventions (events, validation, authorization) discovered in staging; upstream abandonment leaving an unpatchable dependency; and undocumented coupling to Enhavo core pulled in transitively. The worst case is not a crash — it is a working integration that quietly blocks the next two framework upgrades.

Ramp-up. Two to four weeks for a mid-level PHP engineer to become productive in Symfony bundle internals, plus the spike above. That cost is only justified if the bundle provides something genuinely non-trivial. Given a README of one line, we cannot yet claim it does.

Recommendation. Do not adopt into the Laravel codebase. Fund the one-day spike only to answer "what does this do and can we reimplement it," and default to a native Laravel abstraction or an out-of-process Enhavo integration.