Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion package.json
Original file line number Diff line number Diff line change
Expand Up @@ -90,7 +90,7 @@
"next": "^16.1.6",
"next-sitemap": "^4.2.3",
"next-themes": "^0.4.6",
"nodemailer": "^7.0.11",
"nodemailer": "^8.0.5",
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 The @types/nodemailer package in dependencies is still pinned to ^7.0.4 while this PR bumps the runtime nodemailer to ^8.0.5 — a major version mismatch. The fix is trivial: update @types/nodemailer to ^8.0.0 to match the installed runtime.

Extended reasoning...

What the bug is and how it manifests

This PR bumps nodemailer from ^7.0.11 to ^8.0.5 in package.json, but leaves @types/nodemailer at ^7.0.4. Because semver ranges do not cross major version boundaries, the ^7.0.4 constraint will always resolve to a 7.x package and will never pick up the v8 type definitions. nodemailer v8 does not ship its own TypeScript types (no types or typings field in its package.json), so the DefinitelyTyped package is the only source of types. The runtime is v8.0.5 while TypeScript compiles against v7.x definitions — a genuine major-version mismatch.

The specific code path that triggers it

app/api/contact-sales/route.ts imports nodemailer and calls nodemailer.createTransport(smtpUrl) and transporter.sendMail({from, to, replyTo, subject, text}). TypeScript resolves the types for these calls from the installed @types/nodemailer package, which will be 7.x rather than 8.x.

Why existing code doesn't prevent it / addressing the refutation

The refuting verifier correctly points out that the only documented breaking change in nodemailer v8.0.0 is the runtime error-code rename NoAuthENOAUTH, which is not a type-level change and is not referenced in the codebase. For the specific APIs currently in use (createTransport with a string URL and sendMail with standard mail options), the type signatures are functionally identical between v7 and v8, meaning no TypeScript compilation error is produced today.

However, this does not make the mismatch non-existent — it makes it low-impact. Having the runtime at major version 8 and the type definitions at major version 7 is objectively incorrect. Any future code additions that use new v8-only APIs would silently use incorrect or missing type signatures, and the mismatch makes it harder to reason about the dependency graph. Dependency hygiene dictates that types packages track their corresponding runtime package's major version.

Impact

Current impact is low: no compile errors occur for the existing createTransport/sendMail usage. The risk is latent — new code using v8-specific APIs or error codes would be type-checked against stale v7 definitions without any warning.

How to fix it

In package.json, update @types/nodemailer from ^7.0.4 to ^8.0.0. Note that @types/nodemailer is currently placed in dependencies rather than devDependencies; this is a pre-existing placement issue and is separate from the version mismatch introduced by this PR.

Step-by-step proof

  1. nodemailer runtime is resolved to 8.0.5 (confirmed by pnpm-lock.yaml: nodemailer@8.0.5: {}).
  2. @types/nodemailer is constrained to ^7.0.4 — semver range resolves to latest 7.x (e.g., 7.0.11).
  3. @types/nodemailer@8.0.0 exists on npm (confirmed by verifiers via registry check).
  4. nodemailer v8 has no bundled types (no types field in package.json), so TypeScript falls back to @types/nodemailer.
  5. Result: TypeScript uses v7.x type definitions while running v8.x code — a major-version mismatch. The ^7.0.4 constraint must be changed to ^8.0.0 to resolve correctly.

"openai": "^6.22.0",
"openai-edge": "^1.2.2",
"postcss": "^8.4.49",
Expand Down
Loading
Loading