Could you provide any information? Why do you think this? What's the motivation?

The rule doesn't use type information at all so it doesn't seem to fit the bill.

This rule does not use type information and so doesn't need to be disabled. The point of this config is to disable those that need types, not those that can only be run in TypeScript files.

not those that can only be run in TypeScript files

This rule should also be fine to run in JS files cos you can't have an import that's only used as a type in a JS file.

You mean... "you can't have type assertions in JS" 😄

Weird as I was getting the error about needing a parserService and setting the project when that rule was enabled. If that's the case, it should be safe to close this as it is not doing that now.

We have others complaining too, including @JamesHenry and those under #6885. Since @JoshuaKGoldberg proved that it works in https://github.com/JoshuaKGoldberg/repros/tree/consistent-type-assertions-type-information, we will keep it closed until more information can be provided. @6XGate it may help if you can provide a minimal repro showing it not working.

Hi, I have reproduced this in my PR, adding v6 to Nx repo.

To reproduce:

• clone this PR feat(linter): update typescript-eslint to v6 nrwl/nx#19548
• install dependencies with pnpm i --frozen-lockfile
• run pnpm nx lint nx-dev --skip-nx-cache (this should result in the following error)
  
• go to node_modules/@nx/eslint-plugin/src/configs/react-typescript.js and comment out @typescript-eslint/consistent-type-assertions on line 22
• run again pnpm nx lint nx-dev --skip-nx-cache
• the run should now be successful

It's not a minimal repro, but I hope it's not a big hassle.

I landed on this issue making a library for building ESLint configs and I am not sure what combination of conditions I created to produce the issue. If it appears again, I'll try to unravel it.