feat(eslint-plugin): add explicit-module-boundary-types rule

[GuyPie]

Fixes #65

[typescript-eslint]

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.

[phaux]

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]

@phaux makes sense, I renamed it.

[bradzacher]

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]

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

[bradzacher]

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]

@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.

[bradzacher]

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?

[GuyPie]

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]

@bradzacher I added a 'missingArgType' check.

[bradzacher]

LGTM - thanks for doing this.

[codecov]

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%> (ø)