Rule proposal: @typescript-eslint/no-implicit-any (Warning alternative for tsconfig.json option causes error.)

[infacto]

I would prefer using @typescript-eslint/no-implicit-any instead of noImplicitAny of tsconfig.json. Because in ESLint I have the control to show this issue as warning. Setting noImplicitAny in tsconfig is always an error.

// Param "value" has implicit any type. Show warning. (Not error)
public myMethod(value): void {
  console.log(value);
}

[StephanBijzitter]

This would be amazing, it would make transitioning from noImplicitAny: false to true a lot easier!

[bradzacher]

We do not recommend turning off noImplicitAny - this compiler option forms the foundation of a safe codebase. Turning it off can allow any to leak into your codebase.

Additionally we intentionally do not duplicate checks made by the compiler.

For those reasons I am going to reject this proposal.

---

@StephanBijzitter You can use our typedef rule to help progressively onboard a codebase onto noImplicitAny.

Note that this lint rule is designed to be a temporary lint rule to help you onboard only, and should not be left turned on forever.

Additionally our suite of no-unsafe-* rules will use type information to help you progressively find and fix the anys in your codebase.

[infacto]

@bradzacher Generally I agree with you. But sometimes you play with code in live reload. And guys can disrupt the flow when testing some solutions or prototype something. Ich bin nicht gegen typen. I like the strict mode, etc. But in this case it's slightly another case.