v1.5.0

Highlights

Native ESM support is the headline of this release. lambda-api now ships a dual CommonJS/ES module build, so import createAPI from 'lambda-api' works without a bundler interop shim, while require() continues to work exactly as before.

This release also brings lambda-api's responses in line with RFC 9110: status codes that must not carry content no longer emit a response body. See Behavior changes below.

✨ Features

• Dual CJS/ESM build — the package now publishes both CommonJS (dist/cjs) and ES module (dist/esm) output behind an exports map, with type definitions for each. Both entry points and the ./lib/* subpaths resolve correctly under either module system. (#326) — thanks @tomassabol!

  // ESM
  import createAPI from 'lambda-api';
  
  // CommonJS — unchanged
  const createAPI = require('lambda-api');

  The optional @aws-sdk/* S3 peer dependencies remain lazily loaded under both builds, so importing lambda-api without them installed still works for non-S3 consumers.

🐛 Bug Fixes

• No response body for null-body status codes — responses with 1xx, 204, 205, or 304 status codes are now sent with an empty body, per RFC 9110. Previously res.sendStatus(204) emitted "No Content" as the body, and res.status(204).json({...}) passed the payload straight through. The check now lives in send(), so every response method inherits it. (#336, #342) — thanks @programmer4285 for the report and the initial fix!

⚠️ Behavior changes

• Any body passed to send(), json(), jsonp(), html(), or sendFile() is discarded when the status code is 1xx, 204, 205, or 304. If you were relying on a body being returned with one of these codes — most likely res.status(204).json(...) — switch to 200 (or 202) to keep the payload.
• res.sendStatus(204) and res.sendStatus(304) now return an empty body instead of "No Content" / "Not Modified".
• UTILS.statusBodyLookup(), added during development of this release, was folded into UTILS.isNullBodyStatus() before shipping. It was never published, so no released version exposed it.

📚 Documentation

• Clarified that the AWS S3 SDK packages are optional peer dependencies, only required if you use res.sendFile() with an s3:// path or res.getLink(). (#324)
• Documented null-body status code behavior in the status() and sendStatus() sections. (#342)

🔧 CI / Internal

• Benchmark suite comparing lambda-api against other Lambda web frameworks. (#327, closes #34)
• Dual-package e2e coverage — new module-compat tests assert both the CJS and ESM outputs load and serve requests, plus a Layer 1 e2e runner and LocalStack suite.
• CI restructured to build the dual package once on Node 20 and run the Node 14–22 test matrix against the prebuilt dist/, since the SWC toolchain requires Node >= 16.14 to build. Runtime support for Node 14 is unchanged.
• GitHub Sponsors funding config. (#328)
• Development dependency bumps: lodash (#329, #314), brace-expansion (#339), fast-xml-parser + @aws-sdk/client-s3 (#340, #313), @smithy/config-resolver (#341), minimatch (#305), flatted (#308), picomatch (#310), plus benchmark-only bumps (#333, #334, #337, #338). lambda-api has no runtime dependencies, so none of these affect installed consumers.

Full Changelog: v1.4.0...v1.5.0