Router() base-path mounting middleware-order consistency across NODE_ENV

Short answer

Middleware order is fully deterministic and identical across NODE_ENV values. Express executes its pipeline strictly in registration order: everything registered with app.use() before app.use('/api', router) runs first for matching requests; anything registered after the mount runs only if the router fell through (no route matched, or a handler called next() without ending the response). NODE_ENV does not change this ordering, and it does not change express.json() parsing behavior. Error-handling middleware attached after the mount is the correct, reliable pattern — with one version-dependent caveat about async handlers.

Middleware before vs. after the mount

When a request matches the base path, the sequence is:

1. App-level middleware registered before the mount (sees the full original URL).
2. The router's own stack, where req.url is stripped of the mount prefix and req.baseUrl holds it (e.g., a request to /api/users arrives inside the router as req.url === '/users', req.baseUrl === '/api').
3. App-level middleware after the mount — only reached if the router called next() past all its routes. This is why a 404 handler and error handler belong here.

If a route inside the router sends a response, post-mount middleware never executes. That is expected behavior, not an inconsistency.

express.json() and NODE_ENV

express.json() behaves identically in development and production. Parsing rules, the 400 error on malformed JSON (delivered via next(err)), and payload limits do not depend on NODE_ENV. What NODE_ENV=production actually changes in Express are defaults like view caching, etag generation, and whether the default error handler includes stack traces in responses.

The common real-world cause of "works in dev, breaks in prod" is not Express itself but application code that registers middleware conditionally — for example, mounting a logger or body parser only when NODE_ENV !== 'production'. If your environments diverge, audit your own conditional app.use() calls first.

Error handlers after the mount

Yes, attaching a four-argument error handler after all routers is the standard pattern and reliably catches synchronous throws and next(err) calls from mounted routes, including body-parser 400s. The caveat is async handlers:

• Express 4: rejected promises from async handlers are not forwarded to error middleware. You get an unhandled rejection and a hung request. Wrap handlers or use a helper that forwards rejections to next().
• Express 5: rejected promises are forwarded to error-handling middleware automatically.

Check your major version with npm ls express before relying on either behavior.

Verifying consistency in your app

Three quick checks confirm a repeatable pipeline:

# 1. Confirm the Express major version
npm ls express

# 2. Run the same smoke test in both environments
NODE_ENV=development node server.js &
NODE_ENV=production node server.js &

Then: add a temporary log line in each middleware and hit a mounted route in both modes — execution order should be identical. Send a malformed JSON body (curl -X POST -H 'Content-Type: application/json' -d '{bad' http://localhost:3000/api/route) and confirm your custom error handler, not the default, responds in both environments. Finally, log req.baseUrl and req.url inside a router handler to confirm prefix stripping. If any of these differ between environments, the cause is conditional registration in your code, not Express.