App Bundle Laravel Package

Technical Evaluation

Critical framing correction: despite being filed under a Laravel/PHP package shortlist, enhavo/app-bundle is a Symfony bundle, not a Laravel package. Enhavo is a full-stack CMS built on Symfony. There is no Laravel service provider, no Eloquent, no Blade. If the evaluation was scoped as "Laravel ecosystem fit," the correct disposition is reject on stack mismatch and, if CMS capability is still a requirement, re-run the evaluation against the Symfony ecosystem.

Architecture fit. The README is explicit: "This is a subtree split of the main repository." EnhavoAppBundle is the application-level glue bundle of a monorepo — routing, base templates, configuration wiring, admin UI kernel — not a standalone reusable library. Its architecture is correct inside an Enhavo installation and largely meaningless outside one. Consuming it as an independent dependency will not yield a working CMS; you need the parent project (enhavo/enhavo), its sibling bundles, a Doctrine schema, and a front-end asset pipeline.

Integration feasibility. Low as a direct dependency, moderate-to-high as a transitive one. The realistic path is composer create-project from the upstream skeleton, where this bundle arrives pinned by the core's own composer constraints. Direct require enhavo/app-bundle should be treated as an anti-pattern: you would own version-skew reconciliation against sibling bundles that the maintainers never intended to be resolved independently. Additional feasibility gates — bundle registration in config/bundles.php, config import ordering, Doctrine migration baseline, and a Node/Webpack Encore build step — all need verification, and none are documented in this repository.

Technical risk. High, concentrated in provenance rather than code quality:

• Read-only split. "READ-ONLY" means no pull requests, no issue triage, no release notes, no security advisories here. Every defect becomes an upstream conversation on the main repo. That is a real procurement and support consideration, not a formality.
• Zero stars, zero dependents. No external adoption signal whatsoever. You cannot infer stability from the ecosystem; there is no community to lean on and no third party who has already hit your failure modes.
• Generated artifact drift. Subtree splits are mechanical exports. Tags can lag core releases, and a split can silently fall behind or be regenerated with rewritten history. Any pinning strategy must pin the core version, never the split's tag in isolation.
• Maturity = "readme". No CHANGELOG, no upgrade guide, no CI badge, no versioning policy visible in this repo.
• Single-vendor concentration. Bus factor and roadmap continuity depend entirely on the upstream Enhavo organization and its commercial backing.

Key questions to put to the maintainers before any commitment:

1. Is this split actively published to Packagist and tagged in lockstep with core releases, or is it an archival mirror?
2. What Symfony and PHP versions are supported, and is there a stated LTS alignment policy?
3. Is there a security disclosure channel and a patching SLA for the split?
4. Where does commercial support exist, and does it cover this bundle?
5. What is the upgrade contract between major versions — is there a documented BC policy?
6. Which sibling bundles and asset-build steps are hard prerequisites, and what is the minimum viable install footprint?
7. Is the split reproducible from the monorepo at a given commit, so we can audit what we actually ship?

Integration Approach

Stack fit. Two viable postures:

• Org is Symfony-standardized: proceed to a proper evaluation — but scope it against enhavo/enhavo, not this repository. This bundle becomes an inventory line item in the SBOM, nothing more.
• Org is Laravel-standardized: stop. Running a Symfony CMS alongside a Laravel estate means a second framework runtime, a second dependency tree, a second deployment model, and a second skill pool. Do not pay that tax for a zero-star, zero-dependent package. Re-open the CMS requirement against Laravel-native options first.

Migration path. Recommended sequence, assuming Symfony is acceptable:

1. Provision a throwaway environment and install the upstream skeleton, letting Composer resolve all Enhavo bundles including this one. Record the resolved lockfile — that is your real dependency baseline.
2. Do not fork, vendor-patch, or overlay this repository. If a change is needed, it goes upstream or it becomes an application-level override in your own bundle.
3. Model two or three real content types in the admin before any further commitment. Enhavo's value proposition is complex data structures with a clean editorial UI; if your content model is simple, the framework cost is unjustified.
4. Only then design the production topology (database, cache, asset CDN, admin access controls).

Compatibility. Treat as unverified until the spike confirms: PHP floor, Symfony major version, Doctrine ORM version, Node/Encore toolchain, and any required PHP extensions (intl, gd/imagick are common in CMS stacks). The asset pipeline is the most likely silent failure point — a PHP install can succeed while the admin UI is unusable because Encore never built.

Sequencing. Isolated spike (1–2 weeks) → content-modeling proof against real editorial requirements → build-vs-buy decision with the Symfony-runtime cost priced in → security and license review (MIT, permissive — low friction) → pilot in a single bounded content domain → broader rollout. Gate the build-vs-buy decision on the spike, not on this README.

Operational Impact

Maintenance. Ownership sits upstream. Your team's maintenance burden is: tracking core releases, re-resolving the lockfile, and testing upgrades — plus the residual risk of waiting on upstream for fixes you cannot ship yourself. Budget for a named owner who reads the main repository's releases, because this repository will tell you nothing.

Support. No issue tracker, no discussions, no maintainer presence here. Support is either community-forum effort on the main project or a commercial arrangement. Escalation paths must be established contractually before production, not discovered during an incident. Confirm whether the vendor's support tier covers the split artifacts you actually deploy.

Scaling. This bundle is application glue, so horizontal scaling is a property of the deployment, not the package: PHP-FPM workers, Doctrine query and result caching, a shared session/cache store, and page-level caching or a reverse proxy for anonymous traffic. Admin-side scaling is not a concern at typical editorial concurrency. The genuine scaling risk is content-model complexity — heavily nested block structures can produce expensive queries and slow admin renders, and that cost grows with your schema, not your traffic.

Failure modes to instrument for:

• Split drift: the deployed bundle resolves to a version inconsistent with core. Mitigation — pin core, derive the split transitively, and asset-hash the admin build so a mismatch surfaces at deploy.
• Asset pipeline breakage: PHP is healthy, admin UI is blank. Mitigation — build assets in CI, fail the pipeline on build error, smoke-test the admin login post-deploy.
• Upstream stall or abandonment: no releases for an extended window. Mitigation — a documented exit plan; because the license is MIT and the code is vendorable, a hard fork is legally available, though operationally expensive given the monorepo coupling.
• Silent behavioral change in a minor release: no CHANGELOG means no warning. Mitigation — treat every core bump as a regression-test event; maintain a characterization test suite over your content types and admin workflows.
• Mis-pinning this repository directly: a developer adds enhavo/app-bundle to composer.json because it appears in a package index. Mitigation — an allowlist policy and a code-review check on composer.json diffs.

Ramp-up. Non-trivial. Engineers need working Symfony fluency (bundles, DI container, Doctrine, Twig, Encore) before Enhavo-specific concepts — resources, blocks, templates, the admin grid — become learnable. Estimate 2–3 weeks for a competent Symfony developer to reach productive velocity on content modeling, plus additional time for whoever owns the deployment and asset pipeline. If the team is Laravel-only, add framework-transition cost on top, and treat that as the dominant line item in the business case rather than a rounding error.

Bottom line for the decision record: this package should not be adopted as a standalone dependency under any scenario. It is an internal artifact of the Enhavo monorepo, and the only defensible evaluation is of the Enhavo CMS as a whole — a separate decision with a Symfony-runtime prerequisite, a near-absent public adoption signal, and a support posture that must be contractualized before production.