apps/web/app/(ee)/api/cron/welcome-user/route.ts:50

• [nitpick] Consider handling the conditional sendEmail call outside of Promise.all to improve readability and avoid mixing undefined values in asynchronous operations.

isPartner ? undefined : sendEmail({

apps/web/scripts/update-subscribers.ts (1)

50-50: 🛠️ Refactor suggestion

Use the centralized Resend client instead of creating a new instance.

This duplicates the existing centralized Resend client setup. Consider importing and using the centralized client from @dub/email/resend/client for consistency.

Apply this diff to use the centralized client:

-const resend = new Resend(process.env.RESEND_API_KEY);
+import { resend } from "@dub/email/resend/client";

packages/email/src/resend/unsubscribe.ts (1)

6-8: Consider standardizing error messages across modules.

The error message is appropriate but slightly different from the one in subscribe.ts. Consider using consistent error messaging across both modules for better user experience.

For consistency with subscribe.ts, consider updating the error message:

-    console.error(
-      "Resend client is not properly initialized. Skipping operation.",
-    );
+    console.error(
+      "Resend client is not initialized. This may be due to a missing or invalid RESEND_API_KEY in the .env file. Skipping.",
+    );

packages/email/src/resend/client.ts (1)

1-5: LGTM: Clean centralized client initialization pattern.

This module properly centralizes the Resend client initialization with appropriate conditional logic. The pattern of returning null when the API key is missing allows other modules to gracefully handle the unavailable service.

Consider: Invalid API key handling.

While the current implementation handles missing API keys well, consider that an invalid but present RESEND_API_KEY would still create a Resend instance that might fail during API calls. The current error handling in subscribe.ts and unsubscribe.ts should catch API-level errors, but you might want to consider adding validation or more specific error handling if needed.

packages/email/src/resend/constants.ts (2)

1-4: Explicit typing + immutability will prevent accidental audience mutations

RESEND_AUDIENCES is currently inferred as a mutable { [key: string]: string }.
If one of the audiences were to be reassigned elsewhere, Type-Script would not stop us.
Marking the object as readonly (or as const) – and optionally declaring it as a Record<string, string> – locks the mapping down at compile-time:

-export const RESEND_AUDIENCES = {
+export const RESEND_AUDIENCES: Readonly<Record<string, string>> = {
   "app.dub.co": "f5ff0661-4234-43f6-b0ca-a3f3682934e3",
   "partners.dub.co": "6caf6898-941a-45b6-a59f-d0780c3004ac",
 };

This makes accidental writes a type error and documents the intent that these are constants.

---

6-10: Leverage as const to tighten the variant → from mapping

Right now VARIANT_TO_FROM_MAP is inferred as an open { [key: string]: string }, which means VARIANT_TO_FROM_MAP['non-existent'] is perfectly legal and returns string | undefined.
By marking the object as const, we achieve:

• Literal type union 'primary' | 'notifications' | 'marketing' for the keys.
• Narrow string literals for the values.
• Compile-time safety when we later index the map.

-export const VARIANT_TO_FROM_MAP = {
+export const VARIANT_TO_FROM_MAP = {
   primary: "Dub.co <[email protected]>",
   notifications: "Dub.co <[email protected]>",
   marketing: "Steven from Dub.co <[email protected]>",
-};
+} as const;

Downstream (e.g. in send-via-resend.ts) you can then write
VARIANT_TO_FROM_MAP[variant] knowing variant is one of the mapped keys.

packages/email/src/resend/index.ts (1)

1-3: Consider re-exporting constants (and possibly sendEmailViaResend) for a cleaner public surface

Consumers currently need three different import paths:

import { resend } from "@dub/email/dist/resend";
import { subscribe } from "@dub/email/dist/resend";
import { VARIANT_TO_FROM_MAP } from "@dub/email/dist/resend/constants";

Re-exporting * from ./constants (and potentially ../send-via-resend) here would allow a single barrel import:

 export * from "./client";
 export * from "./subscribe";
 export * from "./unsubscribe";
+export * from "./constants";

This is optional, but it can make the package ergonomics nicer while still keeping the modular file structure.

packages/email/src/send-via-resend.ts (3)

14-24: Type-safe variant – narrow it to the known literals

variant defaults to "primary" but the type coming from ResendEmailOptions is presumably string.
Narrowing the type guards against typos ("primay"). You can achieve this by:

type Variant = keyof typeof VARIANT_TO_FROM_MAP; // "primary" | "notifications" | "marketing"

export interface ResendEmailOptions {
  // …
  variant?: Variant;
}

and then:

const { variant = "primary" as Variant, … } = opts;

This pairs nicely with the earlier as const change.

---

26-35: Remove redundant await to propagate errors & slightly improve latency

return await <promise> adds an extra micro-tick and obscures stack-traces; you can simply return the promise:

-  return await resend.emails.send({
+  return resend.emails.send({
     to: email,

Functionally identical but a hair cleaner.

---

26-40: Headers spread pattern is clever but brittle – prefer explicit conditional merge

Spreading false is valid JS, yet it’s a minor foot-gun and can confuse readers unfamiliar with the technique.
An explicit conditional keeps intent clear:

-    ...(variant === "marketing" && {
-      headers: {
-        "List-Unsubscribe": "https://app.dub.co/account/settings",
-      },
-    }),
+    ...(variant === "marketing"
+      ? {
+          headers: {
+            "List-Unsubscribe": "https://app.dub.co/account/settings",
+          },
+        }
+      : {}),

Purely readability, no behavioral change.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro