cc @bradzacher @JoshuaKGoldberg is this by chance an easy PR?

Yup, it is! Replace node.typeParameters with (node.typeArguments ?? node.typeParameters). That'll support both v5 and v6 of typescript-eslint.

i assume we can use || as well, since we don't have a build process here :-)

eye twitches

You may not be able to simply use || for this in case there are valid logic paths where typeParameters is falsy since then it would trigger the deprecation warning. There are some places (at least in propTypes.js) where there is logic for checking if typeParameters exists before using it so I assume this is the case.

I think doing this instead should work:

const typeArgs = 'typeArguments' in node ? node.typeArguments : node.typeParameters;

and then use typeArgs instead of node.typeParameters.

Though it seems like similar handling needs to be done for usage of node.parent.typeArguments and node.superTypeArguments in some places.

I was testing this a bit and was able to get rid of this deprecation warning by monkey patching this kind of changes in node_modules directly.
If I find some time I might contribute a PR that fixes this if you think this approach is ok.

A PR would be great.

monkey patching this kind of changes

I'm just a maintainer on typescript-eslint, not eslint-plugin-react, but: please don't monkey patch modules if it's not absolutely necessary. You never know when those patches break downstream tools or are themselves broken by package updates. Especially when there's a recommended workaround in the thread (#3602 (comment)). I can't guarantee that we won't frequently break the patch by refactors on our end.

@Haprog if the node.typeArguments || node.typeParameters switch is presenting issues, I'd love to see specifics. We can always update https://typescript-eslint.io/blog/announcing-typescript-eslint-v6 and/or the deprecation notice with tailored instructions.

Edit: what ljharb said 👇 😄

It’s fine to do such patching temporarily to test out a PR you want to make, to be clear, just don’t commit or deploy it or anything :-P

Yes, of course. What I meant with monkey patching in this case was that I was just locally modifying eslint-plugin-react package in my project's node_modules to see what it would take to fix the issue to verify the feasibility of the suggested fix before making a PR to eslint-plugin-react. So patching just for the sake of testing the idea. 🙂

Ah got it, sorry for jumping at you there! 😄

@JoshuaKGoldberg btw related to the instruction here https://typescript-eslint.io/linting/troubleshooting/#the-key-property-is-deprecated-on-type-nodes-use-key-instead-warnings

If you've using many ESLint plugins, have updated each to their latest version, and you're not sure which one this complaint is coming from, try disabling half of them at a time to narrow down which plugin it is.

This was not very helpful even though I was only using about 5 plugins since disabling a plugin you also need to remove or comment out the rules related to that plugin and also need to remove related "eslint-disable " comments in your code to be able to run without errors (otherwise you'll get errors about missing rule definitions).

I found a much easier way to figure out which plugin is causing issues is to run with Node's --trace-deprecation option. For example since I was seeing these deprecation warnings when running npm test I could instead run with

npx cross-env NODE_OPTIONS=--trace-deprecation npm test

to get better debugging output and see which plugin/file/line is causing the issues without disabling any plugins/rules.

This will give output like so:

(node:82846) DeprecationWarning: The 'typeParameters' property is deprecated on TSTypeReference nodes. Use 'typeArguments' instead. See https://typescript-eslint.io/linting/troubleshooting#the-key-property-is-deprecated-on-type-nodes-use-key-instead-warnings.
    at Object.defineProperty.get (/Users/<redacted>/node_modules/@typescript-eslint/typescript-estree/dist/convert.js:2477:29)
    at DeclarePropTypesForTSTypeAnnotation.searchDeclarationByName (/Users/<redacted>/node_modules/eslint-plugin-react/lib/util/propTypes.js:630:53)
    at DeclarePropTypesForTSTypeAnnotation.visitTSNode (/Users/<redacted>/node_modules/eslint-plugin-react/lib/util/propTypes.js:597:14)
    at Array.forEach (<anonymous>)
    at DeclarePropTypesForTSTypeAnnotation.convertIntersectionTypeToPropTypes (/Users/<redacted>/node_modules/eslint-plugin-react/lib/util/propTypes.js:723:20)
    at DeclarePropTypesForTSTypeAnnotation.visitTSNode (/Users/<redacted>/node_modules/eslint-plugin-react/lib/util/propTypes.js:606:14)
    at DeclarePropTypesForTSTypeAnnotation.visitTSNode (/Users/<redacted>/node_modules/eslint-plugin-react/lib/util/propTypes.js:595:14)
    at new DeclarePropTypesForTSTypeAnnotation (/Users/<redacted>/node_modules/eslint-plugin-react/lib/util/propTypes.js:583:12)
    at markPropTypesAsDeclared (/Users/<redacted>/node_modules/eslint-plugin-react/lib/util/propTypes.js:975:34)
    at markAnnotatedFunctionArgumentsAsDeclared (/Users/<redacted>/node_modules/eslint-plugin-react/lib/util/propTypes.js:1056:9)

Any updates on this?

nope, or they'd be posted on the issue.

Are maintainers open to PRs to fix it? I can make some time in the next week or so.

@benasher44 yes! altho #3629 already exists, so instead of a new PR, please comment on that PR with a link to a branch or commit, and I'll pull in your changes.