refactor: Move trpc-dependent components from features to web [2]

[hbjORbj]

What does this PR do?

This is part 2 of the ongoing refactor to restore proper package layering in the monorepo (see PR #25859 for part 1).

Why this change is needed

@calcom/features is intended to be a reusable shared layer, but several UI components inside it were directly using tRPC client hooks (e.g., trpc.viewer.*.useQuery() from @calcom/trpc/react). This couples the shared package to app-specific data-fetching assumptions, increases the risk of circular dependencies, and makes it harder to reuse features cleanly across web/platform/embed contexts.

The intended layering is: the web app can depend on both @calcom/features and @calcom/trpc, but @calcom/features should not depend on tRPC.

What changed

This is a refactor only with no intended user-facing behavior changes. It primarily moves files and updates imports.

Components moved from packages/features/** to apps/web/modules/**:

• Booker UI and subcomponents (DatePicker, EventMeta, AvailableTimeSlots, BookEventForm, etc.)
• App store UI components (AllApps, AppCard, AppList, etc.)
• Event type UI components (EventType, CreateEventTypeForm, HostEditDialogs, etc.)
• Calendar weekly view components
• EE components (SSO views, directory sync, users admin pages, video)
• Insights components and hooks

Import paths updated throughout the web app to use @calcom/web/modules/** and ~/ aliases.

Shared types (like EventTypeAssignedUsers, EventTypeHosts) moved to @calcom/features/eventtypes/lib/types to keep them accessible without circular dependencies.

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• N/A - I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

3 Skipped Deployments

Project	Deployment	Review	Updated (UTC)
cal	Ignored		Jan 5, 2026 3:12pm
cal-companion	Ignored	Preview	Jan 5, 2026 3:12pm
cal-eu	Ignored		Jan 5, 2026 3:12pm

[cubic-dev-ai]

8 issues found across 86 files

Note: This PR contains a large number of files. cubic only reviews up to 75 files per PR, so some files may not have been reviewed.

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="packages/features/apps/AdminAppsList.tsx">

<violation number="1" location="packages/features/apps/AdminAppsList.tsx:13">
P1: This import introduces a circular dependency. `apps/web` depends on `@calcom/features`, but now `packages/features` imports from `@calcom/web`. Shared packages like `features` should not import from application-level code (`apps/web`). Consider keeping `AppListCard` in `@calcom/features` or moving this entire file to `apps/web/modules` if it needs web-specific components.</violation>
</file>

<file name="packages/platform/atoms/add-members-switch/AddMembersWithSwitchPlatformWrapper.tsx">

<violation number="1" location="packages/platform/atoms/add-members-switch/AddMembersWithSwitchPlatformWrapper.tsx:2">
P1: This import creates a circular dependency. `AddMembersWithSwitch.tsx` in `@calcom/web` imports `AddMembersWithSwitchPlatformWrapper` from `@calcom/atoms`, but now `AddMembersWithSwitchPlatformWrapper` imports back from `@calcom/web`. This can cause undefined exports and runtime initialization issues.

Consider keeping the import from `@calcom/features` (the original path) or restructuring to break the cycle.</violation>
</file>

<file name="packages/features/ee/sso/page/orgs-sso-view.tsx">

<violation number="1" location="packages/features/ee/sso/page/orgs-sso-view.tsx:5">
P1: This import introduces a circular dependency. The `packages/features` package should not import from `@calcom/web` (the web app). Currently there are no such imports in the features package, and `@calcom/web` is not a declared dependency. Consider keeping the SkeletonLoader in `@calcom/features` or moving it to a shared package like `@calcom/ui`.</violation>
</file>

<file name="packages/features/ee/dsync/components/ConfigureDirectorySync.tsx">

<violation number="1" location="packages/features/ee/dsync/components/ConfigureDirectorySync.tsx:3">
P1: Circular dependency risk: `packages/features` should not import from `@calcom/web`. The features package is a shared library consumed by `apps/web`, not the other way around. This import creates a circular dependency path (`web` → `features` → `web`) and `@calcom/web` is not declared as a dependency in `packages/features/package.json`. Consider keeping the SkeletonLoader in the features package or moving this component to web as well.</violation>
</file>

<file name="packages/features/form-builder/FormBuilder.tsx">

<violation number="1" location="packages/features/form-builder/FormBuilder.tsx:10">
P1: This import introduces a circular dependency. `@calcom/web` depends on `@calcom/features`, so importing from `@calcom/web` in `packages/features` creates a cycle (web → features → web). This can cause build failures, runtime errors, or unpredictable behavior.

The `LearnMoreLink` component should remain in a shared package like `@calcom/features` or `@calcom/ui`, not be imported from `apps/web` into a lower-level package.</violation>
</file>

<file name="packages/platform/atoms/event-types/wrappers/CreateEventTypePlatformWrapper.tsx">

<violation number="1" location="packages/platform/atoms/event-types/wrappers/CreateEventTypePlatformWrapper.tsx:3">
P1: This import introduces a circular dependency. The target `CreateEventTypeForm` in `@calcom/web` imports `useIsPlatform` from `@calcom/atoms`, while this file (part of `@calcom/atoms`) is now importing from `@calcom/web`. Consider either keeping the import from `@calcom/features` or restructuring to avoid the circular reference.</violation>
</file>

<file name="packages/features/bookings/components/event-meta/Duration.tsx">

<violation number="1" location="packages/features/bookings/components/event-meta/Duration.tsx:6">
P1: This import introduces a circular dependency. The `packages/features` package is now importing from `@calcom/web`, but `apps/web` depends on `@calcom/features`. Consider moving `useShouldShowArrows` to a shared package like `@calcom/lib` or `@calcom/ui` that both can depend on, rather than importing from `web` into `features`.</violation>
</file>

<file name="packages/platform/atoms/event-types/hooks/useHandleRouteChange.ts">

<violation number="1" location="packages/platform/atoms/event-types/hooks/useHandleRouteChange.ts:7">
P1: This import introduces a dependency from `@calcom/platform/atoms` to `@calcom/web`, which inverts the expected architecture. Platform packages should be standalone and consumed by the web app, not the other way around. Currently, no other platform package imports from `@calcom/web`.

Consider keeping types in a shared location (e.g., `@calcom/features` or a dedicated types package) rather than importing from the web app to avoid potential circular dependencies and maintain proper package boundaries.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[github-actions]

E2E results are ready!

• Workflow #97028.1 latest results

[cubic-dev-ai]

No issues found across 390 files

Note: This PR contains a large number of files. cubic only reviews up to 75 files per PR, so some files may not have been reviewed.