turbo.json (1)

465-469: Consider updating outputs to include new generated files for future caching

The @calcom/app-store-cli#build task currently lists only two outputs. Since this PR adds analytics.services.generated.ts (and calendar.services.generated.ts exists), it’s safer to enumerate them to avoid surprises if caching is enabled later or for tooling that inspects outputs.

Apply this diff to reflect the new generated artifacts:

     "@calcom/app-store-cli#build": {
       "cache": false,
       "inputs": ["../../app-store/**"],
-      "outputs": ["../../app-store/apps.server.generated.ts", "../../app-store/apps.browser.generated.tsx"]
+      "outputs": [
+        "../../app-store/apps.server.generated.ts",
+        "../../app-store/apps.browser.generated.tsx",
+        "../../app-store/calendar.services.generated.ts",
+        "../../app-store/analytics.services.generated.ts",
+        "../../app-store/apps.metadata.generated.ts",
+        "../../app-store/apps.schemas.generated.ts",
+        "../../app-store/apps.keys-schemas.generated.ts",
+        "../../app-store/bookerApps.metadata.generated.ts",
+        "../../app-store/crm.apps.generated.ts"
+      ]
     },

packages/app-store-cli/src/build.ts (3)

381-397: Analytics map generation is correct and filter is precise

• Uses the same generator as other maps with lazy dynamic imports.
• Filters apps by existence of lib/AnalyticsService.ts, which is sufficient and avoids false positives.

Minor: the filter duplicates file existence checks already performed in getExportedObject; keeping it is fine for clarity.

If you want to DRY this, you can drop the explicit filter here since getExportedObject already skips missing files.

---

399-417: E2E guard wrapping logic mirrors calendar — LGTM, but consider extracting a helper

The wrapping that rewrites export const AnalyticsServiceMap = { to a guarded variant is correct and consistent with CalendarServiceMap.

Consider extracting a small helper to avoid duplication across Calendar/Analytics:

+function wrapWithE2EGuard(objectName: string, lines: string[]) {
+  const idx = lines.findIndex((l) => l.startsWith(`export const ${objectName}`));
+  if (idx === -1) return lines;
+  const exportLine = lines[idx];
+  const objectContent = lines.slice(idx + 1, -1);
+  return [
+    exportLine.replace(
+      `export const ${objectName} = {`,
+      `export const ${objectName} = process.env.NEXT_PUBLIC_IS_E2E ? {} : {`
+    ),
+    ...objectContent,
+    "};",
+  ];
+}

Then reuse it for both CalendarServiceMap and AnalyticsServiceMap.

---

385-390: Default exports in generated imports — consider standardizing on named exports

Repository guidelines prefer named exports for better tree-shaking and refactors. The generator currently assumes default for AnalyticsService. Not blocking, but worth aligning longer-term (while still supporting legacy defaults).

Example future-friendly generation:

-  importConfig: {
-    fileToBeImported: "lib/AnalyticsService.ts",
-    importName: "default",
-  },
+  importConfig: [
+    { fileToBeImported: "lib/AnalyticsService.ts", importName: "AnalyticsService" },
+    { fileToBeImported: "lib/AnalyticsService.ts", importName: "default" }
+  ],

This tries a named export first, falling back to default if needed.

packages/app-store/_utils/getAnalytics.ts (2)

33-38: Improve log clarity and variable naming

• analyticsAppImportFn is a Promise, not a function. Rename for clarity.
• Include the analyticsName in the “not implemented” warning to aid debugging.

Apply this diff:

-  const analyticsAppImportFn = AnalyticsServiceMap[analyticsName as keyof typeof AnalyticsServiceMap];
+  const analyticsAppModulePromise = AnalyticsServiceMap[analyticsName as keyof typeof AnalyticsServiceMap];

-  if (!analyticsAppImportFn) {
-    log.warn(`analytics app not implemented`);
+  if (!analyticsAppModulePromise) {
+    log.warn(`Analytics app not implemented for "${analyticsName}"`);
     return null;
   }

---

48-52: Optional: reduce log verbosity and attach context

Current info log prints the class reference; prefer message with app name to avoid noisy object dumps, especially in prod logs.

-  log.info("Got analyticsApp", AnalyticsService);
+  log.info({ analyticsName }, "Analytics service resolved");

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/app-store/_utils/getAnalytics.ts (1)

19-36: Make analytics imports truly lazy, harden error handling, and support both default and named exports

• Current map values are awaited directly, which assumes they’re Promises and also eagerly triggers dynamic imports at module-evaluation time in the generated file. This undermines laziness and can still load modules when this file is imported.
• If the dynamic import rejects, this function will throw instead of returning null.
• Only the default export is considered; some apps may expose a named AnalyticsService.

Refactor to:

• Treat the map entry as either a Promise or a thunk (() => Promise), calling it if it’s a function.
• Wrap the import in try/catch and return null on failure.
• Accept either a default export or a named AnalyticsService export.
• Normalize analyticsName to lowercase to avoid case/format drift.

Apply this diff within this range:

-  const analyticsName = analyticsType.split("_")[0];
+  const analyticsName = analyticsType.split("_")[0]?.toLowerCase();

-  const analyticsAppImportFn = AnalyticsServiceMap[analyticsName as keyof typeof AnalyticsServiceMap];
+  const importer = AnalyticsServiceMap[analyticsName as keyof typeof AnalyticsServiceMap];

-  if (!analyticsAppImportFn) {
-    log.warn(`analytics app not implemented`);
-    return null;
-  }
+  if (!importer) {
+    log.warn(`analytics app "${analyticsName}" not implemented (type="${analyticsType}")`);
+    return null;
+  }

-  const analyticsApp = await analyticsAppImportFn;
+  let analyticsModule: AnalyticsModule | null = null;
+  try {
+    const modulePromise =
+      typeof importer === "function"
+        ? (importer as () => Promise<AnalyticsModule>)()
+        : (importer as Promise<AnalyticsModule>);
+    analyticsModule = await modulePromise;
+  } catch (err) {
+    log.warn(`failed to load analytics module "${analyticsName}": ${(err as Error)?.message}`);
+    return null;
+  }

-  const AnalyticsService = analyticsApp.default;
+  const AnalyticsServiceCtor = (analyticsModule?.default ??
+    (analyticsModule as any)?.AnalyticsService) as AnalyticsServiceCtor | undefined;

-  if (!AnalyticsService || typeof AnalyticsService !== "function") {
-    log.warn(`analytics of type ${analyticsType} is not implemented`);
-    return null;
-  }
+  if (typeof AnalyticsServiceCtor !== "function") {
+    log.warn(
+      `analytics of type "${analyticsType}" is not implemented (no default export or named "AnalyticsService")`
+    );
+    return null;
+  }

-  return new AnalyticsService(credential);
+  return new AnalyticsServiceCtor(credential);

Add these supporting types near the top of the file (outside this range):

type AnalyticsServiceCtor = new (credential: CredentialPayload) => AnalyticsService;
type AnalyticsModule = { default?: AnalyticsServiceCtor; AnalyticsService?: AnalyticsServiceCtor };

packages/app-store/_utils/getAnalytics.ts (1)

2-2: Avoid value/type name collision with AnalyticsService

You import the interface AnalyticsService as a type and then create a runtime value with the same identifier later. While legal in TS, it’s easy to misread. The diff above renames the runtime value to AnalyticsServiceCtor, which aligns with its semantics (a constructor).

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.