Laravel Sabre Laravel Package

Product Decisions This Supports

• CalDAV/CardDAV interoperability roadmap: This package is the adapter layer that lets a Laravel application expose calendars and contacts to native clients (Apple Calendar, Thunderbird, DAVx5, iOS/Android). It directly enables "sync with the calendar/contacts app your users already use" — a recurring roadmap ask for CRM, scheduling, and contact-management products.
• Build vs. buy: The alternative is hand-rolling WebDAV/CalDAV protocol handling or embedding a standalone SabreDAV server outside Laravel. This package is the "buy/adopt" answer: it wraps sabre/dav and owns the Laravel integration surface (routing, auth, middleware, exception handling), so the team writes node/back-end logic rather than protocol plumbing.
• Feature scoping: The 2.0 architecture change — a framework-native request pipeline — is a signal that the integration now behaves like ordinary Laravel HTTP (middleware, request lifecycle, container resolution). That lowers the cost of adding per-user authorization, rate limiting, tenant scoping, and observability to sync endpoints, which are typically the features requested next.
• Upgrade/technical-debt decision: 2.0.0 is a breaking release. This is a scheduled engineering investment, not an incidental bump: it requires an audit of any direct use of LaravelSabre::getNodes(), LaravelSabre::getPlugins(), InvalidStateException, and any code extending Sabre\Server or Sabre\Sapi. Notably, there are no configuration, environment variable, or URL changes, so user-facing behavior and client setup instructions should be unaffected — which makes this a low-product-risk, engineering-effort-only decision.
• Support/deprecation posture: Because the removed elements now have documented replacements in MIGRATION.md, the PM can decide whether to fund the migration now (staying on a supported line) or defer (accepting divergence from upstream). Staying current matters most if CalDAV/CardDAV is a marketed capability rather than a passive feature.

When to Consider This Package

Consider adoption when:

• The product stores or generates calendar events or contacts and users expect two-way sync with native clients rather than a proprietary export/ICS feed.
• The stack is Laravel/PHP and the team wants DAV endpoints to live inside the existing app — same auth, same users table, same deployment — instead of operating a separate DAV service.
• You need standards compliance without owning the spec: sabre/dav handles the protocol; this package handles the Laravel seam.
• You can absorb a major-version upgrade cadence. 2.0.0 is breaking, and the package is maintained in step with a single primary consumer (Monica), so API churn should be expected.

Look elsewhere when:

• You need a standalone, language-agnostic DAV server (e.g., a dedicated Radicale/Baïkal service or a managed calendar backend) — the Laravel coupling is then a liability, not an asset.
• Your sync needs are read-only or one-directional (public ICS subscriptions); full DAV is substantial overkill.
• You depend on the pre-2.0 extension points. If your code subclasses Sabre\Server/Sabre\Sapi or relies on getNodes()/getPlugins(), you must migrate first — and if the replacements in MIGRATION.md don't cover your customization, that is a genuine adoption blocker.
• You require long-term API stability guarantees or vendor support; this is a focused open-source integration, not a platform.

How to Pitch It (Stakeholders)

For executives: This package is what allows our Laravel product to speak the same calendar and contact sync standards as Apple Calendar, Outlook-adjacent clients, and Android — without us building or operating a separate sync service. It is a small, well-scoped dependency that converts a differentiating feature ("your data, in the apps you already use") into an integration task rather than a protocol engineering project.

For engineering: Version 2.0.0 rebuilds the adapter on a framework-native request pipeline, so DAV endpoints now flow through standard Laravel middleware and request handling. This is a breaking release with zero config, environment, or URL changes — user-facing setup and client compatibility should be unchanged. The work is contained to code that touches the removed public surface: LaravelSabre::getNodes(), LaravelSabre::getPlugins(), InvalidStateException, and any direct use of Sabre\Server / Sabre\Sapi, which are now internal. MIGRATION.md documents each removal and its replacement.

Recommendation: Treat 2.0.0 as a planned maintenance item for the next sprint rather than an emergency. First task is a short audit for the four removed elements; second is executing the documented replacements; third is a smoke test of a real CalDAV/CardDAV client against staging to confirm the pipeline rebuild is behavior-neutral. If the audit finds no direct usage, the upgrade is effectively a dependency bump.