Enable @typescript-eslint/recommended(-type-checked) in create-next-app --typescript

[JoshuaKGoldberg]

Describe the feature you'd like to request

Right now, Next.js projects created with create-next-app --typescript use the TSESLint parser for TypeScript projects -great!- but haven't enabled any of its preset configurations. Those configurations are recommended for most-to-all TypeScript projects by the TSESLint maintenance team (including @armano2, @bradzacher, @JamesHenry, and myself; CCing). At the very least they'd resolve some of the issues mentioned in #27051 around detecting floating promises.

To verify the list of ESLint rules used in an app newly created with create-next-app --typescript, you can run:

npx eslint --print-config pages/index.tsx > rules.json

Is there a particular reason not to include the @typescript-eslint/recommended and @typescript-eslint/recommended-requiring-type-checking @typescript-eslint/recommended-type-checked edit: updated for the v6 streamlining of the config configs for CNA users by default?

A couple of notes on why that's likely more desirable now than in the past:

• The recommended configs should no longer contain opinionated rules that wouldn't be good in most projects
• If there are still overly chafe-y rules, we're gearing up for a 6.X release and would be happy to move those to the new strict configuration Edit: we did this already 🙂

Cheers!

Describe the solution you'd like

1. Make a next/typescript lint config in eslint-plugin-next that extends from @typescript-eslint/recommended and @typescript-eslint/recommended-requiring-type-checking @typescript-eslint/recommended-type-checked edit: updated for the v6 streamlining of the config
2. In create-next-app, when --typescript is provided, change the .eslintrc.json file contents to:

   {
     "extends": [
       "next/core-web-vitals",
       "next/typescript"
     ]
   }

Note that this was started in #28181 by @kyliau.

Describe alternatives you've considered

@kyliau brought up a good point in #28181 that this adds a dependency on the @typescript-eslint/eslint-plugin package -which is separate from @typescript-eslint/parser- for JS consumers. An alternative approach could be to have both of those be added to package.json and .eslintrc.js as described in https://typescript-eslint.io/docs/linting/ only for --typescript users.

Edit July 11th, 2023: renamed from recommended-requiring-type-checking to recommended-type-checked per Announcing typescript-eslint v6

[JoshuaKGoldberg]

I talked a bit with @anthonyshew (thanks for the advice Anthony!) about which benefits of the linting presets are most salient for Next.js & its team. The main points are:

Embracing the Ecosystem Standard

Extending the recommended rulesets is how you're strongly encouraged to use typescript-eslint. We've been working on getting more of the ecosystem to use them (typescript-eslint/typescript-eslint#6760). For example, Remix is on the recommended config and will soon be on recommended-type-checked.

A flip side of not using the standard is that Next.js isn't dogfooding/using the rules that many users are. See https://twitter.com/jullerino/status/1676926270309793794 as an example: the @typescript-eslint/require-await is a popular and useful rule, but Next.js server actions don't play well with it.

Fixing Common Issues

The Next.js team has had to deal with a trickle of user reports caused by bad practices that would be caught by the typescript-eslint recommended rules. @typescript-eslint/no-floating-promises is an exemplar of a rule that would help with some of them. "Floating" Promises break stack traces and can cause unexpected program hangs or crashes:

• @leerob mentioned "forgetting to await an async function" in Common Next.js issues that could use integrated ESLint rules #27051 (comment)
• Discussion from this year on how they cause pain: [edge] improve fetch stack traces in edge runtime #44750 (comment)
• Users getting confused by floating Promises: https://www.reddit.com/r/nextjs/comments/13dej9f/i_need_help_with_nextrouter_and_asyncawait/, Document router.push returns a promise #31337 / router.push returns a promise #31278,

In general, the recommended rules help flag common bugs and misuses of TypeScript - which improves the Next.js dev experience and can help reduce the amount of incoming issue reports.

[anthonyshew]

Love it, @JoshuaKGoldberg! I talked to @timneutkens real quick and our idea that it might help with a lower triage burden didn't turn out. However, Tim also did agree this should be done, anyway!

Would you be able to make a PR? Server Actions would be a spot where we would need to pay special attention that I can think of. There may be others. 🤔

[JoshuaKGoldberg]

Amazing! Yes, absolutely - I'll send a PR. Thanks!

[rwieruch]

Glad that someone brought up this topic! For my new Next.js Book I wanted to provide students with standard ESLint rules such as no-floating-promises which imo are super important, especially when dealing with serverless environments. However, the setup was quite tedious and I would not want to have beginners to go through it. So yeah, it would be awesome to just activate a eslint-typescript (or have it by default) rule such as no-floating-promises 🚀

[karlhorky]

Cross-linking this to the "async functions discouraged in event handler props" topic that has been trending recently

Just want to highlight that enabling the @typescript-eslint/recommended-type-checked preset without any further configuration will cause ESLint warnings / errors on async functions passed to event handler props:

(because of the recommended-type-checked configuration of @typescript-eslint/no-misused-promises):

typescript-eslint Playground

index.tsx

import 'react';

export default function Component() {
  return <button onClick={async () => 0} />;
}

Error message:

Promise-returning function provided to attribute where a void return was expected. eslint (@typescript-eslint/no-misused-promises)

Source: DefinitelyTyped/DefinitelyTyped#66505 (comment)