@web-ts-toolkit/express-response-handler 0.42.2 → 0.44.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +29 -8
- package/create-handler.js +376 -117
- package/create-handler.mjs +376 -117
- package/http-response.d.mts +10 -10
- package/http-response.d.ts +10 -10
- package/http-response.js +146 -38
- package/http-response.mjs +146 -38
- package/index.js +376 -117
- package/index.mjs +376 -117
- package/llms.txt +21 -2
- package/package.json +28 -8
- package/public-types.d.mts +11 -2
- package/public-types.d.ts +11 -2
- package/responses/csv.d.mts +23 -0
- package/responses/csv.d.ts +23 -0
- package/responses/csv.js +136 -28
- package/responses/csv.mjs +136 -28
package/README.md
CHANGED
|
@@ -4,8 +4,22 @@ FastAPI-style return-value responses for Express.
|
|
|
4
4
|
|
|
5
5
|
## Installation
|
|
6
6
|
|
|
7
|
+
Requires Node.js `>=22` and Express `^5` (peer dependency, installed separately).
|
|
8
|
+
|
|
9
|
+
```sh
|
|
10
|
+
pnpm add @web-ts-toolkit/express-response-handler @web-ts-toolkit/http-errors express
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
The quickstart below imports `express` and `@web-ts-toolkit/http-errors`
|
|
14
|
+
directly, so both must be direct dependencies. `@web-ts-toolkit/http-errors`
|
|
15
|
+
is also a transitive dependency of this package, but transitive packages are
|
|
16
|
+
not importable from an isolated consumer (pnpm), so listing it directly is
|
|
17
|
+
required when route code throws typed errors.
|
|
18
|
+
|
|
19
|
+
For TypeScript consumers:
|
|
20
|
+
|
|
7
21
|
```sh
|
|
8
|
-
pnpm add @
|
|
22
|
+
pnpm add -D typescript @types/express @types/node
|
|
9
23
|
```
|
|
10
24
|
|
|
11
25
|
## Highlights
|
|
@@ -108,20 +122,23 @@ import { handleResponse, HttpResponse } from '@web-ts-toolkit/express-response-h
|
|
|
108
122
|
|
|
109
123
|
## Documentation
|
|
110
124
|
|
|
111
|
-
Full package documentation
|
|
125
|
+
Full package documentation: https://web-ts-toolkit.pages.dev/docs/packages/express-response-handler
|
|
112
126
|
|
|
127
|
+
- source: `website/docs/packages/express-response-handler.md` in the repository
|
|
113
128
|
- live docs: https://web-ts-toolkit.pages.dev/docs/packages/express-response-handler
|
|
114
129
|
|
|
115
130
|
## Hooks
|
|
116
131
|
|
|
117
132
|
Hooks are observational side effects. They receive the value or error being handled, may return `void` or `Promise<void>`, and returned values never transform the response payload.
|
|
118
133
|
|
|
119
|
-
- `preJson` runs before a non-`undefined` success value is serialized.
|
|
120
|
-
- `postJson` runs after the HTTP response emits `finish` for a successful JSON, `HttpResponse`, or CSV response.
|
|
121
|
-
- `preError` runs before an error response is serialized.
|
|
122
|
-
- `postError` runs after the HTTP response emits `finish` for an error response.
|
|
134
|
+
- `preJson` runs before a non-`undefined` success value is serialized. It is skipped when the handler returns `undefined` or has already taken manual response ownership (for example a synchronous `res.*` write that committed headers).
|
|
135
|
+
- `postJson` runs after the HTTP response emits `finish` for a successful JSON, `HttpResponse`, or CSV response. It never runs for fallback JSON errors (circular/BigInt serialization, rejected `preJson`, CSV-before-output failures) or for manual `undefined` responses.
|
|
136
|
+
- `preError` runs before an error response is serialized, including success-path fallback errors. It always observes the original failure value.
|
|
137
|
+
- `postError` runs after the HTTP response emits `finish` for an error response, including fallback JSON errors. It receives the same failure that was sent (the original, or the `preError` failure when `preError` itself fails).
|
|
123
138
|
|
|
124
|
-
If a handler returns `undefined`, the library assumes the handler owns the response and
|
|
139
|
+
If a handler returns `undefined`, the library assumes the handler owns the response and runs no success hooks (`preJson`/`postJson`) and emits no unsolicited `500`. `postJson` and `postError` do not run on client `close` or on partial responses that never successfully finish an error body.
|
|
140
|
+
|
|
141
|
+
Success-path serialization, `preJson`, and CSV-before-output failures go through one bounded error lifecycle: one `preError`, one redacted error body, and one finish-timed `postError`. A failing `preError`/provider is never re-entered. When headers are already committed (partial write), the owned failure is delegated to Express error middleware with `next(err)` and no second body.
|
|
125
142
|
|
|
126
143
|
Pre-hook failures are routed through the normal error response path. Post-hook failures happen after the response has completed, so they are passed to Express with `next(err)` for server-side logging/observability without creating a second client response.
|
|
127
144
|
|
|
@@ -158,4 +175,8 @@ return new CSVResponse(rows, {
|
|
|
158
175
|
});
|
|
159
176
|
```
|
|
160
177
|
|
|
161
|
-
See
|
|
178
|
+
See the root import measurement and CSV formula-injection policy rationale in
|
|
179
|
+
[`ERH-12.md`](https://github.com/egose/web-ts-toolkit/blob/main/packages/express-response-handler/ERH-12.md)
|
|
180
|
+
in the repository (dev note, not shipped in the published package).
|
|
181
|
+
|
|
182
|
+
Direct `CSVResponse.streamCsv(res)` error ownership (no breaking change): pre-output failures (invalid filename, failed first read, first-row processor throw) with an `onBeforeOutputError` callback invoke it exactly once and the owner terminates `res` (the handler owner renders one redacted JSON error); a throwing owner is contained and `res` is destroyed with the original failure. Without a callback the destination is destroyed with the normalized failure (observable via `error` + `close`). Post-output failures always destroy the destination. Non-`Error` failures are wrapped with the original as `cause`.
|