PSA/ee/docs/plans/2026-03-10-ee-packages-relocation-calendar-teams/PRD.md

PRD — EE Packages Relocation for Calendar and Teams

• Slug: ee-packages-relocation-calendar-teams
• Date: 2026-03-10
• Status: Draft

Summary

Move live enterprise calendaring code and live Microsoft Teams code out of packages/ee and into first-class enterprise workspace packages under ee/packages/. The target layout is ee/packages/calendar for enterprise calendaring and ee/packages/microsoft-teams for enterprise Teams functionality, with packages/ee reduced to CE stubs and temporary compatibility forwarders only where the CE/EE boundary requires them.

This is a follow-on packaging and topology plan, not a product-scope plan. It supports the previously planned and partially implemented enterprise-only calendar and Teams work by correcting where the live enterprise code lives and how it is resolved by builds, tests, and shared entrypoints.

Problem

The repo currently mixes three concerns across packages/ee, ee/server/src, and shared packages:

• CE stub behavior used to compile Community Edition
• thin EE entrypoints used by Next routes/pages
• live enterprise runtime, actions, services, and UI for calendaring and Teams

That arrangement has already caused drift where the runtime alias path terminates in placeholder files under packages/ee/src while the real implementation lives elsewhere. The result is an unreliable enterprise boundary: some code paths execute real EE logic, some paths hit stubs, and tests/typecheck can validate the wrong source tree.

ee/packages/ already exists in the workspace and is the correct home for enterprise-owned packages. Calendaring and Teams should use that structure rather than continuing to grow inside packages/ee.

Goals

• Create a real enterprise calendaring package at ee/packages/calendar.
• Create a real enterprise Microsoft Teams package at ee/packages/microsoft-teams.
• Move live enterprise calendar and Teams actions, components, libs, services, and route-handler logic into those packages.
• Leave packages/ee as CE stub and compatibility infrastructure only for calendar and Teams.
• Rewire shared callers, EE route/page entrypoints, and build/test config so they resolve the new package surfaces instead of packages/ee live code.
• Keep the package migration scoped to calendaring and Teams; do not turn this into a repo-wide packages/ee elimination effort.
• Preserve current CE behavior, current EE feature gating, and current product behavior while changing package ownership.

Non-goals

• Moving every enterprise feature out of packages/ee.
• Redesigning calendar sync product behavior, Teams product behavior, or Microsoft profile behavior.
• Re-scoping Entra, inbound email, licensing, chat, extensions, or other unrelated enterprise domains.
• Changing tenant-facing rollout rules, feature flags, or permissions beyond what is required to preserve current behavior after the move.
• Removing packages/ee entirely in this plan.

Users and Primary Flows

Primary users are internal engineers and CI/build systems. End users are affected indirectly because enterprise calendaring and Teams runtime must keep working after the package move.

Primary flows:

• An EE build compiles calendaring from ee/packages/calendar and Teams from ee/packages/microsoft-teams.
• Shared CE and shared package callers still compile because stub/delegator boundaries remain intact.
• CE runtime still returns calendar/Teams unavailable behavior where appropriate and never loads live EE code.
• EE Next route/page entrypoints remain thin and delegate into the enterprise packages rather than owning duplicated business logic.
• Vitest, TypeScript, and workspace tooling resolve the correct enterprise source roots for calendar and Teams instead of drifting between packages/ee and ee/server/src.

UX / UI Notes

This is not a user-facing redesign. UI parity is the requirement.

• Existing EE calendar settings UI and profile calendar UI should render from the new calendar package without changing their user-facing behavior.
• Existing EE Teams settings UI and Teams tab/bot/message-extension behavior should render from the new Teams package without changing product scope.
• CE should continue to see the same unavailable or hidden surfaces it sees today after the recent EE boundary work.

Requirements

Functional Requirements

• ee/packages/calendar must become the source of truth for enterprise calendar code.
• ee/packages/microsoft-teams must become the source of truth for enterprise Teams code.
• New enterprise packages must expose stable entrypoints for actions, components, libs, and server handlers needed by shared packages and ee/server.
• packages/ee must not remain the live implementation location for calendar or Teams after the migration.
• Shared package imports that currently depend on @enterprise/* calendar or Teams paths must be migrated to explicit package entrypoints or thin compatibility forwarders that terminate in the new packages.
• EE route/page files under ee/server/src/app/... may remain as framework entrypoints, but their implementation logic must delegate into the new packages.
• CE stub files may remain under packages/ee/src, but only as stubs or temporary forwarders; they must not own live calendar or Teams business logic.
• Build and test aliasing must distinguish between live EE packages and CE stubs without relying on the old omnibus packages/ee layout.
• Existing feature gating for enterprise calendar and Teams must remain unchanged by the package move.
• Workspace package metadata, exports, lint/typecheck targets, and dependency wiring must be valid for the new packages.

Non-functional Requirements

• The migration should minimize churn outside calendaring and Teams.
• The resulting package topology should reduce alias ambiguity rather than adding more ad hoc mappings.
• The plan should prefer explicit package imports over deep filesystem imports.
• The migration should preserve current runtime behavior for CE and EE.
• The plan should keep CI/typecheck/test verification practical and domain-scoped.

Data / API / Integrations

No new product data model is introduced. Existing schema and API behavior for calendar and Teams remain as-is.

Relevant technical surfaces that must be re-homed or rewired:

• Enterprise calendar actions and services
• Enterprise Teams actions and package-generation logic
• Enterprise Teams notification delivery
• Enterprise Teams auth/provider resolution helpers
• Enterprise calendar OAuth callbacks and webhook handlers
• Enterprise Teams tab, bot, message extension, and quick-action handlers
• Enterprise settings/profile components for calendar and Teams

Shared Microsoft profile infrastructure remains shared and is not itself moved by this plan.

Security / Permissions

No permission model changes are intended.

• CE must continue to fail closed and must not accidentally load live EE calendar or Teams code because of alias drift.
• EE must continue to enforce the same tenant/user/feature-flag gating already implemented for calendar and Teams.
• Compatibility forwarders must not create alternate bypass paths around edition checks.

Observability

This plan does not add new observability scope. Existing logging and error behavior should remain intact after relocation.

The main engineering requirement is verification coverage that proves build, routing, and stub/delegation behavior still work after the move.

Rollout / Migration

This is an internal topology migration with no tenant rollout.

Migration shape:

1. Create ee/packages/calendar and ee/packages/microsoft-teams as real workspace packages.
2. Move live enterprise implementation code into those packages.
3. Rewire ee/server entrypoints and shared package imports to the new package entrypoints.
4. Reduce packages/ee calendar and Teams files to CE stubs or temporary compatibility forwarders only.
5. Update aliasing, test config, and workspace metadata so calendar and Teams no longer depend on packages/ee as their live implementation location.
6. Remove obsolete duplicated files and deep import paths once the new package graph is stable.

This plan intentionally does not attempt a one-shot migration of all other packages/ee content.

Open Questions

• Should @enterprise/* remain as a long-lived compatibility alias for migrated calendar and Teams surfaces, or should those imports be fully replaced with direct package entrypoints during this migration?
• Should the new package names be exposed only through workspace path aliases initially, or through stable package names consumed directly by shared code from day one?

Acceptance Criteria (Definition of Done)

• Live enterprise calendaring implementation no longer lives in packages/ee.
• Live enterprise Microsoft Teams implementation no longer lives in packages/ee.
• ee/packages/calendar and ee/packages/microsoft-teams exist as workspace packages with valid exports and project metadata.
• ee/server calendar and Teams route/page entrypoints delegate into the new packages rather than owning duplicated implementation logic.
• Shared callers no longer rely on packages/ee as the live calendar or Teams runtime source.
• packages/ee calendar and Teams files are limited to CE stubs or temporary compatibility forwarders.
• CE behavior remains unchanged and fails closed.
• EE behavior remains functionally equivalent for calendar and Teams after the relocation.
• Targeted typecheck and test coverage validate the new package graph, aliasing, and CE/EE boundary behavior.