Tslint: [Rule Suggestion] Add no-implicit-any as a linter rule

[fnune]

Rule Suggestion

Hello there, I've been trying to hack around with tslint to make a PR but before I invest any more time I'd like to contrast the idea with the repo maintainers.

Is your rule for a general problem or is it specific to your development style?

It tackles a general problem: in big codebases that have been moved from JavaScript to TypeScript, turning the noImplicitAny compiler flag on could mean a pretty big refactor, and most developers would be very happy to have a way to gradually adopt the compiler flag for new files, or in a way that doesn't break compilation.

What does your suggested rule do?

Activating this rule would make the linter behave exactly like the compiler when anything implicitly has an any type. Currently with the compiler, it looks like this:

The goal is to be able to check this with tslint and be able to set it as a warning.

An idea for an autofix possibility

I haven't thought of this too well, but a possible way to autofix these issues would be to _explicitly_ add the any type hint. Probably not the best idea.

List several examples where your rule could be used

Developers about in the internet have adopted two workarounds that I know of:

• Split their tsconfig.json using the extends field (docs here) so that their editors use a config with noImplicitAny activated but their build scripts use one without it.
• Add @ts-nocheck plus the error numbers that are caused by activating noImplicitAny as a compiler flag, and subsequently _not_ adding the magic comment on new files so the rule is checked for new development. This has risk of becoming a regression if any of the rules can also be triggered by a different compiler flag being activated, or by the default TS compiler.

In both of these cases developers would benefit from being able to activate no-implicit-any as a tslint rule in order to be able to adapt it gradually.

Additional context

Related discussions:
https://github.com/Microsoft/TypeScript/issues/18540
https://github.com/Microsoft/TypeScript/issues/8855
https://github.com/Microsoft/TypeScript/issues/11051

[JoshuaKGoldberg]

Similar to discussion in #4100: if this can be done well, great! _If._

[fnune]

What can I do about the Needs Proposal tag? Do you have any examples or guidelines?

[JoshuaKGoldberg]

@brainlessdeveloper great question, thanks for bringing that up!

Although this rule sounds good, it's not clear how it would be implemented from a technical perspective. As with #4100, we need a detailed technical proposal for how to show the TypeScript compiler diagnostics. If someone in either issue can display how to do that without the same downsides as no-unused-variable, that'd be fantastic.

[JoshuaKGoldberg]

Note: per #4534, this issue will be closed in less than a month if no PR is sent to add the rule. If you _really_ need the rule, custom rules are always an option and can be maintained outside this repo!

[JoshuaKGoldberg]

💀 _It's time!_ 💀

TSLint is being deprecated and no longer accepting pull requests for new rules. See #4534. 😱

If you'd like to see this rule implemented, you have two choices:

• Recommended: Use typescript-eslint to lint your TypeScript code with ESLint ✅
• Legacy: Write it as a custom TSLint rule 🤷‍♂️

👋 It was a pleasure open sourcing with you!

_If you believe this message was posted here in error, please comment so we can re-open the issue!_

[JoshuaKGoldberg]

🤖 Beep boop! 👉 TSLint is deprecated 👈 _(#4534)_ and you should switch to typescript-eslint! 🤖

🔒 This issue is being locked to prevent further unnecessary discussions. Thank you! 👋