TRPC Package

Purpose and Scope

The @calcom/trpc package is the monorepo’s shared tRPC boundary for code that needs typed client/server communication without each application wiring the tRPC dependency stack independently. In Cal.diy’s self-hosted scheduling platform, tRPC sits alongside Next.js, React, Prisma, and other workspace packages as part of the application foundation. This page is for maintainers who need to understand which imports are public, which imports are intentionally client-only, and how the package separates React-facing code from server-facing builds.

Sources: packages/trpc/package.json, packages/trpc/index.ts

The package is private to the repository and is described in its manifest as a shared tRPC library for Cal.diy. That means the supported consumer is another workspace package or app, not an external npm installation workflow. The manifest sets main to index.ts, but that root entrypoint does not currently export a general API. Instead, it documents a deliberate import rule: React exports have moved to @calcom/trpc/react, and client-side code should import from that subpath rather than @calcom/trpc.

Cal.diy is community-maintained and intended for self-hosted, non-production personal use in the project’s first-party documentation. Treat this package as internal infrastructure for that self-hosted monorepo rather than as a stable public SDK.

Relevant Source Files

• packages/trpc/package.json — Defines the package name, build scripts, dependency stack, peer dependencies, and package metadata for @calcom/trpc.
• packages/trpc/index.ts — Documents the root-entrypoint policy and directs client-side consumers to @calcom/trpc/react.
• packages/trpc/react/index.ts — Provides the visible React entrypoint by exporting router input/output types, the trpc client surface, the serialization transformer, and endpoint constants.
• packages/trpc/server/adapters/next.ts — Re-exports the official Next.js adapter from @trpc/server/adapters/next for server-side Next integration.

Public Entrypoints

The root entrypoint exists primarily as a guardrail. Its comments say React exports were moved to @calcom/trpc/react, and they explain why: keeping client code out of server builds improves build performance by preventing server builds from traversing client-side code. When adding new imports, use the subpath that matches the runtime you are targeting. Server-side code should not reach into the React entrypoint just because it needs a type or helper, because that reintroduces the coupling the package is explicitly trying to avoid.

Sources: packages/trpc/index.ts, packages/trpc/react/index.ts

The React entrypoint exposes a compact surface: RouterInputs, RouterOutputs, trpc, transformer, and ENDPOINTS. RouterInputs and RouterOutputs are type exports, which lets application code type procedure arguments and responses without duplicating router schema information. trpc is the runtime client surface imported from the package’s internal React implementation. transformer is exported with it so clients and server responses can agree on serialization behavior. ENDPOINTS gives React consumers shared endpoint constants rather than hard-coded strings scattered through feature code.

The server adapter entrypoint is intentionally thin. It re-exports everything from @trpc/server/adapters/next, allowing monorepo consumers to import the Next adapter through the Cal.diy package namespace. This keeps the dependency surface centralized while preserving the upstream adapter API. Because the file is a pure re-export, behavior such as request handling, context wiring, and Next.js adapter semantics remain those of @trpc/server; the Cal.diy package is providing a stable internal import path rather than replacing the adapter implementation.

Sources: packages/trpc/server/adapters/next.ts, packages/trpc/package.json

Compact API Reference

// Client-side React code should use the React subpath.
import { trpc, transformer, type RouterInputs, type RouterOutputs, ENDPOINTS } from "@calcom/trpc/react";
 
// Next.js server adapter consumers can import through the Cal.diy package path.
import { createNextApiHandler } from "@calcom/trpc/server/adapters/next";

The manifest shows the concrete dependency contract behind these imports. Runtime dependencies include @trpc/client, @trpc/next, @trpc/react-query, and @trpc/server, all pinned to the same 11.0.0-next-beta.222 version in the supplied package manifest. Supporting dependencies include superjson, zod, cookie, uuid, @calcom/i18n, and @formbricks/api. Peer dependencies require React Query 5, Next.js 14 or newer, and React/React DOM 18 or 19, which is important when aligning workspace apps with the package.

Sources: packages/trpc/package.json

Build and Dependency Model

The package’s scripts show two separate TypeScript build targets: build:server runs tsc with tsconfig.server.json, and build:react runs tsc with tsconfig.react.json. The combined build script runs both. That split reinforces the import boundary shown in index.ts: server and React compilation are separate concerns, and accidental traversal from one side into the other is something the package authors actively avoid. Maintainers should preserve this separation when adding exports, moving files, or introducing new dependencies.

Sources: packages/trpc/package.json, packages/trpc/index.ts

The manifest also marks the package as sideEffects: false. In practical terms, consumers and bundlers can treat imports from this package as tree-shakeable when the imported modules themselves are safe to eliminate. That setting makes the explicit entrypoint design more valuable: a React application can import the React subpath it needs, while server-only code can remain focused on server adapters and avoid client dependency traversal. Do not add import-time global initialization to public entrypoints without revisiting that side-effect contract.

Linting is handled with Biome through lint and lint:fix, and TypeScript is present as a development dependency. This is a small but useful signal for contributors: changes to this package should be validated as TypeScript library changes, not only by running an application manually. Because the package participates in a larger Turborepo workspace, an entrypoint change can affect multiple apps even when the edited file is only a few lines long. Prefer narrow exports and keep runtime-specific dependencies behind runtime-specific subpaths.

System-to-Code Mapping

Use packages/trpc/react/index.ts when a React component or hook layer needs typed tRPC access. That file is the public client entrypoint in the supplied evidence, so it is the right place to check before reaching into deeper internal files. Use packages/trpc/server/adapters/next.ts when a Next.js server integration needs the upstream tRPC Next adapter through the workspace namespace. Use packages/trpc/index.ts as a policy file: it tells you what not to import for client-side code and why the package root should stay lightweight.

Sources: packages/trpc/react/index.ts, packages/trpc/server/adapters/next.ts, packages/trpc/index.ts

For maintainers, the most important design constraint is that @calcom/trpc is not a dumping ground for every tRPC helper. The root entrypoint’s comments make a build-performance decision visible to future contributors. If a new helper is React-specific, add or expose it from the React subpath. If it is server-specific, keep it on the server side. If it is shared type-only surface, be careful that the export does not force a server build to load React modules or a client build to load server-only modules.

Testing Signals and Next Steps

The supplied package manifest does not define a package-local test script, but it does define lint and build scripts that are appropriate first checks after editing this package. Run the relevant TypeScript build target for the surface you changed, and run Biome linting before opening a pull request. A change to packages/trpc/react/index.ts should be validated against React consumers, while a change to the Next adapter re-export should be validated against server routes or API handlers that depend on the adapter import path.

Sources: packages/trpc/package.json

Next, read the API v2 pages to understand how Cal.diy exposes service APIs, and read the monorepo architecture page to see how workspace package scripts fit into the root Turborepo workflow. When changing this package, keep imports boring and explicit: client code imports from @calcom/trpc/react, server adapter code imports from @calcom/trpc/server/adapters/next, and the package root remains a lightweight boundary that protects server builds from client-side traversal.