Calendar Bundle Laravel Package

Technical Evaluation

• Architecture fit: tattali/CalendarBundle remains a Symfony-heritage calendar/event bundle (RequestParser, controller, serializer, listeners) rather than a native Laravel package. v8.3.0 widens scope: it now mandates Symfony 8 and PHP 8.4+, adds GET support on the events feed with private ETag revalidation, FullCalendar timeZone support, and an immutable-date model across the Event constructor, setters, getters, and listener payloads. Laravel fit still requires a wrapper or manual service binding, but the new interface aliases (#146) make container wiring slightly more predictable if we alias the parser/serializer interfaces ourselves.
• Integration feasibility: Still Composer-based, but no longer a low-effort trial. This is a platform jump (PHP 8.4, Symfony 8) plus a contract change (ISO 8601-only dates, immutable date types, final classes). Feasibility hinges on whether our Laravel runtime can move to PHP 8.4 in the same window and whether any of our code extends or mocks the now-final parser, serializer, or bundle exception classes.
• Technical risk: High relative to v8.2.1. Multiple breaking surfaces: (1) constructor/setter signatures now accept DateTimeInterface and an allDay argument, and the constructor passes given dates straight to setters (#145) — subclasses or factories overriding setters may see different behavior; (2) getters return immutable dates and listeners receive immutable request dates (#143/#144) — any code calling mutable methods (modify(), setDate()) on returned objects will now fail or silently get new instances; (3) only ISO 8601 start/end dates accepted (#149) — free-form or locale-formatted date strings from existing clients will be rejected; (4) final classes break extension, decoration-via-inheritance, and PHPUnit mocking; (5) PHP 8.4 / Symfony 8 minimums. Behavioral risk is not confined to one endpoint as in v8.2.1 — it touches the whole date model.
• Key questions: Are we on v8.2.x in production or still evaluating? Can the Laravel app run PHP 8.4 and Symfony 8 components on its target Laravel version? Do we extend, decorate, or mock RequestParser, the serializer, or bundle exceptions anywhere (now final)? Does any internal code mutate dates returned from Event getters or from listeners? Do our clients always send ISO 8601 start/end, and do they send timeZone? Do we want the new GET-with-ETag feed behavior, and does our caching layer honor private ETags / If-None-Match? Are listeners typed against DateTimeInterface or concrete mutable DateTime? Has each step in docs/upgrade-to-83.md been mapped to a test?

Integration Approach

• Stack fit: PHP/Composer and Symfony components still fit Laravel structurally, but the Symfony 8 requirement is the binding constraint — verify it against the Laravel and PHP versions we actually run before scoping anything else. The interface aliases (#146) are a small win: we can bind our own parser/serializer implementations in a Laravel service provider instead of relying on bundle internals.
• Migration path: Do not treat this as a patch bump. Read docs/upgrade-to-83.md and apply its Migration Steps one-for-one as tracked work items (#151 explicitly enumerates them). Recommended path: v8.2.1 → PHP 8.4 runtime upgrade → Symfony 8 components → v8.3.0 on a branch, with the date-model changes (ISO 8601 validation, immutable getters, allDay arg, DateTimeInterface setters) covered by tests before staging. If we are still evaluating and not yet in production, start at v8.3.0 and avoid inheriting the migration entirely.
• Compatibility: Confirm PHP 8.4 and Symfony 8 constraints against composer.json and the Laravel version’s Symfony component range; a mismatch here blocks everything else. Audit for extends/final conflicts on the parser, serializer, and exception classes, and for test doubles of those types. Verify Mockery/PHPUnit mocking strategy is replaced with interface-based fakes. Confirm Laravel middleware preserves the POST body (still relevant from v8.2.1) and that ETag/If-None-Match headers survive our reverse proxy and cache layers for the new GET feed.
• Sequencing: 1) run composer why-not / constraint analysis for PHP 8.4 and Symfony 8; 2) inventory all RequestParser, serializer, Event, and listener touchpoints; 3) remove or refactor inheritance and mocks against now-final classes; 4) normalize all client-supplied dates to ISO 8601 and add timeZone support where the front end needs it; 5) migrate date handling to DateTimeInterface/immutable semantics in app code; 6) deploy v8.3.0 to staging behind the existing calendar endpoints and run ETag revalidation tests; 7) production canary with 4xx/5xx and cache-hit monitoring; 8) update API docs for ISO 8601-only dates, allDay, timeZone, and GET feed semantics.

Operational Impact

• Maintenance: Higher than the v8.2.1 patch. We now own a PHP 8.4 / Symfony 8 upgrade track plus an internal adapter layer that must track bundle API changes across a breaking minor. Budget recurring effort for constraint bumps and for re-validating the date contract each release.
• Support: Still community-supported upstream with no commercial SLA, but the blast radius of a bad upgrade is larger: date parsing and immutability affect every event read/write path. Internal support must own the ISO 8601 contract, the timeZone/allDay semantics, and ETag behavior for the GET feed.
• Scaling: Parsing overhead remains negligible. Immutable dates add small object-allocation churn, which is irrelevant at typical calendar volumes. The new GET feed with private ETag revalidation can reduce load if clients and intermediaries honor If-None-Match; if they don’t, expect flat or slightly higher request volume on the feed endpoint.
• Failure modes: Non-ISO 8601 dates rejected at the parser (#149) — the most likely production break. Mutable-date assumptions in app code throwing or producing stale objects after getters return immutable instances (#143/#144). Fatal errors from extending final classes or mocking them in tests. composer update failing on PHP 8.4 / Symfony 8 constraints mid-sprint. allDay and timeZone mishandled if clients send them but our serializer/adapter drops them. Cache correctness issues if private ETags leak across users. Rollback to v8.2.1 is possible only if the PHP 8.4 / Symfony 8 runtime changes are also reverted — plan the rollback as a coordinated revert, not a single Composer pin.
• Ramp-up: Moderate-to-high. Developers need familiarity with immutable date semantics, Symfony 8 container aliasing, and ETag revalidation in addition to Composer and Laravel request handling. Run the upgrade guide as a team walkthrough before implementation and document the ISO 8601-only, allDay, and timeZone contracts ahead of rollout.