feat: add skew-protection-webpack-plugin package#18
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
🔗 Linked repositories identifiedCodeRabbit considers these linked repositories for cross-repo context during reviews:
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/skew-protection-webpack-plugin/README.md`:
- Around line 23-24: Update the Skew Protection README wording in the
behavior/options section to fix the awkward “scope rerouting” phrasing in the
description and make it read naturally, then correct the pattern example in the
options docs so the `patterns` value uses `js|css` rather than an escaped pipe.
Reference the surrounding README text for `patterns` and the behavior
description to locate the two doc nits.
In `@packages/skew-protection-webpack-plugin/src/main.test.ts`:
- Around line 41-46: The compiler callback in main.test.ts is triggering
no-confusing-void-expression because it uses return reject(...) in the err and
stats.hasErrors() branches. Update the compiler.run callback to call reject(...)
as a separate statement and then return on the next line, using the compiler.run
callback as the locator for both failure paths.
In `@packages/skew-protection-webpack-plugin/src/main.ts`:
- Around line 150-156: The assignment in the main plugin loader is failing
`no-unsafe-assignment` because `requirePeer('html-webpack-plugin')` is inferred
as `any` before being stored in `HtmlWebpackPlugin`. Update the `main.ts` logic
around `requirePeer` so the result is explicitly cast to the declared `{
getHooks?: (c: Compilation) => HtmlHooks | undefined }` shape when assigned to
`HtmlWebpackPlugin`, keeping the existing `try/catch` and return behavior
intact.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 37c36d18-36de-419e-89b3-ab21503a9014
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (14)
.github/workflows/release-please.yaml.release-please-manifest.jsonpackage.jsonpackages/skew-protection-webpack-plugin/.gitignorepackages/skew-protection-webpack-plugin/CHANGELOG.mdpackages/skew-protection-webpack-plugin/README.mdpackages/skew-protection-webpack-plugin/package.jsonpackages/skew-protection-webpack-plugin/src/lib/runtime-module.tspackages/skew-protection-webpack-plugin/src/main.test.tspackages/skew-protection-webpack-plugin/src/main.tspackages/skew-protection-webpack-plugin/tsconfig.jsonpackages/skew-protection-webpack-plugin/tsup.config.tspackages/skew-protection-webpack-plugin/vitest.config.tsrelease-please-config.json
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
netlify/blueprints(manual)
| > same-origin request and pin your API/XHR traffic to a stale deploy. The default `patterns` scope rerouting to JS/CSS. | ||
|
|
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Fix two documentation accuracy nits in the behavior/options description.
Line 23 reads awkwardly (“scope rerouting”), and Line 47 shows js\|css instead of js|css, which can confuse users copying the pattern.
Suggested doc patch
-> same-origin request and pin your API/XHR traffic to a stale deploy. The default `patterns` scope rerouting to JS/CSS.
+> same-origin request and pin your API/XHR traffic to a stale deploy. The default `patterns` scope skew protection to JS/CSS assets.
@@
-| `patterns` | `[".*\\.(js\|css)$"]` | PCRE path patterns the edge reroutes on. |
+| `patterns` | `[".*\\.(js|css)$"]` | PCRE path patterns the edge reroutes on. |Also applies to: 47-47
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/skew-protection-webpack-plugin/README.md` around lines 23 - 24,
Update the Skew Protection README wording in the behavior/options section to fix
the awkward “scope rerouting” phrasing in the description and make it read
naturally, then correct the pattern example in the options docs so the
`patterns` value uses `js|css` rather than an escaped pipe. Reference the
surrounding README text for `patterns` and the behavior description to locate
the two doc nits.
| compiler.run((err, stats) => { | ||
| compiler.close(() => {}) | ||
| if (err) return reject(err) | ||
| if (stats?.hasErrors()) return reject(new Error(stats.toString())) | ||
| resolve() | ||
| }) |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Fix the blocking no-confusing-void-expression lint errors.
return reject(...) returns the void result of reject, which is failing the Lint job (lines 43-44). Split the reject call and return onto separate statements.
🔧 Proposed fix
compiler.run((err, stats) => {
compiler.close(() => {})
- if (err) return reject(err)
- if (stats?.hasErrors()) return reject(new Error(stats.toString()))
+ if (err) {
+ reject(err)
+ return
+ }
+ if (stats?.hasErrors()) {
+ reject(new Error(stats.toString()))
+ return
+ }
resolve()
})📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| compiler.run((err, stats) => { | |
| compiler.close(() => {}) | |
| if (err) return reject(err) | |
| if (stats?.hasErrors()) return reject(new Error(stats.toString())) | |
| resolve() | |
| }) | |
| compiler.run((err, stats) => { | |
| compiler.close(() => {}) | |
| if (err) { | |
| reject(err) | |
| return | |
| } | |
| if (stats?.hasErrors()) { | |
| reject(new Error(stats.toString())) | |
| return | |
| } | |
| resolve() | |
| }) |
🧰 Tools
🪛 ESLint
[error] 43-43: Returning a void expression from a function is forbidden. Please move it before the return statement.
(@typescript-eslint/no-confusing-void-expression)
[error] 44-44: Returning a void expression from a function is forbidden. Please move it before the return statement.
(@typescript-eslint/no-confusing-void-expression)
🪛 GitHub Actions: Lint / 0_Lint.txt
[error] 43-43: ESLint (typescript-eslint/no-confusing-void-expression): Returning a void expression from a function is forbidden. Please move it before the return statement.
🪛 GitHub Actions: Lint / Lint
[error] 43-43: ESLint (@typescript-eslint/no-confusing-void-expression): Returning a void expression from a function is forbidden. Please move it before the return statement.
🪛 GitHub Check: Lint
[failure] 44-44:
Returning a void expression from a function is forbidden. Please move it before the return statement
[failure] 43-43:
Returning a void expression from a function is forbidden. Please move it before the return statement
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/skew-protection-webpack-plugin/src/main.test.ts` around lines 41 -
46, The compiler callback in main.test.ts is triggering
no-confusing-void-expression because it uses return reject(...) in the err and
stats.hasErrors() branches. Update the compiler.run callback to call reject(...)
as a separate statement and then return on the next line, using the compiler.run
callback as the locator for both failure paths.
Source: Pipeline failures
| let HtmlWebpackPlugin: { getHooks?: (c: Compilation) => HtmlHooks | undefined } | ||
| try { | ||
| // Resolved from the consumer's dependency tree. | ||
| HtmlWebpackPlugin = requirePeer('html-webpack-plugin') | ||
| } catch { | ||
| return | ||
| } |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Resolve the blocking no-unsafe-assignment lint error.
requirePeer('html-webpack-plugin') returns any, so the assignment to the typed HtmlWebpackPlugin variable trips @typescript-eslint/no-unsafe-assignment and is failing the Lint check. Cast the result to the declared shape.
🔧 Proposed fix
- let HtmlWebpackPlugin: { getHooks?: (c: Compilation) => HtmlHooks | undefined }
+ let HtmlWebpackPlugin: { getHooks?: (c: Compilation) => HtmlHooks | undefined }
try {
// Resolved from the consumer's dependency tree.
- HtmlWebpackPlugin = requirePeer('html-webpack-plugin')
+ HtmlWebpackPlugin = requirePeer('html-webpack-plugin') as {
+ getHooks?: (c: Compilation) => HtmlHooks | undefined
+ }
} catch {
return
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| let HtmlWebpackPlugin: { getHooks?: (c: Compilation) => HtmlHooks | undefined } | |
| try { | |
| // Resolved from the consumer's dependency tree. | |
| HtmlWebpackPlugin = requirePeer('html-webpack-plugin') | |
| } catch { | |
| return | |
| } | |
| let HtmlWebpackPlugin: { getHooks?: (c: Compilation) => HtmlHooks | undefined } | |
| try { | |
| // Resolved from the consumer's dependency tree. | |
| HtmlWebpackPlugin = requirePeer('html-webpack-plugin') as { | |
| getHooks?: (c: Compilation) => HtmlHooks | undefined | |
| } | |
| } catch { | |
| return | |
| } |
🧰 Tools
🪛 ESLint
[error] 153-153: Unsafe assignment of an any value.
(@typescript-eslint/no-unsafe-assignment)
🪛 GitHub Check: Lint
[failure] 153-153:
Unsafe assignment of an any value
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/skew-protection-webpack-plugin/src/main.ts` around lines 150 - 156,
The assignment in the main plugin loader is failing `no-unsafe-assignment`
because `requirePeer('html-webpack-plugin')` is inferred as `any` before being
stored in `HtmlWebpackPlugin`. Update the `main.ts` logic around `requirePeer`
so the result is explicitly cast to the declared `{ getHooks?: (c: Compilation)
=> HtmlHooks | undefined }` shape when assigned to `HtmlWebpackPlugin`, keeping
the existing `try/catch` and return behavior intact.
Source: Linters/SAST tools
Adds a new package that brings Netlify Skew Protection to any webpack-based single-page app, without requiring a framework runtime.
How it works
On a Netlify production build, the platform exposes a signed token that fingerprints the current deploy. The plugin reads that token and does two complementary things:
With both halves in place, the edge sees the pinned requests coming from an open tab and routes them to the originating deploy instead of the latest one.