Support alternative linters such as Biome

[shirakaba]

Goals

1. Extract the doctoring logic from next lint and move it to its own independent command (e.g. next doctor)
2. Allow users to lint using their own linters, such as Biome, without wrapping it in a CLI tool like next lint

Non-Goals

1. Providing boilerplate for all possible linters in Next.js itself (instead, it should provide a way for the community and users to provide their own linting boilerplate)

Background

The case against eslint and prettier

Eslint is deprecating formatting rules and community momentum for formatting looks set to move from prettier to Biome. Thus, the current "format with prettier, lint with eslint" setup (which has always pain-points due to mutually exclusive rules and setting up two different tools) is looking less attractive in the long term than simply "format and lint with Biome"..

Users can't bring their own linter

Another discussion has raised the case for documenting how to integrate Biome, but this isn't merely a matter of documentation, as I'll explain below.

As of today, starter templates (at least for Turbo) typically configure projects to lint using next lint. This prevents users from bringing their own linting setups as linting is dependent on the Next.js CLI.

Unfortunately, we can't simply ditch next lint, as it does more than just linting. It does some significant (and valuable) doctoring, too.

next lint, as of v14.0.4, does the following:

• it configures some default values for the CLI flags to pass to eslint. Actually, in most cases, it simply defaults to the same default as the eslint CLI, but it does provides React-appropriate default values for the args --ext and a Next-appropriate --cache-location.
• it sanity-checks the repo for you. Namely, it:
  • checks whether you've installed typescript, @types/react, and @types/node
  • reconfigures (or creates) your tsconfig.json:
    • ensures you have the desired compiler options
    • ensures you have ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"] in your includes array
    • ensures that you have the Next.js plugin { "name": "next" } in your plugins array
    • ensures that you have strict type-checking
    • excludes node_modules
  • checks whether next-env.d.ts has been generated
  • can optionally run a type-check before any linting
• it may finally run eslint. We can avoid running eslint by deliberately omitting an eslint config and either:
  1. setting opts.lintDuringBuild: true (impossible because the value is hard-coded).
  2. setting opts.lintDuringBuild: false (which is the default) and selecting null when prompted which config to start with next time next lint is run. However, this is interactive, so unless we can find a way to pipe the necessary input into it via the shell, I am not sure how we can automate this.

Proposal

1. Deprecate next lint and allow users to use their preferred linter command directly.
2. Move all the doctoring logic into a next doctor command that users could optionally run as part of their linting step.

[JoeSlain]

Legit request, had to implement biome in my turborepo but still had to let next lint run during linting to keep doctoring functions. Would be nice to be able to chose

[wottpal]

This should get more attention. Biome is really becoming a way more performant replacement for the legacy prettier/eslint toolchain.

[l4b4r4b4b4]

Is this a WIP or already supported?

[shirakaba]

No new issues or PRs containing the word "Biome" have been opened on the Next.js repo since I opened this discussion, so there's no indication yet that this proposal is even under official consideration.

[davidlbowman]

Easy +1.

[admmasters]

This really needs to happen.

Nextjs used to feel like it was the future, now it seems to be in a bit of a mire:

• Turbopack is taking far too long and other stacks are thriving on Vite (see Remix and almost every other framework)
• Months without members of the core team even responding to valid issues and suggestions like this

Genuinely starting to ask the question is Nextjs really a good choice now?

[damien-schneider]

+1

[eliasdanielr]

+1

[John-Dennehy]

Would love to see more progress on this. Frustrating to see eslint issues during deployment, when it isn't part of my tool chain.

[Willem-Jaap]

You can add the ignoreDuringBuilds flag to next.config.js

module.exports = {
  eslint: {
    // Warning: This allows production builds to successfully complete even if
    // your project has ESLint errors.
    ignoreDuringBuilds: true,
  },
}

https://nextjs.org/docs/app/api-reference/next-config-js/eslint

[avaltat]

+1

[hgrafa]

+1

[eliasdanielr]

+1

[peterdinis]

+1

[HunteRoi]

+1

[hanan-yara]

+1

[ivanjeremic]

+1

[alexmandrikdev]

+1

[jakst]

Please stop commenting with +1. It creates a bunch of notification noise for those who subscribe to the issue. Instead, add your support to the discussion by upvoting the top post. (And yes, I'm sorry for creating yet another notification -.-)

[rajington]

haha was wrestling with creating another notification myself but had to be said! (also hope this reply doesn't notify everyone!)

depending on how they prioritize their backlog, these +1s that cause others to unsubscribe might actually hurt the chances it gets looked at!

really wish GitHub provided more here, I believe they have more fine-grained "only notify me when it's fixed" notifications for issues, but at the same time some discussion conversations offer alternatives or external updates that I'd hate to miss!

[mcheng-brilliant]

Hello, we were directed to post to GitHub by Vercel support. We had some questions relevant to this discussion.

We have been using next lint as part of our CI to catch linter and formatting issues. However, we discovered that next lint was not linting all of our files. For example, middleware.ts which, per the docs, lives in the root of our project. We revisited the docs and realized that next lint only runs against a fixed set of directories and that list can be manually configured.

Questions we believe that are relevant to this discussion as it pertains to potential design flaws of next lint and would be solved by the next doctor the split proposed:

1. Why doesn't the default config for next lint check all of the known files in a Next.js project? Is it because there's a reason why we shouldn't be linting files like middleware.ts? If so, what are those reasons?
   • next lint not staying up-to-date with Next.js's own project layout can lead to a false sense of security as you may think all deployed code is linted, but it actually isn't. This wouldn't happen in a standard ESLint configured project.
2. For files that Next.js's docs advise putting into the root directory (or any other directory not in the default next lint list), how should we keep our next.config.js's eslint.dirs config up-to-date?
   • We attempted to work around the whitelist approach of next lint by specifying the root and then attempting to blacklist files/directories using .eslintignore. However, that does not appear to work as the ignore file is not used by next lint. This also points towards next lint being a much less of a full solution than using eslint directly.
3. Is there documentation on how we can configure ESLint ourselves with the same flags as next lint so that we can use ESLint and take an approach of linting everything except for what's specified in our .eslintignore file? This would help us solve question 2 much more easily.

[Willem-Jaap]

Hi there, I have struggled with this in the past as well. I'm also very much in favour of a next doctor command.

However, I may be able to steer you in the right direction for taking linting in your own hands:

Ignore the default linting behaviour in builds, before builds, run your own:

module.exports = {
  eslint: {
    // Warning: This allows production builds to successfully complete even if
    // your project has ESLint errors.
    ignoreDuringBuilds: true,
  },
}

https://nextjs.org/docs/app/api-reference/next-config-js/eslint

You can then integrate eslint yourself (e.g. typescript-eslint etc. etc.) in a eslint.config.js file (https://eslint.org/docs/latest/use/configure/)

And run this in your editor or via cli (https://eslint.org/docs/latest/use/command-line-interface)

This custom linting will not include any of the aditional doctoring of next lint.

I really hope this gains traction from maintainers so we are free to use any linting and also have the other powers next lint has.

[warrenbhw]

+1 on this!

[iiAbady]

This is a necessity from now on....

[simonorzel26]

+1

[theklr]

+1

[o8e]

+1

[Willem-Jaap]

@leerob answered my question about this on X:

Definitely want to explore this (Biome looks amazing). It's something that's on our roadmap!

https://x.com/leeerob/status/1820176704662609993

[wlechowicz]

Cool, but means next to nothing, except that it's not being worked on. "On the roadmap" could be 2025 or 2055.

[anagarajah]

+1 On this to support own lint packages into Next JS

[stevecastaneda]

Another +1.

Just migrated to biome and it's so much faster, and didn't realize NextJS was still going to require it's own linting. 😬

[0re5ama]

+1

[DKeken]

[abhishekmmgn]

+1

[lyleunderwood]

Just wanted to point out that since Biome does not currently support custom rules, there is not a clear path to feature parity using biome as an alternative to the next eslint plugin. Until biome supports custom rules or the necessary rules are implemented into core biome, switching to biome as a linter in particular would definitely necessitate sacrificing some of the current features of the eslint plugin. This is obviously not necessarily relevant for other linting tools, but particular to Biome.

That being said, disentangling "doctoring" from linting seems like an obvious step forward.

Also please stop +1 posting.