Victorien Elvinger

I have no strong opinions about this. I am wondering: could we support both for transitional purpose?

I think that the main reason of the existence of this rule is to detect cases where `() => this` could be used instead of `function() { self }`. In...

In the example do you mean ``// do something with `self` ``?

In this case, the function should be replaced by an arrow lambda and `self` should be replaced by `this`. Thinking a bit more about this rule, this could be decomposed...

One issue I see is that a user could expect to apply the linter/checker only on staged parts of the changed files, leaving unchecked the unstaged parts.

Ideally, TSC should support `jsonc` extension. However, according to https://github.com/microsoft/TypeScript/issues/43121 this is not on their agenda. A possible workaround could be to use `tsconfig.jsonc` and a `tsconfig.json` without comments that...

@xunilrj I could add the following recommended rule from ESLint TypeScript that require type info: - [await-thenable](https://typescript-eslint.io/rules/await-thenable) - [no-floating-promises](https://typescript-eslint.io/rules/no-floating-promises) - [no-for-in-array](https://typescript-eslint.io/rules/no-for-in-array) - [no-misused-promises](https://typescript-eslint.io/rules/no-misused-promises) - [restrict-template-expressions](https://typescript-eslint.io/rules/restrict-template-expressions) (enabling `allowNumber`, `allowBoolean`, `allowNullish`) -...

Just for reference: the TS team is [discussing which semantic rule is worth the linting time](https://github.com/microsoft/TypeScript/issues/51809).

Thanks for your contribution :)

Static blocks are static, this should not change the behavior of the rule?