Problem
There are two related issues in how middleware is organized and wired into the app.
1. Error handler is registered before the routes — so it never catches route errors
In src/index.ts, the error-handling middleware is mounted before any of the application routes are registered:
// src/index.ts (around lines 8 and 41)
import { errorHandler } from "./middlewares/errorHandler";
...
app.use(
(err, req, res, next) => {
errorHandler(err, req, res, next);
}
);
// routes (authRoutes, userRoutes, nftRoutes, etc.) are mounted AFTER this line
Express invokes error-handling middleware only for errors thrown by handlers/middleware that were registered before it. Because the error handler is installed before the routes, it will never receive errors from any route handler. Errors fall through to Express's default handler instead, leaking stack traces and bypassing the project's standardized error response.
2. Duplicate middleware directories: src/middleware/ vs src/middlewares/
The repo has both:
src/middleware/ — contains authMiddleware.ts, rateLimitMiddleware.ts
src/middlewares/ — contains errorHandler.ts
This is inconsistent, confusing for contributors, and makes imports unpredictable.
Proposed Solution
- Consolidate both directories into a single
src/middleware/ (singular). Move errorHandler.ts into it and update all imports.
- Reorder middleware registration in
src/index.ts so the order is:
- body parsers (
express.json)
- CORS
- rate limiting
- routes
- 404 handler
- error handler (last)
- Remove the inline arrow-function wrapper in
index.ts and pass the imported errorHandler directly to app.use(...) (the wrapper currently masks Express's 4-arg signature detection in some setups).
- Add a smoke test in
tests/ that throws inside a route handler (next(new Error("boom"))) and asserts the response shape comes from errorHandler, not Express's default.
- Document the canonical middleware order in
CONTRIBUTING.md.
Acceptance Criteria
Out of Scope
- Refactoring the contents of
errorHandler itself (logging, error classes) — a separate effort.
- Adding new middleware.
Suggested Labels
bug, code-quality, good first issue
Problem
There are two related issues in how middleware is organized and wired into the app.
1. Error handler is registered before the routes — so it never catches route errors
In
src/index.ts, the error-handling middleware is mounted before any of the application routes are registered:Express invokes error-handling middleware only for errors thrown by handlers/middleware that were registered before it. Because the error handler is installed before the routes, it will never receive errors from any route handler. Errors fall through to Express's default handler instead, leaking stack traces and bypassing the project's standardized error response.
2. Duplicate middleware directories:
src/middleware/vssrc/middlewares/The repo has both:
src/middleware/— containsauthMiddleware.ts,rateLimitMiddleware.tssrc/middlewares/— containserrorHandler.tsThis is inconsistent, confusing for contributors, and makes imports unpredictable.
Proposed Solution
src/middleware/(singular). MoveerrorHandler.tsinto it and update all imports.src/index.tsso the order is:express.json)index.tsand pass the importederrorHandlerdirectly toapp.use(...)(the wrapper currently masks Express's 4-arg signature detection in some setups).tests/that throws inside a route handler (next(new Error("boom"))) and asserts the response shape comes fromerrorHandler, not Express's default.CONTRIBUTING.md.Acceptance Criteria
src/middleware/);src/middlewares/is deleted.tsc --noEmitand existing tests pass.src/index.ts, the error handler is the lastapp.use(...)call, registered after all routes and a 404 fallback.errorHandleris passed directly toapp.use(no anonymous wrapper).errorHandlerand returns the project's standardized error JSON.CONTRIBUTING.mddocuments the middleware-order convention.Out of Scope
errorHandleritself (logging, error classes) — a separate effort.Suggested Labels
bug,code-quality,good first issue