BTW, I think type checking (Using // @ts-check) currently fails with defineConfig on typescript-eslint config arrays. Try a plain config generated using @eslint/create-config and add // @ts-check to it.

it would be nice to update the typescript-eslint docs to use that instead

ACK on the original suggestion, sorry for the delay - we've been swamped this season and falling behind on issues. This is tentatively likely to be accepted but we'd like to get through supporting the new core config extensions first: #10973. Will respond back soon!

currently fails with defineConfig on typescript-eslint config arrays

That sounds like a separate bug to be filed. If you've got a reproduction you can post in a new issue, please do - we'd love to take a look. Thanks!

Progress - #10973 has been merged!

Nominally, I'd be fully in favor of a gameplan that looks like:

1. feature-freeze tseslint.config() now. Continue to do bugfixes and such, resolving issues as closely to defineConfig() as appropriate (for example as has been done in fix(typescript-eslint): address bugs in config() around global ignores #11065)
2. Switching ourselves internally to defineConfig() and resolving any type incompatibilities between typescript-eslint and ESLint that make this difficult.
3. Then, deprecate tseslint.config() in favor of defineConfig() and switch docs examples.
4. Remove tseslint.config() in a future major version once the minimum ESLint requirement for typescript-eslint includes defineConfig().

However, this directly causes us some heartache with #10841, and, in particular, the closing of eslint/eslint#19438. Hacking functionality into tseslint.config() is being seriously considered in order to provide users an experience where they don't have to explicitly pass import.meta.dirname and/or absolute paths to our tooling in order to read tsconfig files necessary for linting TS. See technical discussion on those issues, but the bottom line is that, until we have another solution, we're rather remiss to close off one of the last remaining options available to support that user experience enhancement, even if it's an unpleasant way to go about supporting it.

While you're making some decisions, I'd like to ask at a minimum you update your examples to also use defineConfig(). We are getting a lot of questions from folks who are trying to use ESLint with typescript-eslint and language plugins like @eslint/json and @eslint/css because the examples assume people are only linting TypeScript. Something like this would go a long way towards addressing that confusion:

// @ts-check

import { defineConfig } from "eslint/config";
import eslint from '@eslint/js';
import tseslint from 'typescript-eslint';

export default defineConfig([
  tseslint.config(
    eslint.configs.recommended,
    tseslint.configs.recommended,
  ),

  // non-TypeScript configs here
]);

At least this way every example users see as they bounce back and forth from the ESLint website to here and then to the language plugins will all look similar enough for them to copy-paste pieces around.

The problem is, we might end up needing to keep the typescript-eslint tseslint.config. I personally don't want to and would prefer the current proposal in #10841 (comment). But there's a chance we as a team end up not being ok with the fancy computed getters in that proposal and wanting to keep to a more explicit tseslint.config() strategy. In that case we'd then end up adding the config back to the typescript-eslint.io docs. Which IMO would be an odd bit of whiplash.

defineConfig([ \n tseslint.config(

😬 That is a bit of extra work that does not look great IMO. I don't think it'd be good for users to go with that, even as a short term patch.

The problem I'm trying to solve is that the current docs actively confuse users. We continue getting these reports and then we have to hold their hands to show them how to use tseslint.config with defineConfig(). The fastest way to solve this problem is for your docs to include defineConfig() just like the core ESLint docs and other plugins do. Placing tseslint.config inside of defineConfig() works the same way as just using tseslint.config, so while it might not look pretty, it does work, and it does follow the conventions we've set forth with defineConfig() (such as using the globalIgnores() helper inside it).

At an absolute minimum, the "without helper" examples should be using defineConfig() right now.

We continue getting these reports

Can you post links to some of these reports? I think that'd be helpful for triage here.

The fastest way to solve this problem is for your docs to include defineConfig() just like the core ESLint docs and other plugins do.

note that for all intents and purposes -- defineConfig === tseslint.config. They do the same thing -- which was the entire reason that I pushed for it on the RFC. Our config function does not mutate the config objects to only apply them to TS files.

Put another way:

export default defineConfig([
  tseslint.config(
    eslint.configs.recommended,
    tseslint.configs.recommended,
  ),
]);

/// is EXACTLY the same as

export default defineConfig([
  eslint.configs.recommended,
  tseslint.configs.recommended,
]);

/// is EXACTLY the same as

export tseslint.config(
  eslint.configs.recommended,
  tseslint.configs.recommended,
);


/// is EXACTLY the same as

export default [
  eslint.configs.recommended,
  ...tseslint.configs.recommended,
];

So nesting defineConfig([ \n tseslint.config( isn't necessary, nor is it correct.

If users are reporting issues with CSS linting then I would hazard a guess that instead the issue is that our docs are written around how people were using ESLint before you introduced CSS support -- they just defined their parsers and rules with no globs.

To be fair -- for ~99.7% ¹ of our users the docs going to guide them towards correctly setting up their codebase as they aren't using ESLint for CSS linting.
You would find that all of the other JS/TS plugins are going to have the same problem with their docs -- they won't have their docs scoped to just JS/TS files.

This is a separate issue to the docs usage of tseslint.config.

Note that the reason we do not currently and have never included globs to limit what files our configs apply to is because people use non-standard extensions for various usecases that consume our tooling. And until now (with the introduction of CSS linting) there wasn't any explicit need to scope things.

+1 on links to some issues so we can understand (a) the support burden we're causing and (b) the types of issues people are reporting. We wouldn't want to hastily change the docs without understanding what problems users are facing.

This is the most recent one: eslint/css#117 (comment)

Keep in mind that ESLint is now a multi-language linter, so the percentage of users who are using ESLint to lint more than just JavaScript/TypeScript is only going to grow from here. Being able to move from the core ESLint docs to the typescript-eslint docs and see similar examples will go a long way towards helping people figure out how to update their config files on their own, saving us all time.