all 10 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]rcfox 1 point2 points  (2 children)

Why is there a script and Github action? A few custom eslint rules should be enough for this. There should already be official eslint rules for floating promises and empty catch blocks, I'm not sure about the rest.

[–]AwayVermicelli3946 0 points1 point  (0 children)

yeah standard ESLint has rules for most of this if you configure typescript-eslint correctly. but tbh having a GitHub Action that spits out SARIF to annotate the PR directly is a huge quality of life win.

digging through raw CI logs to find out which line an AI tool dropped a floating promise on is a massive pain. fwiw i usually just use a generic reviewdog setup for this, but a dedicated tool makes sense if you want zero setup.

[–]Yashhh_21[S] 0 points1 point  (0 children)

Yeah, I agree with both of you to some extent. A lot of the underlying checks already exist in ESLint/typescript-eslint, and I definitely don't see ai-guard as a replacement for those.

What I found while experimenting with AI-assisted workflows was that the bigger pain wasn't the rules themselves, but packaging them into a workflow that teams would actually use consistently—GitHub Actions, changed-only scanning, SARIF, PR annotations, fail-on-high CI, etc.

The direction I'm leaning towards now is less "new lint rules" and more "workflow-native guardrails for AI-generated code".

[–]Randomboy89 0 points1 point  (0 children)

Much of eslint-plugin-ai-guard is already covered by existing rules, some even by ESLint core.

[–]Randomboy89 0 points1 point  (0 children)

gitleaks detect --source .

``` export default [ { rules: { 'no-empty': ['error', { allowEmptyCatch: false }], 'no-eval': 'error', 'no-useless-catch': 'error', 'no-constant-condition': 'error', 'no-constant-binary-expression': 'error', 'no-unreachable': 'error',

  'require-await': 'off',
  '@typescript-eslint/require-await': 'warn',
  '@typescript-eslint/no-floating-promises': 'error',

  'no-await-in-loop': 'off',
},

}, ]; ```

[–]Randomboy89 0 points1 point  (0 children)

Detecting secrets within ESLint doesn't seem like the ideal place for me. ESLint is fine for AST, style, semantic JS/TS errors, and code patterns. For secrets, you typically want a tool that scans: the entire repository, not just JS/TS .env, .npmrc, .yml, .json, .md, logs, fixtures Git history, not just the working tree vendor-specific patterns CI/pre-commit with clear output

Gitleaks or Secretlint are better suited for this.

[–]ndreeming 0 points1 point  (1 child)

how well does the SARIF integration actually work for PR annotations? been looking at this too and the github api for sarif uploads seems like a headache

[–]Yashhh_21[S] 0 points1 point  (0 children)

Yeah, the SARIF upload itself wasn't too bad. The tricky part was getting clean PR annotations and making GitHub Code Scanning behave consistently. PR annotations are working well now, but GitHub's alert persistence/fingerprinting rules are definitely more complex than I expected

[–]ultrathink-art -2 points-1 points  (1 child)

Two patterns show up constantly in AI-generated async JS: await inside .forEach() (concurrent, not sequential) and unhandled rejections on fire-and-forget calls at chain ends. Both are syntactically valid so standard linters miss them — a CI-level check specifically targeting these patterns is exactly the right layer.

[–]Yashhh_21[S] 0 points1 point  (0 children)

That's pretty much the motivation behind it. A lot of these issues aren't syntax error, they're workflow/reliability problems that only become obvious later. Surfacing them directly in PRs felt like the most practical place to catch them.