Skip to content

architecture-features-modules.md

Latest commit

 

History

History
54 lines (41 loc) · 1.64 KB

architecture-features-modules.md

File metadata and controls

54 lines (41 loc) · 1.64 KB
title packages/features vs apps/web/modules
impact HIGH
impactDescription Wrong placement causes tight coupling and import issues
tags architecture, features, modules, trpc

packages/features vs apps/web/modules

packages/features

The packages/features package should contain only framework-agnostic code:

  • Repositories (data access layer)
  • Services (business logic)
  • Core utilities and helpers
  • Types and interfaces

Files in packages/features/** should NOT import from @calcom/trpc.

apps/web/modules

Web-specific code, particularly anything that uses tRPC, should live in apps/web/modules/...:

  • React hooks that use tRPC queries/mutations
  • tRPC-specific utilities
  • Web-only UI components that depend on tRPC

Example Structure

packages/features/feature-opt-in/
├── repository/
│   └── FeatureOptInRepository.ts    # Data access - OK here
├── service/
│   └── FeatureOptInService.ts       # Business logic - OK here
└── types.ts                          # Types - OK here

apps/web/modules/feature-opt-in/
└── hooks/
    └── useFeatureOptIn.ts           # tRPC hook - MUST be here

Why This Matters

// ❌ Bad - tRPC hook in packages/features
// packages/features/feature-opt-in/hooks/useFeatureOptIn.ts
import { trpc } from "@calcom/trpc/react";

// ✅ Good - tRPC hook in apps/web/modules
// apps/web/modules/feature-opt-in/hooks/useFeatureOptIn.ts
import { trpc } from "@calcom/trpc/react";

This separation ensures that packages/features remains portable and can be used by other apps (like apps/api/v2) without pulling in web-specific dependencies.