Calendar Bundle Laravel Package

Technical Evaluation

Architecture fit (TPM read: is this a dependency or a platform decision?)

• This is not a Laravel package, despite how it may surface in a Laravel/PHP package index. enhavo/calendar-bundle is a Symfony bundle and a read-only subtree split of the Enhavo CMS monorepo (enhavo/enhavo). There is no service provider, no Laravel package discovery, and no standalone insertion point in a Laravel application.
• The bundle is coupled to Enhavo's own layers — resource abstraction, Doctrine entities, admin UI asset pipeline, block configuration. It ships value only inside a running Enhavo instance.
• The decision it actually informs is: "Is Enhavo a candidate CMS foundation for us?" Calendar/events is a checklist line inside that platform bet, not a technology choice in its own right. Frame the ticket accordingly so no one scopes it as "evaluate a calendar library."
• A TPM should treat the "Laravel/PHP package" taxonomy as a data-quality defect in the source index, not a signal about the package.

Integration feasibility

• Single viable path: composer require enhavo/calendar-bundle inside a full Enhavo app, or install Enhavo itself and enable the bundle through CMS configuration. Both pull the broader CMS dependency graph.
• Documentation is effectively absent on the split repo — a README stub pointing at the main repository. Feature surface (event model, recurrence, admin screens, iCal export) must be read from source. Plan for source-reading as a work item, not an afterthought.
• Maturity signal is "readme." This is a packaging artifact created to satisfy Composer, not a consumable product with a support story.

Technical risk (inputs for the risk register)

• Adoption concentration: 1 star, 0 dependents, single-vendor stewardship. No external validation of stability, API surface, or security posture.
• Split desync: published package can lag upstream tags; version and BC policy are undocumented on the split.
• Read-only provenance: the team cannot contribute fixes where it consumes them. Any local patch becomes a private fork with ongoing rebase cost.
• Detection gap: security advisories may land against the monorepo name rather than the split package name, so dependency scanning can silently miss this component.
• Blast radius: adopting a calendar feature transitively pulls an entire CMS into the upgrade and attack surface.
• License is MIT — legal risk is low. All risk here is operational and continuity-based.

Key questions to take into the spike

• Are we running, or credibly planning to run, Enhavo CMS? If no, close this out — the evaluation is a non-starter.
• Which Symfony/PHP versions are supported on the branch we would pin, and does the split reliably track upstream releases?
• What is upstream maintainer activity and release cadence over the last 12 months?
• What does the calendar data model cover — recurrence, timezones, iCal/CalDAV interop, multi-calendar, permissions? Where are our gaps?
• Who owns the upgrade path when Enhavo makes a breaking change, and what is our exit trigger?

Integration Approach

Stack fit

• Laravel stack: no fit. Options are (a) decline, (b) run Enhavo as a separate Symfony service and integrate over HTTP, (c) mine the domain model as a design reference and build natively in Laravel. Option (c) is the usual outcome and should be the default recommendation unless Enhavo is strategic for other reasons.
• Symfony without Enhavo: partial fit at best; the bundle's value is bound to Enhavo's resource and admin layers, so isolated reuse is disproportionately expensive.
• Already on Enhavo: natural path — install via Composer, wire the resource and block definitions, exercise the admin UI.

Migration path

• There is no migration path from a Laravel app into this package. Adoption means adopting Enhavo, and the TPM should communicate that as a platform migration, not a library addition — different stakeholders, different timeline, different risk profile.
• Extracting the calendar domain into a framework-agnostic library is a rewrite (decouple resource layer, Doctrine mappings, admin UI), not an integration. Size it as such if anyone proposes it.

Compatibility

• Requires PHP 8.x, Symfony FrameworkBundle, Doctrine ORM, and Enhavo core packages pulled transitively. Pin an explicit version and verify the split's commit matches the intended upstream tag before any commitment — put that verification step in the plan as an explicit gate.

Sequencing for the plan

1. Triage gate (hours): confirm we are or will be an Enhavo shop. If not, close the ticket with the framework-mismatch rationale and move on.
2. Spike (days, timeboxed): stand up a disposable Enhavo sandbox, exercise calendar admin and data model end-to-end, capture the actual feature set in writing.
3. Gap analysis (days): compare captured features against our calendar requirements — recurrence, timezones, exports, API access, permissions.
4. Build-vs-adopt decision: if gaps are material or Enhavo is not otherwise strategic, default to native implementation using this bundle as a reference only.
5. If adopted: lock versions, document the downstream-fork policy, name the upgrade owner, and add the detection-gap mitigation to our dependency scanning before it reaches production.

Operational Impact

Maintenance

• Entirely upstream-driven. The read-only split means local patches require a private fork with continuous rebase cost against a moving CMS monorepo — budget that as standing overhead, not a one-time cost.
• Upgrade cadence is coupled to full Enhavo releases. A calendar fix may arrive bundled with unrelated CMS changes, which inflates regression-testing scope for what looks like a small bump.

Support

• Community-only. Issues route to the main repository; no SLA, no contracted triage, unknown response times. This is a hard stop for anything customer-facing and regulated.
• Onboarding material is absent on the split repo. Institutional knowledge must be built by reading the main repository — plan for that in ramp-up estimates and in the bus-factor mitigation.

Scaling

• CMS calendar implementations typically assume moderate, editorially driven workloads. Query strategy, indexing, and caching for high-volume or public-facing calendar reads are unverified. Require a benchmark against realistic read volume before relying on it for a public calendar surface.

Failure modes to name in the risk register

• Upstream abandonment of Enhavo or the bundle strands us on an unsupported dependency.
• Split desync yields a published package that does not match documented upstream behavior.
• Breaking changes with no documented semver policy, discovered at upgrade time.
• Security advisories missed because they are filed against the monorepo name, not the split package.
• Transitive CMS pull inflates upgrade blast radius and attack surface for a nominally bounded calendar feature.

Ramp-up

• Engineers need Symfony fluency plus Enhavo-specific knowledge (resource layer, admin UI conventions, block configuration). With no docs, expect source-reading time measured in weeks before confident contribution — reflect that in the estimate rather than assuming a library-style afternoon install.
• Recommend a single named owner for the Enhavo dependency and a written exit plan (private-fork criteria, replacement trigger, migration sketch) recorded before any production commitment.

How to pitch this

• Executives: a low-adoption component of an open-source Symfony CMS, not a standalone product. It is evidence that Enhavo covers calendar/event content, and a negative data point on ecosystem maturity. Recommendation: no standalone investment; revisit only inside a broader Enhavo platform evaluation.
• Engineering: read-only upstream artifact — do not fork; contribute upstream. Read source over docs; expect weeks of ramp-up. Zero Laravel integration value.
• Product: calendar and events are table stakes, not differentiation. This raises confidence slightly that Enhavo can host structured date-bound content; it does not justify a platform bet on its own.