Calendar Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for calendar/event functionality. This bundle does not stand alone — it is a read-only subtree split of the Enhavo CMS (a full-stack Symfony product). The decision it actually informs is whether Enhavo is a viable foundation when events, editorial calendars, or date-bound content are one feature among many. Frame the question that way in any roadmap discussion.
• CMS/platform shortlisting. If your roadmap pairs structured content with scheduling or event display, Enhavo's bundle map is evidence that calendar support ships in-scope rather than as a third-party integration. Useful when comparing against Drupal, WordPress, or Sulu on "what's in the box."
• Framework-fit triage (fast kill). Despite being listed as a "Laravel/PHP package," this is Symfony-first: no service provider, no facade, no Laravel package discovery, no config/calendar.php story. That single fact should end any Laravel-native evaluation in the first 15 minutes and save the team a spike.
• Prioritization signal — and a negative one. 1 star, 0 dependents, README-only maturity, and a split repo with no independent docs or issue tracker mean near-zero ecosystem validation. Use it to argue that calendar/events are table stakes, not a differentiation budget line, unless you are already on Enhavo.
• Dependency and vendor-risk accounting. Any plan that says "we'll just vendor this bundle" needs correcting to "we'll adopt Enhavo and consume this bundle transitively," which changes the size, risk, and owner of the commitment.
• Roadmap de-risking via reference design. Even if we never adopt Enhavo, the bundle's domain model (event entities, recurrence, admin CRUD patterns) is a cheap design reference for a native implementation — a research input, not a dependency.

When to Consider This Package

Consider it only when all of the following hold:

• You have already committed to, or are seriously shortlisting, Enhavo CMS on a Symfony stack.
• You need calendar/event content types as part of a broader CMS content model, not as a standalone scheduling engine or iCal library.
• Your team is fluent in Symfony bundles and Composer subtree-split packages, and is willing to read source in the monorepo because standalone documentation does not exist.
• You have a named maintenance owner who will track the upstream enhavo/enhavo repo, since the split has no independent release narrative and is read-only.

Look elsewhere when:

• You are on Laravel. There is no integration value. Evaluate spatie/laravel-google-calendar, framework-native scheduling, or a JS calendar front end instead.
• You need a standalone iCalendar/recurrence library — prefer eluceo/ical, sabre/vobject, or rlanvin/php-rrule, which have real docs, tests, and dependents.
• You need vendor support, SLAs, or a security disclosure process. 1 star and 0 dependents is a hard stop for customer-facing or regulated work.
• You expect calendar UI/UX out of the box — plan for your own front end (FullCalendar et al.) regardless.
• You cannot accept release coupling to an upstream monorepo you do not control.

How to Pitch It (Stakeholders)

Executive summary. This is a small, low-adoption component of the Enhavo CMS, not a product we would adopt on its own merits. Its value to us is twofold: it is evidence that Enhavo covers calendar and event content, and it is a useful negative data point on ecosystem maturity. Recommendation: no standalone investment. Revisit only as one checklist item inside a broader Enhavo platform evaluation, and only if our stack is Symfony.

For engineering. Treat it as a read-only upstream artifact, not a library. Do not fork — contribute to enhavo/enhavo. Budget for source reading over documentation. Flag the framework mismatch loudly: anyone assuming Laravel should be redirected immediately. Confirm supported Symfony/PHP versions on the branch we would pin, and verify the split's commit matches the intended upstream tag before any dependency is recorded.

For product. Calendar and events are table stakes, not differentiation. This package raises confidence slightly that Enhavo can host structured date-bound content, but it does not justify a platform bet by itself. If we shortlist Enhavo, evaluate the CMS as a whole — content modeling, admin UX, upgrade path, community activity — and treat this bundle as a single line on that checklist.

Risk to flag. Single-digit stars, zero dependents, split-repo provenance, no independent docs, and no issue tracker on the published package mean bus-factor and longevity risk sit entirely with the Enhavo maintainers. Security advisories raised against the monorepo may not surface against the split package name, so dependency scanning could miss them. Confirm maintainer activity and release cadence — and write down the replacement trigger — before any production commitment.