-
-
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): allow explicit variable type with arrow functions #260
feat(eslint-plugin): allow explicit variable type with arrow functions #260
Conversation
Codecov Report
@@ Coverage Diff @@
## master #260 +/- ##
=========================================
+ Coverage 97.2% 97.2% +<.01%
=========================================
Files 68 68
Lines 2501 2505 +4
Branches 385 387 +2
=========================================
+ Hits 2431 2435 +4
Misses 44 44
Partials 26 26
|
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.
Please add an example to the rule's readme so people can see this functionality without looking at the tests.
@typescript-eslint/core-team do we want to put this behind a setting (default on) in case people don't want to "trust" type annotations?
I.e. might not trust them because the following case passes:
type X = Function;
const x: X = () => 1;
packages/eslint-plugin/src/rules/explicit-function-return-type.ts
Outdated
Show resolved
Hide resolved
3ec706f
to
a9df636
Compare
Thanks for the review @bradzacher .
Done.
I think you are right. I made this opt-in. |
871c9b1
to
d08e435
Compare
packages/eslint-plugin/docs/rules/explicit-function-return-type.md
Outdated
Show resolved
Hide resolved
d08e435
to
8a73cee
Compare
db9f929
to
17acfba
Compare
17acfba
to
072afa5
Compare
@bradzacher @j-f1 , is there still something preventing this PR from being merged? |
Please avoid the workflow of amend + force push. |
@bradzacher I didn't realize GitHub couldn't handle this properly. Also, I'm not very used to commitlint and was unsure what commit messages I should use for non-features commits. I'll do my best to avoid force-pushes in the future. All my apologies for the inconvenience and thanks for your time and review. |
packages/eslint-plugin/src/rules/explicit-function-return-type.ts
Outdated
Show resolved
Hide resolved
…lbsgilbs/typescript-eslint into explicit-variable-type-arrow-function
…ipt-eslint into explicit-variable-type-arrow-function
…ipt-eslint into explicit-variable-type-arrow-function
…ipt-eslint into explicit-variable-type-arrow-function
any updates on this ? |
Hi! Can we unblock this @bradzacher @JamesHenry? Are we waiting for something? Thanks! |
Thanks for the reviews and your time. |
Has this been released to NPM yet? If not, when could one expect it? |
I have been waiting for the release since the merge too! It hasn't been released yet from what I can see. |
Refs: typescript-eslint/typescript-eslint#260 ToDo: Enable when fix is available
…ypescript-eslint#260) Similar to what we've done with both indent, and camelcase. Rather than forcing users to configure both our rule and the base rule (which has been a source of confusion), this lets users just use our rule. ```diff { - "no-unused-vars": ["error", { config }], + "no-unused-vars": "off", - "typescript/no-unused-vars": "error", + "typescript/no-unused-vars": ["error", { config }], } ```
Fixes typescript-eslint#144 Requires ~~typescript-eslint#259~~, ~~typescript-eslint#260~~. - added a util to make it standardised and easier to add default config for a rule - configured recommended based on typescript-eslint#144 - purposely switched `recommended` prop to be `"error" | "warning" | false` - inside the eslint repo, it should be `true`. otherwise it's just a property that isn't used officially by eslint. It's truthy so `eslint-docs` still work. - changed recommended generator to accept `"error"`/`"warning"` for more configurability. - adjusted default config of certain rules that didn't match our recommendations.
Fixes #149
Not sure if this is really acceptable though. Please tell me if it has some edge cases I didn't see or if it's just too broad.