Brad Zacher

I think the eslint team generally avoided doing this because it means you need to create policies around what constitutes a tool that should or shouldn't be on the list...

> As for the rule to accept an integration, it should be simple: the PR should show proof of correct integration with the project. In other words, the tool surfaces...

The issue with this is that it's quite difficult to check for a "function that handles all its errors". For the most part a human can verify that a function...

I think you've misunderstood the intent of the rule. When the rule says that the type constraint is redundant - it doesn't mean that your entire generic is redundant -...

Is this just an indexing thing with algolia? We are still on the old infra (https://github.com/typescript-eslint/typescript-eslint/issues/5008)

It seems like you just want [`strict-boolean-expressions`](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/strict-boolean-expressions.md) to also check JSX expressions as if they were logical conditions?

happy to accept PR for a new option, say `checkJsxLogicals` which applies the rule's logic to a JSX expression (if it is a logical expression).

Best option would be to play around in https://astexplorer.net/ to get a feel for the AST you're looking to target. From there you can craft an [ESLint selector](https://eslint.org/docs/developer-guide/selectors) as best...

that is true - it will "just work" with the right options. I wonder if this is just a documentation thing, then? We can add another section to the docs...

To be clear - if we want to make a small enhancement to `strict-boolean-expressions` to do an additional check for JSXExpressions - then that change lives here in this project....