fix(types): accept Express/Koa request types in Request constructor#446
Open
dhensby wants to merge 1 commit into
Open
fix(types): accept Express/Koa request types in Request constructor#446dhensby wants to merge 1 commit into
dhensby wants to merge 1 commit into
Conversation
dhensby
force-pushed
the
fix/types-request-framework-compat
branch
from
436eec4 to
b87c558
Compare
Since 5.2.1 the Request constructor typed `headers` and `query` as `Record<string, string>`, which rejects common framework request shapes at compile time — e.g. Express 5's `req.query` (`ParsedQs`, whose values can be nested or `undefined`) and Koa's `IncomingHttpHeaders` (`string | string[] | undefined`). Widen both to `Record<string, any>`, which accepts those shapes while remaining backwards compatible with plain `Record<string, string>` callers. `headers`/`method`/`query` stay required, so a raw Fetch `Request` (which has no `query`) still correctly fails to type-check. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
dhensby
force-pushed
the
fix/types-request-framework-compat
branch
from
b87c558 to
04aa383
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Loosens the
Requestconstructor'sheaders/querytyping fromRecord<string, string>toRecord<string, any>, fixing the compile-time regression introduced in5.2.1(#362) for framework request objects.This addresses the Express/Koa typing-compatibility part of #356 — it does not close it (see Scope).
Why
Since
5.2.1, passing real framework request data fails to type-check:req.queryisParsedQs({ [k]: string | ParsedQs | (string | ParsedQs)[] | undefined }) — not assignable toRecord<string, string>.IncomingHttpHeaders(string | string[] | undefined).string | string[]isn't broad enough (ParsedQshas nested /undefinedvalues), soRecord<string, any>is the value type that accepts them.Backwards compatibility
Record<string, string>callers still compile (string⊆any), and reads stayany-compatible (no forced narrowing), so no consumer breaks.headers/method/queryremain required (matching the runtime, which throws if they're missing), so a raw FetchRequest(noquery) still correctly fails to compile rather than compiling and throwing at runtime.Verified with
tsc: Express 5ParsedQs/ KoaIncomingHttpHeaders/ plain string maps all compile; a query-less object is still rejected.Scope
This is the typing half of #356. First-class Fetch
Requestsupport (the issue's original title) is a separate feature: a FetchRequesthas noqueryand an async-stream body, so it can't be handled in the synchronous constructor — it needs an adapter or a dedicated async entry point. That remains open on #356 to design.🤖 Generated with Claude Code