Skip to content
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): add explicit-module-boundary-types rule #1020

Merged
merged 4 commits into from
Jan 15, 2020

Conversation

GuyPie
Copy link
Contributor

@GuyPie GuyPie commented Sep 29, 2019

Fixes #65

@typescript-eslint
Copy link
Contributor

Thanks for the PR, @GuyPie!

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.

@GuyPie GuyPie force-pushed the master branch 2 times, most recently from 6a0d3b6 to 304397c Compare September 29, 2019 19:22
@GuyPie GuyPie changed the title feat(eslint-plugin): [explicit-function-return-type] add ignoreUnexpr… feat(eslint-plugin): [explicit-function-return-type] add ignoreUnexpor… Sep 29, 2019
@bradzacher bradzacher changed the title feat(eslint-plugin): [explicit-function-return-type] add ignoreUnexpor… feat(eslint-plugin): [explicit-function-return-type] add ignoreUnexportedFunctions option Sep 30, 2019
@bradzacher bradzacher added the enhancement: plugin rule option New rule option for an existing eslint-plugin rule label Sep 30, 2019
@GuyPie GuyPie force-pushed the master branch 2 times, most recently from 36cf7b1 to 96a1ae1 Compare October 7, 2019 15:31
@phaux
Copy link
Contributor

phaux commented Nov 25, 2019

All the other options are allowSomething and only this one is ignoreSomething. Is there a difference? If not, I think it should be like all the others

@GuyPie
Copy link
Contributor Author

GuyPie commented Dec 1, 2019

@phaux makes sense, I renamed it.

@GuyPie GuyPie changed the title feat(eslint-plugin): [explicit-function-return-type] add ignoreUnexportedFunctions option feat(eslint-plugin): [explicit-function-return-type] add allowUnexportedFunctions option Dec 1, 2019
@bradzacher bradzacher closed this Dec 1, 2019
@bradzacher bradzacher reopened this Dec 1, 2019
@bradzacher
Copy link
Member

Hmm. I wonder if this is better suited being combined with no-untyped-public-signature as a standalone rule, as opposed to an option on this rule.

I feel like having a single rule that says "ensure the module boundary is explicitly typed" is probably better than a collection of rules with options.

@GuyPie
Copy link
Contributor Author

GuyPie commented Dec 3, 2019

I agree. How about replacing "no-untyped-public-signature" with a new "explicit-module-boundary-types" rule?

@bradzacher
Copy link
Member

bradzacher commented Dec 3, 2019

that sounds like a decent idea.
You can use the deprecated, and replacedBy meta props to point users at the new rule.

Then it's just a matter of copying the code across. We can delete the old rule in the next major.

You can probably make the return type checks a lot simpler as well. Right now explicit-function-return-type is pretty complex because it has a lot of "I'll ignore this case, as a human can probably infer the type here".

To start with, the rule can probably just care about these simple cases:

export [default] class Foo {
  method(arg) {} // error - need explicit argument type
                 // error - need explicit function return type

  fnMember1 = (arg) => {} // error - need explicit argument type
                          // error - need explicit function return type

  fnMember2 = function foo(arg) {} // error - need explicit argument type
                                   // error - need explicit function return type

  get getter() {} // error - need explicit function return type
  set setter(arg) {} // error - need explicit argument type
}

export default {
  // same as above, but an object
}
export const obj = {
  // ditto
}

export [default] function bar1(arg) {} // error - need explicit argument type
                                       // error - need explicit function return type
export const bar2 = function (arg) {} // error - need explicit argument type
                                      // error - need explicit function return type

export const baz = (arg) => {} // error - need explicit argument type
                               // error - need explicit function return type
export default (arg) => {} // error - need explicit argument type
                           // error - need explicit function return type

is there anything I missed there...?

@GuyPie GuyPie changed the title feat(eslint-plugin): [explicit-function-return-type] add allowUnexportedFunctions option feat(eslint-plugin): add explicit-module-boundary-types rule Dec 10, 2019
@GuyPie GuyPie force-pushed the master branch 3 times, most recently from 2b49f8f to e265779 Compare December 10, 2019 10:35
@GuyPie
Copy link
Contributor Author

GuyPie commented Dec 10, 2019

@bradzacher I added the new explicit-module-boundary-types rule, let me know what you think. In the end it's pretty much a direct copy of explicit-function-return-type, with a few changes -

  • It only checks exported functions and methods of exported classes.
  • I removed the allowExpressions option, since it's not applicable to module boundaries.
  • I added the allowedNames option, which is a string array of function/method names to skip the check for.

Copy link
Member

@bradzacher bradzacher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one thing that's missing is the argument handling from the no-untyped-public-signature rule.

Eg:

export default const (arg): void => {} // error - need explicit argument type

export function foo(arg): number { return 1; } // error - need explicit argument type

export class Foo {
  bar(arg): string { return '' } // error - need explicit argument type
}

could you please copy that over as well?

@bradzacher bradzacher added the awaiting response Issues waiting for a reply from the OP or another party label Dec 20, 2019
@GuyPie GuyPie force-pushed the master branch 2 times, most recently from 21a581a to f474d7e Compare December 22, 2019 17:43
@GuyPie
Copy link
Contributor Author

GuyPie commented Dec 22, 2019

one thing that's missing is the argument handling from the no-untyped-public-signature rule.

Eg:

export default const (arg): void => {} // error - need explicit argument type

export function foo(arg): number { return 1; } // error - need explicit argument type

export class Foo {
  bar(arg): string { return '' } // error - need explicit argument type
}

could you please copy that over as well?

👍 will do.

@GuyPie GuyPie force-pushed the master branch 2 times, most recently from 5360f67 to 52e4d25 Compare December 22, 2019 18:13
@bradzacher bradzacher removed the awaiting response Issues waiting for a reply from the OP or another party label Dec 23, 2019
@GuyPie GuyPie force-pushed the master branch 2 times, most recently from 5df0e66 to 6d3d34d Compare December 26, 2019 16:25
@GuyPie
Copy link
Contributor Author

GuyPie commented Dec 26, 2019

@bradzacher I added a 'missingArgType' check.

Guy Perkal added 3 commits January 14, 2020 16:43
…ipt-eslint#65)

This rule will deprecate no-untyped-public-signatures, as it covers the same functionality but checks exported functions in additio
n to class methods.
It is being superseded by explicit-module-boundary-types.
Add 'missingReturnType' check for arguments, add docs for 'allowDirectConstAssertionInArrowFunctions' option, fix readme rule name.
Copy link
Member

@bradzacher bradzacher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - thanks for doing this.

@codecov
Copy link

codecov bot commented Jan 15, 2020

Codecov Report

Merging #1020 into master will decrease coverage by <.01%.
The diff coverage is 90.9%.

@@            Coverage Diff             @@
##           master    #1020      +/-   ##
==========================================
- Coverage   95.56%   95.56%   -0.01%     
==========================================
  Files         144      144              
  Lines        6568     6567       -1     
  Branches     1877     1876       -1     
==========================================
- Hits         6277     6276       -1     
- Misses        109      111       +2     
+ Partials      182      180       -2
Impacted Files Coverage Δ
...kages/experimental-utils/src/eslint-utils/index.ts 100% <100%> (ø) ⬆️
...kages/eslint-plugin/src/rules/naming-convention.ts 88.45% <100%> (+0.56%) ⬆️
packages/eslint-plugin/src/util/index.ts 100% <100%> (ø) ⬆️
packages/eslint-plugin-tslint/src/rules/config.ts 100% <100%> (ø) ⬆️
...mental-utils/src/eslint-utils/getParserServices.ts 33.33% <50%> (ø)

@bradzacher bradzacher merged commit bb0a846 into typescript-eslint:master Jan 15, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement: plugin rule option New rule option for an existing eslint-plugin rule
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[explicit-function-return-type] only apply to exported functions
3 participants