Prisma 7 .mts generated client breaks Vercel deploy via @vercel/redwood (NFT can't parse .mts)

[bellcoTech]

Heads up on something I hit pushing a Cedar 4.2 ESM app to Vercel. Not asking for a template change — .mts is the right default per #1752 / #1761 — just flagging it because the documented path is incompatible with Vercel's default builder and there's no in-project workaround that doesn't diverge from your docs.

What I see

Vercel build succeeds. At runtime, the lambda throws:

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@prisma/client' imported from /var/task/api/db/generated/prisma/client.mts

Patch around that (force NFT to trace @prisma/client via a .ts side-effect import in db.ts) and the next error is:

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/var/task/api/db/generated/prisma/enums.mts' imported from /var/task/api/db/generated/prisma/client.mts

…and so on for every sibling generated .mts file.

Why

Vercel deploys Cedar via @vercel/redwood, which calls nodeFileTrace from @vercel/nft over api/dist/**/*.{js,ts} and bundles only what NFT returns:

nodeFileTrace([absEntrypoint], {
  base: workPath, processCwd: workPath,
  ts: true, mixedModules: true,
  ignore: config.excludeFiles,
})

(vercel/vercel/packages/redwood/src/index.ts)

@vercel/nft parses with acorn (vanilla JS, no TS support). The ts: true flag enables .js → .ts resolver fallback but neither the resolver nor the parser handles .mts (vercel/nft/src/analyze.ts, node-file-trace.ts).

When NFT parses client.mts — which contains TS syntax (generics, type aliases, interfaces) — acorn fails. NFT catches the error and returns { deps: [], imports: [] }. Silent. Every transitive import inside the generated client is dropped. client.mts itself ends up in the bundle because it's referenced from a parseable .js file (api/dist/lib/db.js), but the trace stops there.

Why this isn't fixable in a Cedar project

• .mts is the documented default and necessary for CJS-mode Cedar projects per fix(internal): fall back to schema parsing for Prisma 7 ModelName #1752 / fix(prisma): Explain schema.prisma config settings #1761 — can't drop it.
• The deploy docs explicitly forbid vercel.json functions config: "Since Cedar has its own handling of the api directory, the Vercel flavored api directory is disabled. Therefore you don't use the 'functions' config in vercel.json with Cedar."
• @vercel/redwood reads excludeFiles only, no includeFiles — confirmed in source. No env var, no cedar.toml field. There's no surface for a Cedar user to inject files into the bundle while staying on the documented path.

Where the fix could live (probably not Cedar)

Two candidates, both Vercel-side:

1. @vercel/redwood — copy api/db/generated/**/* into each function bundle after nodeFileTrace. Small, surgical, no NFT change needed.
2. @vercel/nft — add TS-aware parsing for .ts/.mts/.cts (pre-strip types via typescript or @swc/core before acorn). Architecturally correct but a bigger change.

Happy to file at vercel/vercel against @vercel/redwood linking back here if that's useful. Filing here first since Cedar users are who hit it.

Conditional workaround (not for the template)

For ESM-only projects (api workspace is type: module), generatedFileExtension = "ts" is functionally equivalent at runtime — Node 24 strips types from both, NFT's ts: true then parses the generated client correctly. Not safe as a template default, but a viable local divergence for ESM-only apps until upstream fixes land.

Environment

• Cedar 4.2.0
• Prisma 7.8.0, prisma-client provider, generatedFileExtension = "mts"
• api workspace "type": "module"
• Node 24.x
• Vercel @vercel/redwood (auto-detected, @vercel/nft@1.5.0 transitive)

Related

• fix(internal): fall back to schema parsing for Prisma 7 ModelName #1752 — closed PR where the .mts choice was established
• fix(prisma): Explain schema.prisma config settings #1761 — docs comments explaining the .mts rationale
• feat(create-cedar-app): Create ESM apps #80 — original ESM template PR (predates Prisma 7 + Vercel combination)

[Tobbe]

Thanks for filing this issue. And I'm super grateful for the workaround. Sounds like a totally acceptable path forward for anyone deploying ESM Cedar apps to Vercel.

If @vercel/nft is still what they use in modern deployments I think they most likely want to update that to better support TS. Pure TS usage is only going to increase as Node adds better and better support for it natively.

@vercel/redwood is really starting to show its age. If that's a path we want to continue to support it's definitely time for a @vercel/cedar flavor.

The real way forward here is most likely going to be Cedar's upcoming support for Universal Deploy. I'm targeting Netlify first, because I have a better line of communication with them. But I'll make sure to test with Vercel as well as soon as I've verified it works for Netlify.

CC @QuiiBz

[bellcoTech]

Thanks @Tobbe, and really appreciate all the work you do here.

[lisa-assistant]

Implementation Plan

Summary

The root cause is in the Vercel toolchain, not Cedar — but there are meaningful things Cedar can do short-term (documentation + build-time warning) while the long-term fix (Universal Deploy) lands.

---

Root cause

Prisma 7's default generatedFileExtension = "mts" emits a Prisma client whose files contain TypeScript syntax (client.mts, enums.mts, etc.). @vercel/redwood calls nodeFileTrace from @vercel/nft, which uses acorn (vanilla JS parser) to trace imports. Acorn chokes silently on TS syntax; NFT returns { deps: [], imports: [] } for every .mts file it encounters. The entry file (client.mts) ends up in the bundle because a traced .js file references it, but all of its internal import './enums.mts' chains are dropped, causing runtime ERR_MODULE_NOT_FOUND.

---

Action 1 — Documentation (highest priority, fully Cedar-owned)

File: docs/docs/deploy/vercel.md

Add a Troubleshooting section at the bottom:

## Troubleshooting

### Prisma 7 `.mts` client — `ERR_MODULE_NOT_FOUND` at runtime

If your API lambda throws errors like:

```
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '.../generated/prisma/enums.mts'
```

this is caused by `@vercel/nft` (the dependency tracer used by `@vercel/redwood`) being unable to parse TypeScript syntax in Prisma 7's `.mts`-extension generated client files.

**Workaround for ESM-only projects** (api workspace has `"type": "module"` in `package.json`):

In `schema.prisma`, override the generated extension:

```prisma
generator client {
  provider               = "prisma-client"
  output                 = "./generated/prisma"
  moduleFormat           = "esm"
  generatedFileExtension = "ts"
  importFileExtension    = "ts"
}
```

**Note**: This workaround is only safe for ESM projects. For CJS projects, `.ts` extension is not viable at runtime.

The permanent fix is Cedar's [Universal Deploy](https://github.com/universal-deploy/universal-deploy) support for Vercel, which bypasses `@vercel/redwood` entirely.

---

Action 2 — Build-time warning in cedar deploy vercel

File: packages/cli/src/commands/deploy/helpers/deployHandler.js (or a new vercelChecks.js imported by the Vercel deploy path)

Before running the build commands, detect the problematic config and warn early:

// packages/cli/src/commands/deploy/helpers/vercelChecks.js
import fs from 'node:fs'
import path from 'node:path'
import boxen from 'boxen'
import { getPaths } from '@cedarjs/project-config'

export function warnIfMtsGeneratedClientForVercel() {
  const paths = getPaths()

  // Check schema.prisma for generatedFileExtension = "mts"
  const schemaPath = path.join(paths.api.db, 'schema.prisma')
  if (!fs.existsSync(schemaPath)) return

  const schema = fs.readFileSync(schemaPath, 'utf8')
  if (!/generatedFileExtension\s*=\s*["']mts["']/.test(schema)) return

  // Check if api is ESM
  const apiPkgPath = path.join(paths.api.base, 'package.json')
  const isEsm =
    fs.existsSync(apiPkgPath) &&
    JSON.parse(fs.readFileSync(apiPkgPath, 'utf8'))?.type === 'module'

  const workaround = isEsm
    ? 'Set generatedFileExtension = "ts" in your schema.prisma generator block (safe for ESM-only projects).'
    : 'The .mts workaround is only safe for ESM projects. Consider Universal Deploy for Vercel.'

  console.warn(
    boxen(
      `Prisma 7 .mts client detected — Vercel deploy may fail\n\n` +
      `@vercel/nft cannot parse TypeScript syntax in .mts files, which will\n` +
      `cause ERR_MODULE_NOT_FOUND at runtime.\n\n` +
      `Workaround: ${workaround}\n\n` +
      `See: https://cedarjs.com/docs/deploy/vercel#troubleshooting`,
      { title: 'Vercel deploy warning', borderColor: 'yellow', padding: 1 }
    )
  )
}

Call warnIfMtsGeneratedClientForVercel() at the top of deployHandler when the deploy target is vercel.

Edge cases:

• Prisma schema folder feature: schema.prisma may not be at the default path. Use getPrismaSchemas() from @cedarjs/project-config to locate all schema files and check each.
• Users on Prisma < 7 won't have this setting and won't be affected.

---

Action 3 — Upstream issues (not Cedar code)

Two upstream issues should be filed to push the fix into the right tools:

1. vercel/vercel against packages/redwood: copy api/db/generated/**/* into each function bundle after nodeFileTrace, or switch from nodeFileTrace to @swc/core-backed tracing for .mts/.ts files.
2. vercel/nft: add .mts/.cts to the set of extensions handled by the TS-aware parser path (pre-strip types before acorn via typescript or @swc/core).

The issue reporter offered to file these — coordinate with them or file directly.

---

Long-term

Universal Deploy support for Vercel bypasses @vercel/redwood entirely. Once UD is stable for Vercel, this entire issue class is resolved. Tracked under the UD initiative (#1782 and friends).

[lisa-assistant]

Confidence Score: 6/10

Why 6?

The root cause is entirely in @vercel/redwood / @vercel/nft — Cedar can't fix it directly. The two things Cedar can do are:

• Docs (Action 1): Straightforward — 9/10 confidence. Write the troubleshooting section, done.
• Build-time warning (Action 2): ~7/10. Reading schema.prisma with a regex is reliable, but the Prisma schema folder preview feature means the path isn't always api/db/schema.prisma.
• The actual problem (making the Vercel deploy work): 3/10. That requires either an upstream change in @vercel/nft or @vercel/redwood, or shipping Universal Deploy for Vercel. Cedar can file upstream issues and document workarounds, but can't ship the fix itself.

The 6 reflects the combination: Cedar can meaningfully improve the experience (docs + warning), but can't fully resolve the issue until UD lands or Vercel ships a fix.