feat(eslint-plugin): [ban-types] handle empty type literal {}

[a-tarasyuk]

Fixes #1185

[typescript-eslint]

Thanks for the PR, @a-tarasyuk!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

---

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day.

[codecov]

Codecov Report

Merging #1348 into master will increase coverage by 0.06%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1348      +/-   ##
==========================================
+ Coverage   93.94%   94.01%   +0.06%     
==========================================
  Files         131      132       +1     
  Lines        5865     5881      +16     
  Branches     1662     1664       +2     
==========================================
+ Hits         5510     5529      +19     
+ Misses        188      186       -2     
+ Partials      167      166       -1

Impacted Files	Coverage Δ
packages/eslint-plugin/src/rules/ban-types.ts	100% <100%> (ø)	⬆️
packages/eslint-plugin/src/rules/prefer-for-of.ts	87.32% <0%> (-1.25%)	⬇️
packages/eslint-plugin/src/rules/index.ts	100% <0%> (ø)	⬆️
...escript-estree/src/semantic-or-syntactic-errors.ts	87.5% <0%> (ø)	⬆️
...-plugin/src/rules/explicit-member-accessibility.ts	89.09% <0%> (ø)	⬆️
packages/eslint-plugin/src/rules/no-extra-semi.ts	100% <0%> (ø)
packages/typescript-estree/src/convert.ts	98.85% <0%> (ø)	⬆️
...es/eslint-plugin/src/rules/no-use-before-define.ts	98.57% <0%> (+3.04%)	⬆️
packages/eslint-plugin/src/util/misc.ts	92% <0%> (+5.79%)	⬆️

[bradzacher]

Mostly LGTM - thanks for doing this.

A few things:

Could you please document this in the readme?
Maybe just add a line to the options section that says something like "the banned type can either be a type name literal (Foo), a type name with generic parameter instantiations(s) (Foo<Bar>), or the empty object literal ({})"

Might be good to add a little bit of "sanitisation" to the input keys now - remove all spaces. That way we won't confuse users if they try and use "{ }", or things like "Foo<Bar, Baz>".

This doesn't currently perform any validation on the string, which means technically it opens up to people putting in things like {foo:string}.
It's probably not worthwhile, but it might be a good idea to validate the options? Up to you. I think the documentation change suggested above will probably suffice.

[bradzacher]

LGTM - thanks for this!