Calendr Bundle Laravel Package

Technical Evaluation

Architecture fit

• Framework mismatch is the headline finding: this is not a Laravel package. frequence-web/calendr-bundle is a Symfony bundle — its entire value-add is a Bundle class, a DI extension for YAML config, and a Twig extension. None of that is consumable by Laravel's service container, config repository, or Blade compiler.
• The underlying library, CalendR, is framework-agnostic PHP. It is the only piece with genuine stack fit; the bundle should be treated as reference implementation and documentation, not as a dependency.
• Fit is therefore moderate for the core library, zero for the package as shipped. Do not add this repository to composer.json of a Laravel application.
• Scope check: CalendR is a rendering and export helper (month/week views, event objects, iCal output, calendar links). It is not a calendaring system — no persistence, no recurrence engine, no invitation/attendee model. Any product expectation beyond "draw a calendar with events and export it" is out of scope and must be built or bought separately.

Integration feasibility

• High-effort-but-low-risk path: depend on CalendR directly, write a ~150-line Laravel service provider, a config file, and one or two Blade components wrapping the renderer.
• Effort is concentrated in presentation, not logic: translating Twig helpers to Blade, mapping config to config/calendar.php, and wiring an Eloquent-backed event provider into CalendR's event-collection interface.
• Key questions for the spike:
  • Which CalendR version and PHP constraint does the bundle pin? Is CalendR itself still released, and does it install cleanly on our PHP 8.x target?
  • Do we actually need server-side HTML rendering, or only iCal/.ics export and calendar deep-links? If the latter, the integration surface shrinks dramatically and CalendR may only be needed for export.
  • Is Twig a hard transitive requirement anywhere, or can it be excluded?
  • What is the license, and are we permitted to fork the thin adapter internally?
  • Does the front-end expect a JS calendar (FullCalendar, etc.)? If so, server-side rendering is duplicated work.

Technical risk

• Abandonment risk: high. 23 stars and 0 dependents is very thin evidence of production use anywhere. Low star count plus zero dependents plus a bundle-era Symfony structure strongly suggests a dormant project. Assume no upstream security patching, no PHP-version maintenance, and no responsiveness to issues.
• Ecosystem-drift risk: Symfony 2.x-era bundles routinely rely on PSR-0 autoloading, deprecated DI patterns, and Twig 1.x APIs. Expect friction the moment it is installed against a modern PHP runtime, even in a scratch project used only for reference.
• Low strategic value: an opportunity score of 13.53 signals this is not a differentiated capability. Spending internal engineering time resurrecting an unmaintained wrapper buys nothing a half-day adapter over the core library would not.
• Hidden complexity risk sits in the domain, not the package: timezones, DST transitions, multi-day and all-day event boundaries, locale-aware week starts, and iCal escaping/line-folding. These are where bugs and support tickets will actually originate, and the bundle provides no coverage of them.

Recommendation: treat as reject the bundle, evaluate the core library. Run a one-day spike against CalendR directly in a Laravel app; if the spike fails on PHP compatibility, fall back to a maintained iCalendar library for export plus a JS calendar for display.

Integration Approach

Stack fit

• Target architecture: laravel/framework (PHP 8.x) + CalendR core + a first-party CalendarServiceProvider + Blade components + an Eloquent-backed event source.
• Do not install the Symfony bundle. Do not install Symfony DI, HttpKernel, or Twig solely to satisfy it — that would drag a parallel framework into the application for one rendering helper.
• Where the bundle's Twig templates and helper signatures are useful, port them once into Blade partials rather than shimming Twig.

Migration path

1. Dependency spike: composer require the CalendR core package in an isolated branch; confirm it resolves and autoloads on our PHP version with no deprecation noise.
2. Adapter layer: a CalendarFactory bound in a service provider that takes config (first day of week, locale, default view, date format) and returns a configured CalendR instance.
3. Event mapping: an interface + Eloquent implementation that converts domain records into CalendR events, keeping the domain model free of library types. This is the seam that makes a later swap cheap.
4. Presentation: Blade component(s) plus a published CSS baseline.
5. Export: iCal and calendar-link generation as a separate, independently testable service.
6. Fallback trigger: if step 1 fails on compatibility, stop and pivot rather than patching vendor code.

Compatibility

• Pin the core library exactly and record the rationale in the ADR; an unpinned dormant dependency is an unowned liability.
• Verify no transitive conflict with nesbot/carbon, illuminate/support, or the i18n extensions we already ship — date libraries collide frequently.
• Confirm locale data availability; CalendR's translations are a common gap for non-English products.
• Check that the library's autoloading (PSR-0 vs PSR-4) does not degrade our optimized Composer autoloader in production.

Sequencing

• Sequence as: spike → adapter + provider → read-only month view → export → write/edit interactions (if any) → front-end decision.
• Gate each step on a demo, not on a document. The first gate — "core library installs and renders on our runtime" — should be answered inside a day.
• Decide the server-render vs JS-calendar question before building Blade components; reversing that later discards most of the work.

Operational Impact

Maintenance

• We own it, permanently. Zero dependents means no upstream constituency to absorb fixes; the practical outcome is an internal fork of both the adapter and, eventually, the core library.
• Budget a standing line item: PHP minor-version bump testing, security triage on a dependency with no security process, and Composer constraint drift.
• Keep the fork as thin as possible and isolated behind the CalendarFactory/event-provider interfaces so replacement cost stays measured in days.

Support

• No vendor support path, no active maintainer responsiveness to assume, no community to escalate to. Internal documentation becomes the sole source of truth — the adapter and the known-bug list must be written by whoever builds it.
• Expect the first support tickets to be timezone and DST reports, not library defects. Pre-empt with test fixtures for DST boundaries, all-day events, and multi-day spans crossing month edges.

Scaling

• Rendering is stateless and CPU-light; horizontal scaling is a non-issue at typical page-view volumes.
• The real scaling constraint is event volume per rendered period. Rendering a month with dense data, or many concurrent calendar page views, means repeated hydration of large event collections. Cache rendered month fragments keyed by period + event-version.
• iCal export is the more likely hot path (clients polling/subscribing); it should be behind a cache and a rate limit, and generated asynchronously if event sets are large.

Failure modes

• Silent wrongness is the dominant risk: off-by-one rendering around month boundaries, DST-shifted event times, locale-inverted week starts, and malformed iCal that only fails inside Outlook or Apple Calendar. These do not throw — they ship.
• PHP deprecation warnings from an unattended dependency can escalate to hard failures on a runtime upgrade, in production, without warning.
• Unpinned transitive date libraries can be bumped by an unrelated composer update and shift output.
• Mitigations: golden-file tests on rendered output and on generated .ics, exact version pins, and a CI job that runs the suite on the next PHP minor ahead of the upgrade.

Ramp-up

• Learning curve is low: CalendR's API is small, and the adapter is a few hundred lines. A mid-level engineer is productive in a day.
• The ramp-up cost is not the library — it is the domain. Allocate the majority of onboarding time to timezone/DST semantics and iCal validation, and pair the first implementation with whoever owns the calendar UI expectations.
• Given the low opportunity score and dormant upstream, keep the team surface deliberately small: one owner, one adapter, one documented fallback.