feat(ts): implement caughtErrorCauses rule

[jcamino]

PR Checklist

• Addresses an existing open issue: fixes 🚀 Feature: Implement caughtErrorCauses rule (TypeScript) #1306
• That issue was marked as status: accepting prs — caveat: The issue is labeled status: blocked (its original draft, feat(ts): implement caughtErrorCauses rule #1363, was blocked on 🚀 Feature: Create a scope manager for TypeScript #400 scope analysis — 🚀 Feature: Create a scope manager for TypeScript #400 has since closed; see below) — this PR is the revival of that draft, opened as a draft for maintainer review
• Steps in CONTRIBUTING.md were taken

Overview

Draft revival — opening for maintainer review, not asserting merge-readiness.

Revives #1363 (caughtErrorCauses), which stalled on the legacy rule API and on #400. This branch ports it to the current ruleCreator.createRule(language, …) + visitor-services API.

The rule reports throw new <Error>(…) inside a catch block when no cause option is passed, so the original error chain isn't lost.

Porting notes

• The old preset: "logical" + strictness: "strict" pair maps to presets: ["logicalStrict"] — flag if you'd rather have it in both tiers.
• hasErrorCause was simplified to the presence check it always effectively was: the original compared the cause initializer against the catch parameter but then returned true unconditionally, so the comparison was dead code. Any cause: property still satisfies the rule (e.g. { cause: wrapError(error) }).
• The cause detection was then aligned with ESLint preserve-caught-error's semantics, fixing three false positives the original draft had:
  • AggregateError takes its options as the third argument — new AggregateError([e], "msg", { cause: e }) is now valid (and new AggregateError([e], "msg") is now correctly reported).
  • Shorthand { cause } and string-literal { "cause": e } keys are now recognized.
  • Unknown-shaped options don't report: options passed as a variable, spread arguments at/before the options slot, and object literals containing spreads are treated as unanalyzable, same as ESLint's UNKNOWN_CAUSE bail-out.
• An undefined guard on the options argument was added for noUncheckedIndexedAccess.
• Test fixtures reference console, so the test uses domLibRuleTester; fixtures cover all the cases above.

The #400 blocker has lifted — follow-up opportunity

#1363 was marked blocked because verifying that the thrown error's cause is actually the caught error (vs. any value) needs scope analysis (#400). The TypeScript scope manager has since landed (#2828, extended in #2916 with ScopeManager.getScope). This revival preserves the original lenient behavior; tightening it to verify the caught error flows into the cause (directly or wrapped) is now implementable and left as a maintainer-scoped decision — happy to do it in this PR or a follow-up if wanted.

Files

• packages/ts/src/rules/caughtErrorCauses.ts — the rule
• packages/ts/src/rules/caughtErrorCauses.test.ts — co-located rule-tester snapshots
• packages/site/src/content/docs/rules/ts/caughtErrorCauses.mdx — docs
• packages/ts/src/plugin.ts — alphabetical registration
• packages/comparisons/src/data.json — entry flipped to status: implemented
• .changeset/caught-error-causes.md

Local gates

eslint --max-warnings 0 · tsc -b packages/ts · vitest (17/17, rule test) · comparisons/data.test.ts (28/28) · prettier --check — all pass locally.

🤖 Generated with Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: 21ed556

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@flint.fyi/ts	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[netlify]

❌ Deploy Preview for flint-fyi failed.

Name	Link
🔨 Latest commit	21ed556
🔍 Latest deploy log	https://app.netlify.com/projects/flint-fyi/deploys/6a28b165fef87f0008a54811

[kovsu]

Hi, thanks for your contributions.

To be clear, we don't have any issue with AI-generated code itself. However, as a first-time contributor, you may not yet have enough familiarity with the project's architecture, coding conventions, and established patterns to effectively steer AI-generated suggestions. This can sometimes lead to changes that don't align well with the codebase, creating additional review overhead and maintenance challenges.

For example, the new code we're adding now is specifically designed to avoid these issues(#2395, #2772 and #1404), but the AI-generated code you submitted managed to hit every single pitfall we were trying to avoid.

[JoshuaKGoldberg]

👋 @kovsu, thanks for the thoughtful response - but @jcamino is working with me on this. These PRs won't be moved from draft to review-requested until a human (jcamino) has fixed them up to be ready.