fix(protect): type-safe scaffolded guard.ts (strict TanStack build)#75
Merged
Conversation
A `patchstack-connect protect` install failed `tsc` in the target app with two errors in the scaffolded guard: - `mode` inferred as `string`, not `"block" | "dry-run"` → createProtection arg rejected. Pin the annotation: `const mode: "block" | "dry-run" = …`. - `screenResponse(response: unknown): Promise<unknown>` made the request middleware's server fn return `Promise<unknown>`, which TanStack's RequestMiddlewareServerFnResult rejects. Make it a generic passthrough `screenResponse<T>(response: T): Promise<T>` so `screenResponse(await next())` preserves next()'s return type. Both reproduced + fixed under `tsc --strict` in isolation. Added a scaffolder regression test asserting the guard ships these type-safe signatures. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Introduces explicit union types and generics for strict type safety in guard.ts. 🎯 Quality: 100% Elite · 📦 Size: Small 📈 This month: Your 28th PR — above team average · Averaging Excellent |
Contributor
Author
|
/review |
mariojgt
approved these changes
Jul 14, 2026
patchstackdave
added a commit
that referenced
this pull request
Jul 15, 2026
… rules Two scaffolder features (both build on the #75 guard.ts type-safety fix, included here): Route-level WAF (env-gated, off by default): - guard.ts exports guardRequest(request) — runs the request-phase rules via fetchGuard on a cloned request and returns a 403 on a match (fail-open). - the scaffolded request middleware calls it only when PATCHSTACK_ROUTE_WAF=1, so a plain `GET /?file=../../etc/passwd` gets a 403. Opt-in because it runs broad request rules on all traffic (classic-WAF false-positive surface); the default only screens the data path. `protect --demo`: - seeds a broad, many-class sample rule set (src/protect/templates/demo-rules.json, generated from + kept in lockstep with examples/protect/demo-rules.json minus its _demo vectors) instead of the high-precision starter, and SKIPS baking a site UUID so the local sample rules stay active (a baked UUID makes the guard fetch live Pulse rules instead). - default install now writes the starter rules only if absent (no longer clobbers a customized rules.json on re-run). - disclosed in the CLI help + AGENT-INSTALL.md; PATCHSTACK_MODE / PATCHSTACK_ROUTE_WAF added to the env list. Verified: real CLI `protect --demo` seeds the 11-class bundle; route-WAF blocks a path-traversal URL (403) and allows benign; +8 scaffolder tests incl. a template/examples parity check. 416 tests. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
patchstackdave
added a commit
that referenced
this pull request
Jul 15, 2026
… rules (#77) * feat(protect): opt-in route-level WAF (env) + `protect --demo` sample rules Two scaffolder features (both build on the #75 guard.ts type-safety fix, included here): Route-level WAF (env-gated, off by default): - guard.ts exports guardRequest(request) — runs the request-phase rules via fetchGuard on a cloned request and returns a 403 on a match (fail-open). - the scaffolded request middleware calls it only when PATCHSTACK_ROUTE_WAF=1, so a plain `GET /?file=../../etc/passwd` gets a 403. Opt-in because it runs broad request rules on all traffic (classic-WAF false-positive surface); the default only screens the data path. `protect --demo`: - seeds a broad, many-class sample rule set (src/protect/templates/demo-rules.json, generated from + kept in lockstep with examples/protect/demo-rules.json minus its _demo vectors) instead of the high-precision starter, and SKIPS baking a site UUID so the local sample rules stay active (a baked UUID makes the guard fetch live Pulse rules instead). - default install now writes the starter rules only if absent (no longer clobbers a customized rules.json on re-run). - disclosed in the CLI help + AGENT-INSTALL.md; PATCHSTACK_MODE / PATCHSTACK_ROUTE_WAF added to the env list. Verified: real CLI `protect --demo` seeds the 11-class bundle; route-WAF blocks a path-traversal URL (403) and allows benign; +8 scaffolder tests incl. a template/examples parity check. 416 tests. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(protect): reconcile start.ts guards in place (upgrade existing installs) patchStart previously skipped an already-wired start.ts, so a re-run after a connect upgrade never refreshed the middleware (e.g. an existing app couldn't pick up the new route-WAF hook). Make the generated blocks MANAGED: - wrap each middleware block in `// #region patchstack-guard` … `// #endregion` markers; a re-run replaces the marked region in place (upgrade), and the guard import line is refreshed wholesale. - migrate a legacy (pre-markers) block: bound it from its `const …` line (plus the comment header above) to its terminating `});`, and replace with the marked block. - fresh installs insert as before. All paths stay idempotent (a second run is a no-op). Verified end-to-end: re-running the CLI on a legacy-wired app adds the route-WAF hook + markers + refreshed import with no duplication. +1 upgrade test (417 total). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
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
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.
A real
patchstack-connect protectinstall failed the target app'stscbuild with two errors in the scaffoldedguard.ts:Cause & fix
modewas inferred asstringin the published template → thecreateProtection(...)argument was rejected. Pin it:const mode: "block" | "dry-run" = ….screenResponse(response: unknown): Promise<unknown>(added in feat(protect): scaffold response screening + first scaffolder tests #70) made the request-middleware server fn returnPromise<unknown>, which TanStack'sRequestMiddlewareServerFnResultrejects. Make it a generic passthroughscreenResponse<T>(response: T): Promise<T>, soscreenResponse(await next())preservesnext()'s return type. (Onlyguard.tschanges — thestart.tserror is caused by this signature, so it clears with nostart.tsedit.)Both were reproduced under
tsc --strictin isolation and confirmed fixed. Added a scaffolder regression test asserting the guard ships these type-safe signatures.Note
connect's own typecheck doesn't compile the.tstemplates against a real TanStack app, which is why this slipped through #70. The new assertion is a content guard; a full template-typecheck-against-TanStack pass is a possible follow-up.🤖 Generated with Claude Code