BREAKING(http/unstable): split parseProblemDetails, validate status, add statusText option#7117
BREAKING(http/unstable): split parseProblemDetails, validate status, add statusText option#7117tomas-zijdemans wants to merge 4 commits into
Conversation
…add statusText option
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #7117 +/- ##
=======================================
Coverage 94.61% 94.61%
=======================================
Files 634 634
Lines 51801 51815 +14
Branches 9329 9336 +7
=======================================
+ Hits 49011 49025 +14
Misses 2216 2216
Partials 574 574 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
lunadogbot
left a comment
There was a problem hiding this comment.
Split looks right — keeping parseProblemDetails for plain input and giving the async path its own name parseProblemDetailsResponse removes the overload without forcing sync callers to migrate. Number.isInteger correctly rejects NaN/Infinity/3.14/"500" (the test loop in createProblemDetailsResponse() throws RangeError for non-integer status covers all four). The statusText spread ({ statusText } only when defined) preserves the prior platform default — assertEquals(response.statusText, "") in the unset case confirms.
- nit:
@see {@link https://www.rfc-editor.org/rfc/rfc9457.html}was dropped from the module JSDoc. Prose still names RFC 9457 but the clickable link is gone.
|
@bartlomieju this is ready to merge |
parseProblemDetailsinto sync (unknowninput) and asyncparseProblemDetailsResponse.statusTextoption toProblemDetailsResponseOptions, forwarded toResponseonly when defined.RangeErrorfor non-integer status increateProblemDetailsResponse.ProblemDetailsExtensionsJSDoc to honestly describe the intersection-based safety.isProblemDetailsResponsedocs; add@throwstags throughout.Responseparse example; replaceRecord<never, never>defaults withRecord<string, never>.statusTextforwarding, and primitive bodies.