Summary

The webapp's server bundle imports prop-types directly, but the package was declared only as a devDependency. A production install therefore leaves it out and the built server fails to boot:

Failed to start server: Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'prop-types'
  imported from /triggerdotdev/apps/webapp/build/server/assets/server-build-*.js

Moving it to dependencies is the whole change.

Why the bundle imports it

Nothing in the webapp's own code uses prop-types — there is no reference to it, or to PropTypes, anywhere under apps/webapp/app. It arrives through recharts, whose react-smooth dependency still declares propTypes on its components.

That was invisible until recently. While recharts was resolved at runtime, its prop-types import was satisfied inside recharts' own dependency tree, which is production all the way down. #4486 added recharts and victory-vendor to ssr.noExternal to fix a hydration mismatch on every server-rendered chart; that inlines react-smooth into the server bundle, which moves its prop-types import into the webapp's own resolution scope — where the package was not available in production.

So the bundling change was correct about which d3-shape build both sides resolve, and wrong about what the production runtime would be able to find.

Verification

docker/Dockerfile builds the runtime dependencies with pnpm install --prod against a turbo prune --scope=webapp --docker output, so I reproduced exactly that: pruned the workspace, installed with --prod, and imported prop-types from apps/webapp.

It resolves both as a CommonJS require and as an ESM import, which is the form the bundle uses.

I also checked this is not one symptom of a wider problem: of the 169 bare specifier roots the server bundle imports, prop-types is the only one that is a devDependency and not a production dependency. The rest are node builtins or production dependencies.

The hydration fix from #4486 is unaffected — the rebuilt bundle still carries the rounding d3-path build.

Notes

prop-types is inert in production (its entry point swaps in factoryWithThrowingShims), so this adds a 124 KB package that does no work at runtime. It has to be resolvable regardless, because the import is real.

An alternative would be adding prop-types to ssr.noExternal so it is inlined and needs no runtime resolution. That keeps the dependency list honest about the fact that the webapp itself does not use it, at the cost of bundling a CommonJS package into the ESM server output. This route is the smaller, better-understood change.

Worth following up separately: a check that every bare import in the server bundle resolves from a production install would have caught this before it landed. Local development installs every devDependency, so the gap is invisible when the built server is run from a working tree.