v1.4.0

Highlights

Route-level generic request & response typing is the headline of this release: route handlers can now opt into strongly typed inputs and outputs that are enforced at compile time — with zero changes required to existing code.

✨ Features

• Generic Request/Response typing for routes — Middleware, ErrorHandlingMiddleware, and HandlerFunction now accept <TRequest, TResponse> generics, and every route method (get, post, put, patch, delete, options, head, any, METHOD) plus use carries them through to your handlers. Response<TBody> enforces the response payload shape on send, json, and jsonp. Fully backward compatible — generics default to today's Request/Response. (#320)

  interface TypedRequest extends Request {
    params: { thingId: string };
  }
  
  api.get<TypedRequest, Response<{ hello: string }>>('/typed', (req, res) => {
    res.json({ hello: req.params.thingId }); // payload shape checked at compile time
  });

🔒 Security

• Prototype pollution hardening in use() — middleware argument iteration moved from for-in to for-of, so enumerable Array.prototype methods added by third-party libraries can no longer leak into the args scan and trigger a spurious ConfigurationError: Middleware must have 3 or 4 parameters. (#321)

🐛 Bug Fixes

• Middleware inheritance for base-pathed root (/) routes — when an API is configured with a base path, handlers registered on / now correctly inherit wildcard middleware, making /base-path/ behave consistently with its non-root siblings. (#319)

🔧 CI / Internal

• npm release workflow — the published version is now stamped at publish time from the release tag, and a manual workflow_dispatch trigger allows publishing a specific version on demand. (#318)

Full Changelog: v1.3.0...v1.4.0