Conversation
arnavsurve
left a comment
There was a problem hiding this comment.
Clean, well-structured PR. The rule logic is correct, tests cover the main scenarios, and integration follows existing conventions. A couple of minor observations below, but nothing blocking.
🤖 Generated with Claude Code
| } | ||
|
|
||
| // Also allow String() or toString() wrapping encodeURIComponent inside | ||
| if (t.isCallExpression(expr)) { |
There was a problem hiding this comment.
Nit: The comment says "Also allow String() or toString() wrapping encodeURIComponent inside" but toString() (a method call, i.e. expr.toString()) is not actually handled here -- only function-call wrapping like String(encodeURIComponent(...)) is detected. The code is fine, but the comment is slightly misleading. Consider updating it to just say "Also allow function calls wrapping encodeURIComponent, e.g. String(encodeURIComponent(...))".
| const results = lint(code); | ||
| expect(results).toHaveLength(0); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
Minor: There's no test for the nested wrapping allowance path (lines 32-40 of the rule), e.g.:
it('allows String(encodeURIComponent(...)) wrapped values', () => {
const code = 'const url = `https://api.example.com?q=${String(encodeURIComponent(query))}`;';
const results = lint(code);
expect(results).toHaveLength(0);
});Worth adding to ensure that code path stays covered.
Summary
url-params-must-encoderule that flags template literal interpolations in URL query parameter positions not wrapped inencodeURIComponent()?key=${value}and&key=${value}patternsencodeURIComponent()wrapping and nested wrappingTest plan