Change Request: Support .ts files with TypeScript syntax by default

[JoshuaKGoldberg]

ESLint version

9.19.0

What problem do you want to solve?

Now that Node.js supports .ts files and type stripping by default (explainer post from Marco), ESLint is the last mainstream tool amongst the common (build, format, lint, test) list for many repositories to not support .ts files by default. It would be very convenient for users if they could lint TypeScript syntax directly.

What do you think is the correct solution?

Proposal:

• Add .cts, .mts, and .ts to the list of default checked file extensions
• Support TypeScript syntax in the default parser

This way, folks can get the standard ESLint flow with an eslint.config.* file and no additional configuration.

Participation

• I am willing to submit a pull request for this change.

Additional comments

I think the adding support for .*ts extensions only makes sense if TypeScript syntax is supported out-of-the-box too. An alternative could be to strip out the syntax à la amaro / ts-blank-space - but then I think users would be confused about the lack of linting for that syntax.

Thus, I think this issue is blocked on #19173 (comment):

TSC Summary: This issue proposes starting to make ESLint core rules TypeScript-aware in order to eliminate duplication with typescript-eslint.

TSC Question: Do we want to accept this proposal?

Related:

• TypeScript support? estree/estree#321
  • Previously: Proposal for open-ended type annotations estree/estree#115
• Change Request: Use native Node.js TypeScript loading for eslint.config.ts? #19357 (tangentially)

[nzakas]

Support TypeScript syntax in the default parser

This is a heavy lift for such a short sentence. 😄 To double-check: do you literally mean the parser understands and produces an AST containing TypScript? Or do you mean we should strip TypeScript-specific syntax and produce an AST as if it were JS?

Add .cts, .mts, and .ts to the list of default checked file extensions

I'm not in favor of this. As we're moving more to a world where languages exist in plugins, I don't think adding more default extensions makes sense.

[JoshuaKGoldberg]

do you literally mean the parser understands and produces an AST containing TypScript? Or do you mean we should strip TypeScript-specific syntax and produce an AST as if it were JS?

I'd meant to ideate both, but really just defer to whatever is decided for #19173.

[nzakas]

I think #19173 is only tangentially related in that it's on the topic of TypeScript but doesn't really have any bearing on what the default parser does.

I'm not sure if it makes sense to have TypeScript support built in to the default parser or if it would be better to a separate package so non-TS folks don't pay the extra cost. (The effort for this is sufficiently large that we should be sure to think deeply about it.)

[github-actions]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.

[github-actions]

This issue was auto-closed due to inactivity. While we wish we could keep responding to every issue, we unfortunately don't have the bandwidth and need to focus on high-value issues.