Imported by: lib/express.js only.

Express itself never reads a request body. req.body exists only if some middleware populated it, and the middleware Express endorses is body-parser -- historically part of Express core, split out in 4.x, and re-exported here so applications need no separate install:

var bodyParser = require('body-parser')
// …
exports.json = bodyParser.json
exports.raw = bodyParser.raw
exports.text = bodyParser.text
exports.urlencoded = bodyParser.urlencoded

That is the entire integration -- four property assignments. express.json() is bodyParser.json(); there is no wrapping layer. The division of labor: body-parser handles content-type matching (via type-is), charset validation, inflation of gzipped bodies, and size limits; Express provides the pipeline position (app.use) and the error route (parse failures call next(err) with an http-errors error carrying a 4xx status).

Why re-export instead of bundling

Body parsing is policy-heavy -- limits, accepted types, strictness -- and many deployments want none of it (proxies, static servers) or a different codec entirely. Keeping it a separate package with a re-export gives the common case one-line ergonomics without forcing the parser into every request path. A body parser only touches requests whose Content-Type matches its type option; everything else passes through untouched.

Usage in this repo

The examples use the re-exports exactly as an application would. examples/cookies/index.js:

// parses x-www-form-urlencoded
app.use(express.urlencoded())

and examples/route-separation/index.js passes the option that switches urlencoded parsing to qs semantics:

app.use(express.urlencoded({ extended: true }))

The contract, per the tests

This repo carries four test files -- test/express.json.js, test/express.urlencoded.js, test/express.text.js, test/express.raw.js -- that pin the re-exported behavior rather than trusting the dependency blindly. From test/express.json.js, the edge cases worth knowing:

• "should parse JSON" -- the base case: Content-Type: application/json yields a parsed req.body.
• "should handle Content-Length: 0" and "should handle empty message-body" -- both produce {}, not an error.
• Later blocks cover the limit, strict, type, and verify options, invalid-JSON 400s with entity.parse.failed error types, and charset/encoding rejection (415 charset.unsupported).

The json test file also asserts that parsing preserves AsyncLocalStorage context across the async body read -- a Node-integration guarantee added for Express 5.

One historical note visible in test/support/env.js: NO_DEPRECATION = 'body-parser,express' -- body-parser is the one dependency whose deprecation warnings the suite explicitly silences, a trace of how often its defaults have shifted underneath Express majors.