Document the validate option and cover its remaining branches - #951
Merged
Conversation
Follow-up to #828, which fixed predicates being coerced to true but left the option undocumented and partially covered. - Document `validate: false` and the predicate form in the README, including the coerceTypes interaction: coercion runs as part of validation, so requests a predicate skips aren't coerced either. - Add tests for the default, explicitly-undefined and `false` cases. The explicitly-undefined test is a regression guard — it fails against the old `!!opts.validate`, which turned `validate: undefined` into false and silently disabled validation. - Assert no Ajv validators are built when validate is false. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N2aqJLvFpzQkMSAs7un12V
anttiviljami
changed the title
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
2 participants
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.
Summary
Docs and test follow-up to #828. That PR fixed
validatepredicates being coerced totrue; this one documents the option and covers the branches it left untested. No behaviour changes here.Changes
README — new "Controlling when requests get validated" section under Request validation. The option had no prose documentation at all, which is plausibly why the regression sat unnoticed from 5.11.0 onwards. Covers
validate: false, the predicate form, and thecoerceTypesinteraction: coercion runs inside the validation branch ofhandleRequest, so requests a predicate skips don't get their path/query params coerced either.Tests — three cases added alongside the two from #828:
validateis explicitlyundefinedvalidate: falseskips validation and validator construction (assertsapi.validatorstays undefined)The explicitly-
undefinedcase is a genuine regression guard, not just coverage. I verified it by temporarily restoring!!optsWithDefaults.validateand re-running: it fails, because the old code turnedvalidate: undefinedintofalseand silently disabled validation entirely. That's a distinct bug from the predicate coercion and wasn't covered by #828.JSDoc —
validatenow mentions the predicate form.coerceTypespreviously read "Requires validate to be enabled", which is imprecise now that a predicate can enable it per request.Testing
Full suite green (299 tests, 4 suites),
npm run lintclean,tsc --noEmitclean.🤖 Generated with Claude Code
https://claude.ai/code/session_01N2aqJLvFpzQkMSAs7un12V