packages/lib/di/modules/CheckBookingAndDurationLimits.ts (2)

15-19: Make the wrapper readonly to prevent accidental mutation.

Add as const to narrow types and freeze shape.

-export const checkBookingAndDurationLimitsModuleWithToken = {
+export const checkBookingAndDurationLimitsModuleWithToken = {
   token,
   moduleToken,
   module: checkBookingAndDurationLimitsModule,
-};
+} as const;

Nit: consider using the same DI_TOKENS import style used elsewhere (absolute alias) for consistency.

---

15-19: Centralize the wrapper shape.

Define and reuse a shared ModuleWithToken type to standardize these objects across modules.

Example (in a common DI file):

export type ModuleWithToken = Readonly<{
  token: symbol;
  moduleToken: symbol;
  module: ReturnType<typeof createModule>;
}>;

Then annotate:

export const checkBookingAndDurationLimitsModuleWithToken: ModuleWithToken = { ... } as const;

packages/lib/di/modules/Cache.ts (1)

15-19: Harden the wrapper by marking it readonly.

-export const cacheModuleWithToken = {
+export const cacheModuleWithToken = {
   token,
   moduleToken,
   module: cacheModule,
-};
+} as const;

packages/lib/di/modules/CheckBookingLimits.ts (2)

6-11: Add a minimal compile-time guard on dep keys.

Mirror the pattern used in other modules by asserting the dep-map keys.

-  .bind(token)
-  .toClass(CheckBookingLimitsService, { bookingRepo: DI_TOKENS.BOOKING_REPOSITORY });
+  .bind(token)
+  .toClass(
+    CheckBookingLimitsService,
+    { bookingRepo: DI_TOKENS.BOOKING_REPOSITORY } as const satisfies Record<"bookingRepo", symbol>,
+  );

---

13-17: Mark the wrapper as const for safety and consistency.

-export const checkBookingLimitsModuleWithToken = {
+export const checkBookingLimitsModuleWithToken = {
   token,
   moduleToken,
   module: checkBookingLimitsModule,
-};
+} as const;

packages/prisma/prisma.module.ts (2)

8-10: Use the local token alias in the binding for consistency.

-const token = DI_TOKENS.PRISMA_CLIENT;
+const token = DI_TOKENS.PRISMA_CLIENT;
 const moduleToken = DI_TOKENS.PRISMA_MODULE;
-prismaModule.bind(DI_TOKENS.PRISMA_CLIENT).toFactory(() => prisma, "singleton");
+prismaModule.bind(token).toFactory(() => prisma, "singleton");

---

13-17: Apply as const to the wrapper.

-export const prismaModuleWithToken = {
+export const prismaModuleWithToken = {
   token,
   moduleToken,
   module: prismaModule,
-};
+} as const;

packages/lib/di/modules/Booking.ts (2)

9-9: Optional: prefer named deps over positional array (if supported).

Positional arrays couple binding to constructor order. A named map is more resilient to constructor changes.

---

11-15: Freeze the wrapper with as const.

-export const bookingRepositoryModuleWithToken = {
+export const bookingRepositoryModuleWithToken = {
   token,
   moduleToken,
   module: bookingRepositoryModule,
-};
+} as const;

packages/lib/di/modules/Features.ts (2)

9-9: Prefer using the new type-safe binder + export a loadDeps to preload Prisma.

Leverage bindModuleToClassOnToken for compile-time validation and to auto-generate a deps loader. This keeps the module consistent with others (e.g., RegularBookingService). Adjust the deps key to match FeaturesRepository['deps'].

Example refactor:

 import { DI_TOKENS } from "@calcom/lib/di/tokens";
+import { bindModuleToClassOnToken } from "@calcom/lib/di/ioctopus";
+import { prismaModuleWithToken } from "@calcom/prisma/prisma.module";

 export const featuresRepositoryModule = createModule();
 const token = DI_TOKENS.FEATURES_REPOSITORY;
 const moduleToken = DI_TOKENS.FEATURES_REPOSITORY_MODULE;
-featuresRepositoryModule.bind(token).toClass(FeaturesRepository, [DI_TOKENS.PRISMA_CLIENT]);
+export const loadDeps = bindModuleToClassOnToken({
+  module: featuresRepositoryModule,
+  token,
+  classs: FeaturesRepository,
+  depsMap: {
+    // Replace 'prisma' key if FeaturesRepository.deps uses a different key name
+    prisma: prismaModuleWithToken,
+  },
+});

---

11-15: Add a shared type for the wrapper to enforce shape.

Export and reuse a ModuleWithToken type (e.g., from @calcom/lib/di/ioctopus) to catch shape drift across modules.

packages/lib/di/ioctopus.ts (4)

24-37: Dial down library-wide console noise; gate logs behind an option.

Unconditional console.log in a shared lib is noisy and may leak internals. Make logging opt-in and switch to console.debug.

Apply:

-  return function loadDeps(container: Container) {
-    console.log("[DI DEBUG] Binding Class to token", token);
-    console.log("[DI DEBUG] Deps Object", depsObject);
-    console.log("[DI DEBUG] Bound Class to token", token);
+  return function loadDeps(container: Container, opts?: { debug?: boolean }) {
+    if (opts?.debug) console.debug("[DI DEBUG] Binding Class to token", token);
+    if (opts?.debug) console.debug("[DI DEBUG] Deps Object", depsObject);
+    if (opts?.debug) console.debug("[DI DEBUG] Bound Class to token", token);
 
-    for (const key in depsMap) {
-      const depToken = depsMap[key as keyof typeof depsMap].moduleToken;
-      const depModule = depsMap[key as keyof typeof depsMap].module;
-      console.log("[DI DEBUG] Loading dependency", depToken, depModule);
-      container.load(depToken, depModule);
-      console.log("[DI DEBUG] Successfully loaded dependency", depToken);
-    }
-    console.log("[DI DEBUG] All dependencies loaded for token", token);
+    for (const { moduleToken: depToken, module: depModule } of Object.values(depsMap)) {
+      if (opts?.debug) console.debug("[DI DEBUG] Loading dependency", depToken);
+      container.load(depToken, depModule);
+      if (opts?.debug) console.debug("[DI DEBUG] Successfully loaded dependency", depToken);
+    }
+    if (opts?.debug) console.debug("[DI DEBUG] All dependencies loaded for token", token);
   };

---

16-19: Introduce and reuse a ModuleWithToken type for stronger typing.

This avoids repeating the shape and keeps modules consistent.

Apply:

 import type { Container, Module } from "@evyweb/ioctopus";
 
+export type ModuleWithToken = {
+  token: string | symbol;
+  moduleToken: string | symbol;
+  module: Module;
+};
+
 ...
   depsMap: Record<
     keyof InstanceType<TClass>["deps"],
-    { token: string | symbol; moduleToken: string | symbol; module: Module }
+    ModuleWithToken
   >;

---

7-20: Optional: tighten type constraint on classes expected to have deps.

If all participating classes expose deps, constrain TClass to improve errors when misused. Keep as an overload to avoid breaking existing callers.

Example overload:

type HasDeps = { deps: Record<string | number | symbol, unknown> };
export function bindModuleToClassOnToken<TClass extends new (...args: any[]) => any>(args: {
  module: Module; token: string | symbol; classs: TClass; depsMap: Record<keyof InstanceType<TClass>["deps"], ModuleWithToken>;
}): (container: Container, opts?: { debug?: boolean }) => void;
// Stricter version:
export function bindModuleToClassOnToken<TClass extends new (...args: any[]) => HasDeps>(args: {
  module: Module; token: string | symbol; classs: TClass; depsMap: Record<keyof InstanceType<TClass>["deps"], ModuleWithToken>;
}): (container: Container, opts?: { debug?: boolean }) => void;

---

29-35: Avoid for..in on objects with unknown prototypes.

Swapping to Object.values(depsMap) prevents accidental iteration over inherited props.

packages/features/bookings/lib/di/containers/RegularBookingServiceContainer.ts (1)

17-17: Load dependencies once at module init, not on every call.

Calling loadDeps per invocation can repeatedly call container.load, which may be non-idempotent and adds overhead.

Apply:

-export function getRegularBookingService(): RegularBookingService {
-  loadRegularBookingServiceModuleDeps(regularBookingServiceContainer);
+// Preload deps once
+loadRegularBookingServiceModuleDeps(regularBookingServiceContainer);
+
+export function getRegularBookingService(): RegularBookingService {

And remove the now-redundant call inside the function.

-  loadRegularBookingServiceModuleDeps(regularBookingServiceContainer);

packages/features/bookings/lib/di/modules/RegularBookingServiceModule.ts (5)

15-16: Narrow token types with as const (optional).

Helps keep literal types and catch mismatches at compile time.

-const token = DI_TOKENS.REGULAR_BOOKING_SERVICE;
-const moduleToken = DI_TOKENS.REGULAR_BOOKING_SERVICE_MODULE;
+const token = DI_TOKENS.REGULAR_BOOKING_SERVICE as const;
+const moduleToken = DI_TOKENS.REGULAR_BOOKING_SERVICE_MODULE as const;

---

20-20: "classs" reads like a typo—prefer klass or ctor for clarity.

If bindModuleToClassOnToken accepts an alias, consider this rename to avoid confusion; otherwise, ignore.

-  classs: RegularBookingService,
+  klass: RegularBookingService,

---

21-28: Freeze depsMap literal for stronger inference.

Adding as const preserves key literals and prevents accidental mutation.

   depsMap: {
     cacheService: cacheModuleWithToken,
     checkBookingAndDurationLimitsService: checkBookingAndDurationLimitsModuleWithToken,
     prismaClient: prismaModuleWithToken,
     bookingRepository: bookingRepositoryModuleWithToken,
     featuresRepository: featuresRepositoryModuleWithToken,
     checkBookingLimitsService: checkBookingLimitsModuleWithToken,
-  },
+  } as const,

---

31-35: Type-guard the WithToken object.

Lock it down with as const (and optionally satisfies a common ModuleWithToken shape if available).

-const regularBookingServiceModuleWithToken = {
+const regularBookingServiceModuleWithToken = {
   token,
   moduleToken,
   module: regularBookingServiceModule,
-};
+} as const;

Optionally, if a helper type exists:

const regularBookingServiceModuleWithToken = {
  token,
  moduleToken,
  module: regularBookingServiceModule,
} satisfies ModuleWithToken;

---

31-35: Inline-export the WithToken object to reduce export churn (optional).

Keeps declaration and export together; minor readability win.

-const regularBookingServiceModuleWithToken = {
+export const regularBookingServiceModuleWithToken = {
   token,
   moduleToken,
   module: regularBookingServiceModule,
-};
+};
 
-export { loadDeps, regularBookingServiceModuleWithToken };
+export { loadDeps };

Also applies to: 39-39

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

packages/lib/di/modules/Booking.ts (2)

8-11: Good move to localize tokens; consider using the new helper for type-safety

Bindings look fine. To align with the PR’s goal of type-safe wiring, consider replacing manual bind/toClass with the new bindModuleToClassOnToken utility for compile-time checks on deps.

---

12-17: Export a single “WithToken” object (token, moduleToken, module, loadModule) for SSoT

Current export exposes only token and loadModule. Including moduleToken and module prevents drift and matches the standardized shape.

Apply:

-export const moduleLoader = {
-  token,
-  loadModule: function (container: Container) {
-    container.load(moduleToken, bookingRepositoryModule);
-  },
-};
+export const bookingRepositoryModuleWithToken = {
+  token,
+  moduleToken,
+  module: bookingRepositoryModule,
+  loadModule(container: Container) {
+    container.load(moduleToken, bookingRepositoryModule);
+  },
+};
+// Back-compat alias if callers expect `moduleLoader`
+export const moduleLoader = bookingRepositoryModuleWithToken;

packages/lib/di/modules/CheckBookingLimits.ts (2)

11-12: Add a “satisfies” guard to lock deps map to the service’s contract

Mirror the pattern used in CheckBookingAndDurationLimits to avoid runtime key mismatches.

Apply (adjust interface name if different):

-  .bind(token)
-  .toClass(CheckBookingLimitsService, { bookingRepo: DI_TOKENS.BOOKING_REPOSITORY });
+  .bind(token)
+  .toClass(
+    CheckBookingLimitsService,
+    { bookingRepo: DI_TOKENS.BOOKING_REPOSITORY }
+      satisfies Record<keyof ICheckBookingLimitsService, symbol>
+  );

If no interface exists, I can add a minimal ICheckBookingLimitsService type and wire it up. Want me to push that?

---

14-19: Export the unified “WithToken” object (include moduleToken and module)

Brings this module in line with the standardized export shape and prevents token/module divergence.

-export const moduleLoader = {
-  token,
-  loadModule: (container: Container) => {
-    container.load(moduleToken, checkBookingLimitsModule);
-  },
-};
+export const checkBookingLimitsModuleWithToken = {
+  token,
+  moduleToken,
+  module: checkBookingLimitsModule,
+  loadModule(container: Container) {
+    container.load(moduleToken, checkBookingLimitsModule);
+  },
+};
+export const moduleLoader = checkBookingLimitsModuleWithToken;

packages/lib/di/modules/CheckBookingAndDurationLimits.ts (1)

16-21: Standardize on “WithToken” export shape

Expose moduleToken and module alongside token and loadModule for consistency and easier introspection.

-export const moduleLoader = {
-  token,
-  loadModule: (container: Container) => {
-    container.load(moduleToken, checkBookingAndDurationLimitsModule);
-  },
-};
+export const checkBookingAndDurationLimitsModuleWithToken = {
+  token,
+  moduleToken,
+  module: checkBookingAndDurationLimitsModule,
+  loadModule(container: Container) {
+    container.load(moduleToken, checkBookingAndDurationLimitsModule);
+  },
+};
+export const moduleLoader = checkBookingAndDurationLimitsModuleWithToken;

packages/prisma/prisma.module.ts (1)

14-19: Expose read-only client via its own loader and include module/moduleToken for SSoT

Some modules depend on READ_ONLY_PRISMA_CLIENT; giving it a loader keeps the API symmetric and prevents ad-hoc token references. Also export module and moduleToken.

-export const moduleLoader = {
-  token,
-  loadModule: (container: Container) => {
-    container.load(moduleToken, prismaModule);
-  },
-};
+export const prismaModuleWithToken = {
+  token,
+  moduleToken,
+  module: prismaModule,
+  loadModule(container: Container) {
+    container.load(moduleToken, prismaModule);
+  },
+};
+export const moduleLoader = prismaModuleWithToken;
+
+export const readOnlyPrismaModuleLoader = {
+  token: DI_TOKENS.READ_ONLY_PRISMA_CLIENT,
+  loadModule(container: Container) {
+    container.load(moduleToken, prismaModule);
+  },
+};

If you prefer a single export, we can also expose tokens: [DI_TOKENS.PRISMA_CLIENT, DI_TOKENS.READ_ONLY_PRISMA_CLIENT] on prismaModuleWithToken and keep one loader.

packages/lib/di/modules/Features.ts (1)

12-17: Adopt the unified “WithToken” export (add moduleToken and module)

Keeps exports consistent and future-proof.

-export const moduleLoader = {
-  token,
-  loadModule: (container: Container) => {
-    container.load(moduleToken, featuresRepositoryModule);
-  },
-};
+export const featuresRepositoryModuleWithToken = {
+  token,
+  moduleToken,
+  module: featuresRepositoryModule,
+  loadModule(container: Container) {
+    container.load(moduleToken, featuresRepositoryModule);
+  },
+};
+export const moduleLoader = featuresRepositoryModuleWithToken;

packages/features/bookings/lib/di/modules/RegularBookingServiceModule.ts (2)

17-21: Confirm bindModuleToClassOnToken option name: classs

Is the option intentionally spelled classs in the util’s signature? If the util expects klass/classRef/Class, this will fail type-checking at call sites. Please verify the util’s param name and adjust here for consistency.

---

32-35: Export the standardized ModuleWithToken shape (token + moduleToken + module) and alias moduleLoader

Other modules expose a unified object with token, moduleToken, and module, plus a moduleLoader alias. This file currently omits moduleToken and module, and only exports regularBookingServiceModule. For cross-module consistency and single source of truth, export the full shape and an alias.

Apply:

 export const regularBookingServiceModule = {
   token,
+  moduleToken,
+  module: thisModule,
   loadModule,
 };
+
+// For import consistency with other modules:
+export const moduleLoader = regularBookingServiceModule;

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: hariombalhara
PR: calcom/cal.com#23541
File: packages/features/bookings/lib/di/modules/RegularBookingServiceModule.ts:22-28
Timestamp: 2025-09-03T09:52:51.149Z
Learning: The IBookingServiceDependencies interface in packages/features/bookings/lib/handleNewBooking.ts contains 6 properties: cacheService, checkBookingAndDurationLimitsService, prismaClient, bookingRepository, featuresRepository, and checkBookingLimitsService. This interface is used by RegularBookingService and matches the depsMap structure in RegularBookingServiceModule.

Learnt from: hariombalhara
PR: calcom/cal.com#23541
File: packages/features/bookings/lib/di/modules/RegularBookingServiceModule.ts:22-28
Timestamp: 2025-09-03T09:52:51.149Z
Learning: The IBookingServiceDependencies interface in packages/features/bookings/lib/handleNewBooking.ts contains 6 properties: cacheService, checkBookingAndDurationLimitsService, prismaClient, bookingRepository, featuresRepository, and checkBookingLimitsService. This interface is used by RegularBookingService and matches the depsMap structure in RegularBookingServiceModule.

packages/lib/di/modules/EventType.ts (1)

6-9: Export a standardized moduleLoader to match the new convention.

Per this PR’s objective, modules should export { token, loadModule }. This file currently exposes only eventTypeRepositoryModule. Recommend adding a moduleLoader export (keep the existing export for backwards compatibility).

 export const eventTypeRepositoryModule = createModule();
 eventTypeRepositoryModule
   .bind(DI_TOKENS.EVENT_TYPE_REPOSITORY)
   .toClass(EventTypeRepository, [DI_TOKENS.PRISMA_CLIENT]);
 
+// Standardized loader export to align with repo-wide convention
+export const eventTypeRepositoryModuleLoader = {
+  token: DI_TOKENS.EVENT_TYPE_REPOSITORY,
+  loadModule: async () => eventTypeRepositoryModule,
+};

Please confirm downstream code expects moduleLoader here as with other modules in this PR.

packages/lib/di/modules/Team.ts (1)

6-7: Add moduleLoader export to Team.ts for consistent DI pattern
Other modules under packages/lib/di/modules expose both token and loadModule; Team.ts currently only exports teamRepositoryModule. Retain the existing export for back-compat and append the loader wrapper:

 export const teamRepositoryModule = createModule();
 teamRepositoryModule
   .bind(DI_TOKENS.TEAM_REPOSITORY)
   .toClass(TeamRepository, [DI_TOKENS.PRISMA_CLIENT]);

+// New uniform entrypoint (non-breaking)
+export const moduleLoader = {
+  token: DI_TOKENS.TEAM_REPOSITORY,
+  loadModule: async () => teamRepositoryModule,
+};

packages/lib/di/containers/BookingLimits.ts (2)

12-18: Use moduleLoader.token instead of DI_TOKENS to avoid duplication

Leverage the module’s single source of truth for its token; removes drift risk and matches the standardized moduleLoader shape.

- container.load(DI_TOKENS.PRISMA_MODULE, prismaModule);
- container.load(DI_TOKENS.BOOKING_REPOSITORY_MODULE, bookingRepositoryModule);
- container.load(DI_TOKENS.CHECK_BOOKING_LIMITS_SERVICE_MODULE, checkBookingLimitsModule);
- container.load(
-   DI_TOKENS.CHECK_BOOKING_AND_DURATION_LIMITS_SERVICE_MODULE,
-   checkBookingAndDurationLimitsModule
- );
+ container.load(prismaModule.token, prismaModule);
+ container.load(bookingRepositoryModule.token, bookingRepositoryModule);
+ container.load(checkBookingLimitsModule.token, checkBookingLimitsModule);
+ container.load(
+   checkBookingAndDurationLimitsModule.token,
+   checkBookingAndDurationLimitsModule
+ );

---

20-28: Annotate return types on public getters

Makes the public surface explicit and resilient to inference regressions.

-export function getCheckBookingLimitsService() {
+export function getCheckBookingLimitsService(): CheckBookingLimitsService {
   return container.get<CheckBookingLimitsService>(DI_TOKENS.CHECK_BOOKING_LIMITS_SERVICE);
 }

-export function getCheckBookingAndDurationLimitsService() {
+export function getCheckBookingAndDurationLimitsService(): CheckBookingAndDurationLimitsService {
   return container.get<CheckBookingAndDurationLimitsService>(
     DI_TOKENS.CHECK_BOOKING_AND_DURATION_LIMITS_SERVICE
   );
 }

packages/lib/di/modules/RoutingFormResponse.ts (1)

7-9: Prefer named DI map over positional injection for type-safety.

If the repository supports named deps, switch to an object map with satisfies to catch mismatches at compile time. If not, keep as-is.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: hariombalhara
PR: calcom/cal.com#23541
File: packages/features/bookings/lib/di/modules/RegularBookingServiceModule.ts:22-28
Timestamp: 2025-09-03T09:52:51.182Z
Learning: The IBookingServiceDependencies interface in packages/features/bookings/lib/handleNewBooking.ts contains 6 properties: cacheService, checkBookingAndDurationLimitsService, prismaClient, bookingRepository, featuresRepository, and checkBookingLimitsService. This interface is used by RegularBookingService and matches the depsMap structure in RegularBookingServiceModule.

Learnt from: hariombalhara
PR: calcom/cal.com#23541
File: packages/features/bookings/lib/di/modules/RegularBookingServiceModule.ts:22-28
Timestamp: 2025-09-03T09:52:51.182Z
Learning: The IBookingServiceDependencies interface in packages/features/bookings/lib/handleNewBooking.ts contains 6 properties: cacheService, checkBookingAndDurationLimitsService, prismaClient, bookingRepository, featuresRepository, and checkBookingLimitsService. This interface is used by RegularBookingService and matches the depsMap structure in RegularBookingServiceModule.

Learnt from: supalarry
PR: calcom/cal.com#23217
File: apps/api/v2/src/ee/event-types/event-types_2024_06_14/services/output-event-types.service.ts:93-94
Timestamp: 2025-08-21T13:44:06.805Z
Learning: In apps/api/v2/src/ee/event-types/event-types_2024_06_14/event-types.repository.ts, repository functions that use explicit Prisma select clauses (like getEventTypeWithSeats) are used for specific purposes and don't need to include all EventType fields like bookingRequiresAuthentication. These methods don't feed into the general OutputEventTypesService_2024_06_14 flow.

packages/lib/di/containers/FilterHosts.ts (3)

2-12: Align loads with the new moduleLoader pattern.

Per PR objectives, modules now export a { token, loadModule } moduleLoader. Prefer container.load(moduleLoader) over (token, module) to keep consistency and leverage the standardized shape.

Apply this refactor (adjust names if your modules re-export moduleLoader under a different alias):

-import { prismaModule } from "@calcom/prisma/prisma.module";
+import { moduleLoader as prismaModuleLoader } from "@calcom/prisma/prisma.module";
@@
-import { bookingRepositoryModule } from "../modules/Booking";
-import { filterHostsModule } from "../modules/FilterHosts";
+import { moduleLoader as bookingRepositoryModuleLoader } from "../modules/Booking";
+import { moduleLoader as filterHostsModuleLoader } from "../modules/FilterHosts";
@@
-const container = createContainer();
-container.load(DI_TOKENS.PRISMA_MODULE, prismaModule);
-container.load(DI_TOKENS.BOOKING_REPOSITORY_MODULE, bookingRepositoryModule);
-container.load(DI_TOKENS.FILTER_HOSTS_SERVICE_MODULE, filterHostsModule);
+const container = createContainer();
+container.load(prismaModuleLoader);
+container.load(bookingRepositoryModuleLoader);
+container.load(filterHostsModuleLoader);

---

9-16: Optional: lazy-init the container for testability and to avoid side effects at import time.

Defers wiring until needed and makes it easier to reset between tests.

-const container = createContainer();
-container.load(DI_TOKENS.PRISMA_MODULE, prismaModule);
-container.load(DI_TOKENS.BOOKING_REPOSITORY_MODULE, bookingRepositoryModule);
-container.load(DI_TOKENS.FILTER_HOSTS_SERVICE_MODULE, filterHostsModule);
-
-export function getFilterHostsService() {
-  return container.get<FilterHostsService>(DI_TOKENS.FILTER_HOSTS_SERVICE);
-}
+let _container: ReturnType<typeof createContainer> | null = null;
+
+export function getFilterHostsService() {
+  if (!_container) {
+    _container = createContainer();
+    // Use moduleLoader-based loads if available
+    // _container.load(prismaModuleLoader);
+    // _container.load(bookingRepositoryModuleLoader);
+    // _container.load(filterHostsModuleLoader);
+    // If still on (token, module), keep the original three loads here.
+  }
+  return _container.get<FilterHostsService>(DI_TOKENS.FILTER_HOSTS_SERVICE);
+}

---

1-16: Standardize module export/loading conventions across DI containers

• FilterHosts module doesn’t export a moduleLoader (whereas Booking, Cache, etc. do); either add a moduleLoader export to FilterHosts.ts or remove the unused moduleLoader exports from the other modules.
• Decide on—and apply—one loading pattern repo-wide: use either the one-arg container.load(moduleLoader) approach or the two-arg container.load(token, module) style (including for prismaModule).

packages/lib/di/modules/Team.ts (1)

6-7: Export a standardized moduleLoader alongside the module to match PR’s unified pattern.

Keeps current export while enabling the new loader-based flow everywhere.

Apply:

 export const teamRepositoryModule = createModule();
 teamRepositoryModule.bind(DI_TOKENS.TEAM_REPOSITORY).toClass(TeamRepository, [DI_TOKENS.PRISMA_CLIENT]);
 
+// PR convention: every module exports a { token, loadModule } loader
+export const moduleLoader = {
+  token: DI_TOKENS.TEAM_REPOSITORY,
+  loadModule: () => teamRepositoryModule,
+};

packages/lib/di/modules/GetUserAvailability.ts (1)

6-12: Optional: adopt bindModuleToClassOnToken for stronger type/runtime safety.

To align with the new DI utility, consider wiring via bindModuleToClassOnToken(...) from ../di so the depsMap is generically validated and loadDeps is auto-generated. I can provide a patch once we confirm the exact helper signature exported by ../di.

packages/lib/di/containers/Cache.ts (2)

1-12: Adopt moduleLoader pattern to decouple from DI_TOKENS and standardize loading

Use each module’s moduleLoader.{loadModule, token} instead of loading by DI_TOKENS._MODULE and getting by DI_TOKENS.. This aligns with the PR’s “single source of truth” and avoids token drift.

-import { DI_TOKENS } from "@calcom/lib/di/tokens";
-import { prismaModule } from "@calcom/prisma/prisma.module";
+import { moduleLoader as prismaModuleWithToken } from "@calcom/prisma/prisma.module";

 import type { CacheService } from "../../../features/calendar-cache/lib/getShouldServeCache";
 import { createContainer } from "../di";
-import { cacheModule } from "../modules/Cache";
-import { featuresRepositoryModule } from "../modules/Features";
+import { moduleLoader as cacheModuleWithToken } from "../modules/Cache";
+import { moduleLoader as featuresRepositoryModuleWithToken } from "../modules/Features";

 const container = createContainer();
-container.load(DI_TOKENS.PRISMA_MODULE, prismaModule);
-container.load(DI_TOKENS.FEATURES_REPOSITORY_MODULE, featuresRepositoryModule);
-container.load(DI_TOKENS.CACHE_SERVICE_MODULE, cacheModule);
+prismaModuleWithToken.loadModule(container);
+featuresRepositoryModuleWithToken.loadModule(container);
+cacheModuleWithToken.loadModule(container);

---

14-16: Get by moduleLoader.token and annotate return type

Minor consistency and typing polish.

-export function getCacheService() {
-  return container.get<CacheService>(DI_TOKENS.CACHE_SERVICE);
+export function getCacheService(): CacheService {
+  return container.get<CacheService>(cacheModuleWithToken.token);
 }

packages/lib/di/modules/Features.ts (2)

11-16: Freeze moduleLoader for immutability and stronger inference

Tiny hardening: mark the loader object immutable.

 export const moduleLoader = {
   token,
   loadModule: (container: Container) => {
     container.load(moduleToken, featuresRepositoryModule);
   },
-};
+} as const;

---

9-9: Use bindModuleToClassOnToken for type-checked dependencies

Import the helper from "../di" and replace:

featuresRepositoryModule.bind(token).toClass(FeaturesRepository, [DI_TOKENS.PRISMA_CLIENT]);

with:

import { bindModuleToClassOnToken } from "../di";

const loadModule = bindModuleToClassOnToken({
  module: featuresRepositoryModule,
  token,
  class: FeaturesRepository,
  deps: [DI_TOKENS.PRISMA_CLIENT],
});

This enforces compile-time validation of constructor deps and sets up auto-loading hooks.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: hariombalhara
PR: calcom/cal.com#23541
File: packages/features/bookings/lib/di/modules/RegularBookingServiceModule.ts:22-28
Timestamp: 2025-09-03T09:52:51.182Z
Learning: The IBookingServiceDependencies interface in packages/features/bookings/lib/handleNewBooking.ts contains 6 properties: cacheService, checkBookingAndDurationLimitsService, prismaClient, bookingRepository, featuresRepository, and checkBookingLimitsService. This interface is used by RegularBookingService and matches the depsMap structure in RegularBookingServiceModule.

Learnt from: supalarry
PR: calcom/cal.com#23217
File: apps/api/v2/src/ee/event-types/event-types_2024_06_14/services/output-event-types.service.ts:93-94
Timestamp: 2025-08-21T13:44:06.805Z
Learning: In apps/api/v2/src/ee/event-types/event-types_2024_06_14/event-types.repository.ts, repository functions that use explicit Prisma select clauses (like getEventTypeWithSeats) are used for specific purposes and don't need to include all EventType fields like bookingRequiresAuthentication. These methods don't feed into the general OutputEventTypesService_2024_06_14 flow.

packages/lib/di/containers/BookingLimits.ts (1)

6-6: Internalize DI import: LGTM

Switching createContainer to the local DI entrypoint aligns with the PR direction and keeps DI concerns in-repo.

packages/lib/di/containers/BookingLimits.ts (2)

7-9: Consider adopting the new moduleLoader pattern here for consistency and type-safety

This container still manually loads modules via DI_TOKENS. To match the PR’s standardized pattern ({ token, loadModule }) and gain type-safe wiring, load via the per-module loader objects.

Example refactor (assuming these modules export ...ModuleLoader):

-import { bookingRepositoryModule } from "../modules/Booking";
-import { checkBookingAndDurationLimitsModule } from "../modules/CheckBookingAndDurationLimits";
-import { checkBookingLimitsModule } from "../modules/CheckBookingLimits";
+import { bookingRepositoryModuleLoader } from "../modules/Booking";
+import { checkBookingAndDurationLimitsModuleLoader } from "../modules/CheckBookingAndDurationLimits";
+import { checkBookingLimitsModuleLoader } from "../modules/CheckBookingLimits";

-const container = createContainer();
-container.load(DI_TOKENS.PRISMA_MODULE, prismaModule);
-container.load(DI_TOKENS.BOOKING_REPOSITORY_MODULE, bookingRepositoryModule);
-container.load(DI_TOKENS.CHECK_BOOKING_LIMITS_SERVICE_MODULE, checkBookingLimitsModule);
-container.load(
-  DI_TOKENS.CHECK_BOOKING_AND_DURATION_LIMITS_SERVICE_MODULE,
-  checkBookingAndDurationLimitsModule
-);
+const container = createContainer();
+// If prisma also exposes a loader, prefer that for consistency:
+// container.load(prismaModuleLoader.token, prismaModuleLoader.loadModule);
+container.load(bookingRepositoryModuleLoader.token, bookingRepositoryModuleLoader.loadModule);
+container.load(checkBookingLimitsModuleLoader.token, checkBookingLimitsModuleLoader.loadModule);
+container.load(
+  checkBookingAndDurationLimitsModuleLoader.token,
+  checkBookingAndDurationLimitsModuleLoader.loadModule
+);

If you’ve generated loadDeps for a higher-level module/container, you can replace these manual loads entirely with that helper.

Also applies to: 11-18

---

20-28: Add explicit return types on exported getters

Locks the public API and protects against accidental type drift if internal implementations change.

-export function getCheckBookingLimitsService() {
+export function getCheckBookingLimitsService(): CheckBookingLimitsService {
   return container.get<CheckBookingLimitsService>(DI_TOKENS.CHECK_BOOKING_LIMITS_SERVICE);
 }

-export function getCheckBookingAndDurationLimitsService() {
+export function getCheckBookingAndDurationLimitsService(): CheckBookingAndDurationLimitsService {
   return container.get<CheckBookingAndDurationLimitsService>(
     DI_TOKENS.CHECK_BOOKING_AND_DURATION_LIMITS_SERVICE
   );
 }

packages/lib/di/containers/AvailableSlots.ts (2)

27-47: Align with the new moduleLoader pattern to remove token duplication.

Per PR objectives, modules export { token, loadModule }. Prefer container.load(moduleLoader) to avoid drift between DI_TOKENS.* and the module’s internal token and to gain type/runtime safety.

- container.load(DI_TOKENS.REDIS_CLIENT, redisModule);
- container.load(DI_TOKENS.PRISMA_MODULE, prismaModule);
- container.load(DI_TOKENS.OOO_REPOSITORY_MODULE, oooRepositoryModule);
- container.load(DI_TOKENS.SCHEDULE_REPOSITORY_MODULE, scheduleRepositoryModule);
- container.load(DI_TOKENS.SELECTED_SLOT_REPOSITORY_MODULE, selectedSlotsRepositoryModule);
- container.load(DI_TOKENS.TEAM_REPOSITORY_MODULE, teamRepositoryModule);
- container.load(DI_TOKENS.MEMBERSHIP_REPOSITORY_MODULE, membershipRepositoryModule);
- container.load(DI_TOKENS.USER_REPOSITORY_MODULE, userRepositoryModule);
- container.load(DI_TOKENS.BOOKING_REPOSITORY_MODULE, bookingRepositoryModule);
- container.load(DI_TOKENS.EVENT_TYPE_REPOSITORY_MODULE, eventTypeRepositoryModule);
- container.load(DI_TOKENS.ROUTING_FORM_RESPONSE_REPOSITORY_MODULE, routingFormResponseRepositoryModule);
- container.load(DI_TOKENS.FEATURES_REPOSITORY_MODULE, featuresRepositoryModule);
- container.load(DI_TOKENS.CACHE_SERVICE_MODULE, cacheModule);
- container.load(DI_TOKENS.CHECK_BOOKING_LIMITS_SERVICE_MODULE, checkBookingLimitsModule);
- container.load(DI_TOKENS.AVAILABLE_SLOTS_SERVICE_MODULE, availableSlotsModule);
- container.load(DI_TOKENS.GET_USER_AVAILABILITY_SERVICE_MODULE, getUserAvailabilityModule);
- container.load(DI_TOKENS.BUSY_TIMES_SERVICE_MODULE, busyTimesModule);
- container.load(DI_TOKENS.FILTER_HOSTS_SERVICE_MODULE, filterHostsModule);
- container.load(DI_TOKENS.QUALIFIED_HOSTS_SERVICE_MODULE, qualifiedHostsModule);
- container.load(DI_TOKENS.NO_SLOTS_NOTIFICATION_SERVICE_MODULE, noSlotsNotificationModule);
+ container.load(redisModule);
+ container.load(prismaModule);
+ container.load(oooRepositoryModule);
+ container.load(scheduleRepositoryModule);
+ container.load(selectedSlotsRepositoryModule);
+ container.load(teamRepositoryModule);
+ container.load(membershipRepositoryModule);
+ container.load(userRepositoryModule);
+ container.load(bookingRepositoryModule);
+ container.load(eventTypeRepositoryModule);
+ container.load(routingFormResponseRepositoryModule);
+ container.load(featuresRepositoryModule);
+ container.load(cacheModule);
+ container.load(checkBookingLimitsModule);
+ container.load(availableSlotsModule);
+ container.load(getUserAvailabilityModule);
+ container.load(busyTimesModule);
+ container.load(filterHostsModule);
+ container.load(qualifiedHostsModule);
+ container.load(noSlotsNotificationModule);

---

49-51: Prefer moduleLoader.token for retrieval to keep token definitions single-sourced.

This avoids mismatches between DI_TOKENS and the module’s declared token.

- return container.get<AvailableSlotsService>(DI_TOKENS.AVAILABLE_SLOTS_SERVICE);
+ return container.get<AvailableSlotsService>(availableSlotsModule.token);

packages/lib/di/modules/CheckBookingAndDurationLimits.ts (2)

4-4: Adopt the new helper for stronger typing and consistency with the PR’s pattern.

Prefer using bindModuleToClassOnToken from ../di rather than hand-rolling the toClass + satisfies check. It yields tighter compile-time guarantees and better aligns with the new moduleLoader flow.

Apply:

-import { type Container, createModule } from "../di";
+import { type Container, createModule, bindModuleToClassOnToken } from "../di";

---

14-19: Minor: freeze the loader object.

Mark moduleLoader as const to prevent accidental mutation and keep its shape stable.

 export const moduleLoader = {
   token,
   loadModule: (container: Container) => {
     container.load(moduleToken, checkBookingAndDurationLimitsModule);
   },
-};
+} as const;

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: hariombalhara
PR: calcom/cal.com#23541
File: packages/features/bookings/lib/di/modules/RegularBookingServiceModule.ts:22-28
Timestamp: 2025-09-03T09:52:51.182Z
Learning: The IBookingServiceDependencies interface in packages/features/bookings/lib/handleNewBooking.ts contains 6 properties: cacheService, checkBookingAndDurationLimitsService, prismaClient, bookingRepository, featuresRepository, and checkBookingLimitsService. This interface is used by RegularBookingService and matches the depsMap structure in RegularBookingServiceModule.

Learnt from: hariombalhara
PR: calcom/cal.com#23541
File: packages/features/bookings/lib/di/modules/RegularBookingServiceModule.ts:22-28
Timestamp: 2025-09-03T09:52:51.182Z
Learning: The IBookingServiceDependencies interface in packages/features/bookings/lib/handleNewBooking.ts contains 6 properties: cacheService, checkBookingAndDurationLimitsService, prismaClient, bookingRepository, featuresRepository, and checkBookingLimitsService. This interface is used by RegularBookingService and matches the depsMap structure in RegularBookingServiceModule.

packages/prisma/prisma.module.ts (1)

13-19: Optional: dedicated loader for read-only token (repeat of earlier feedback).

If you want first-class referencing symmetry, add a separate readOnlyModuleLoader; current readOnlyToken on moduleLoader is workable, so this is optional.

 export const moduleLoader = {
   token,
   readOnlyToken,
   loadModule: (container: Container) => {
     container.load(moduleToken, prismaModule);
   },
 };
+
+export const readOnlyModuleLoader = {
+  token: readOnlyToken,
+  loadModule: (container: Container) => {
+    container.load(moduleToken, prismaModule);
+  },
+};

packages/lib/di/bookings/tokens.ts (1)

1-8: Make token bag readonly to prevent accidental mutation.

Tiny safety improvement:

-export const BOOKING_DI_TOKENS = {
+export const BOOKING_DI_TOKENS = {
   REGULAR_BOOKING_SERVICE: Symbol("RegularBookingService"),
   REGULAR_BOOKING_SERVICE_MODULE: Symbol("RegularBookingServiceModule"),
   RECURRING_BOOKING_SERVICE: Symbol("RecurringBookingService"),
   RECURRING_BOOKING_SERVICE_MODULE: Symbol("RecurringBookingServiceModule"),
   INSTANT_BOOKING_CREATE_SERVICE: Symbol("InstantBookingCreateService"),
   INSTANT_BOOKING_CREATE_SERVICE_MODULE: Symbol("InstantBookingCreateServiceModule"),
-};
+} as const;

packages/lib/di/bookings/containers/InstantBookingCreateService.container.ts (2)

4-7: Align export naming with the standardized moduleLoader.

If InstantBookingCreateService.module.ts now exports moduleLoader, prefer importing that for consistency across modules.

Apply:

-import {
-  type InstantBookingCreateService,
-  instantBookingCreateServiceModule,
-} from "../modules/InstantBookingCreateService.module";
+import {
+  type InstantBookingCreateService,
+  moduleLoader as instantBookingCreateServiceModule,
+} from "../modules/InstantBookingCreateService.module";

---

9-14: Confirm container lifecycle is safe in your runtimes.

Module-scoped singleton container persists across imports. Verify it’s safe under SSR/serverless concurrency and won’t retain request-scoped state.

packages/lib/di/bookings/modules/RegularBookingService.module.ts (2)

30-33: Standardize export name to moduleLoader.

The PR’s pattern says each module exports { token, loadModule } as moduleLoader. Rename for consistency with other modules and imports (you’re already consuming others as moduleLoader).

Apply:

-export const regularBookingServiceModule = {
-  token,
-  loadModule,
-};
+export const moduleLoader = {
+  token,
+  loadModule,
+} as const;

And update any consumers (e.g., RegularBookingService.container) to import { moduleLoader } or alias as needed.

---

10-18: Optional: add a type to the exported loader for stronger guarantees.

If you have a ModuleLoader interface/type, annotate the export or use satisfies to lock shape at compile time.

Example:

export const moduleLoader = { token, loadModule } satisfies ModuleLoader;

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: hariombalhara
PR: calcom/cal.com#23541
File: packages/features/bookings/lib/di/modules/RegularBookingServiceModule.ts:22-28
Timestamp: 2025-09-03T09:52:51.182Z
Learning: The IBookingServiceDependencies interface in packages/features/bookings/lib/handleNewBooking.ts contains 6 properties: cacheService, checkBookingAndDurationLimitsService, prismaClient, bookingRepository, featuresRepository, and checkBookingLimitsService. This interface is used by RegularBookingService and matches the depsMap structure in RegularBookingServiceModule.