Skip to content

feat: bodyReaders option (0.5.1) - #2

Merged
Gabriel (gabrielstuff) merged 1 commit into
mainfrom
feat/body-readers
Oct 6, 2026
Merged

Gabriel (gabrielstuff) merged 1 commit into
mainfrom
feat/body-readers

Conversation

@gabrielstuff

@gabrielstuff Gabriel (gabrielstuff) commented Oct 6, 2026 •

Copy link
Copy Markdown
Member

Lets an app declare its own request-body readers (for example a size-capped readJsonBody). The unvalidated-body check then requires their result to be .parse()d, like readBody.

  • Calls with a type argument (readJsonBody<Input>(event)) are matched.
  • The reader's own definition line is not reported.

Verified on an app that uses readJsonBody: 0.5.1 + config gives a clean full gate, and an unparsed readJsonBody call is reported.

🤖 Generated with Claude Code


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.

…ated-body check (0.5.1)

- `bodyReaders: ['readJsonBody']` checks a wrapper like readBody,
  including calls with a type argument (`readJsonBody<Input>(event)`).
- A reader's own definition line is not reported.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 6, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-06T14:58:04.963014Z 0032cd4 PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@kora-operator

kora-operator Bot commented Oct 6, 2026

Copy link
Copy Markdown

PR #2 — feat: bodyReaders option (0.5.1) — review

Nice, focused change: the unvalidatedReadBody check now also covers app-declared body readers via a new bodyReaders option, with the definition line excluded and type-argument calls matched. Tests, config types, docs, and CHANGELOG are all updated coherently, and the version bump (0.5.0 → 0.5.1) is consistent across package.json, README, and the example.

Two small things I noticed in src/checks.js:

  1. Nested generics will be missed — the call regex (?:<[^>]*>)?\s*\( stops at the first >. A call like readJsonBody<Map<string, Input>>(event) won't match. Rare, but worth a follow-up or a comment if you don't care.
  2. Only function definitions are excluded — a reader defined as const readJsonBody = async (…) => … would still be reported as a "call". Same trade-off existed for readBody before, so maybe fine.

Assessment: mergeable, no conflicts, CI still running (test 22/24 queued, Socket alert check in progress). Risk level "high" is mostly procedural — no approvals yet and it touches package.json (version bump). The [code]smith check is "skipped", not failing.

I won't merge anything without an explicit go — want me to keep an eye on CI and squash-merge once green, or leave it for human review?

@gabrielstuff
Gabriel (gabrielstuff) merged commit dcfbdc6 into main Oct 6, 2026
6 checks passed
@gabrielstuff
Gabriel (gabrielstuff) deleted the feat/body-readers branch October 6, 2026 14:56

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0032cd4d8c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "Codex (@codex) review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "Codex (@codex) address that feedback".

Comment thread src/checks.js
export const unvalidatedReadBody = check('Unvalidated readBody', function* (ctx) {
const readers = ['readBody', ...(ctx.options?.bodyReaders ?? [])].join('|')
// `readJsonBody<Input>(event)`: an optional type argument sits between the name and the call
const call = `(?:<[^>]*>)?\\s*\\(`

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Match nested generic type arguments

When a configured reader is called with a common nested type such as readJsonBody<Partial<Input>>(event) or readJsonBody<Array<Input>>(event), [^>]* stops at the inner closing bracket and the remaining > prevents the regex from matching. The unvalidated body therefore passes the gate, despite the feature explicitly supporting type arguments.

Useful? React with 👍 / 👎.

Comment thread src/checks.js
const PARSED = /safeParse\s*\(|\.parse\s*\(/

export const unvalidatedReadBody = check('Unvalidated readBody', function* (ctx) {
const readers = ['readBody', ...(ctx.options?.bodyReaders ?? [])].join('|')

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Escape configured reader names before building regexes

Because each configured name is interpolated as regex syntax, a valid JavaScript identifier containing $, such as read$JsonBody, becomes an end-of-input anchor and its calls are never checked. Other regex metacharacters can change matching or make construction throw; escape each configured name before joining the alternatives.

Useful? React with 👍 / 👎.

Comment thread src/checks.js
Comment on lines +130 to +131
// the reader's own definition (`function readJsonBody<T>(`) is not a call
const READ_BODY = new RegExp(`(?<!function\\s+)\\b(${readers})\\s*${call}`)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Exclude method declarations from body-reader calls

The definition guard only recognizes declarations containing the function keyword, so a configured reader declared with TypeScript method syntax, such as async readJsonBody<T>(event: H3Event) {, is treated as an invocation and reported. This creates an unavoidable gate failure for class/object methods and interface method signatures even though no request body is read on that line.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant