-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(eslint-plugin): [ban-types] handle empty type literal {} #1348
feat(eslint-plugin): [ban-types] handle empty type literal {} #1348
Conversation
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 Report
@@ 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
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - thanks for this!
Fixes #1185