Skip to content

[explicit-module-boundary-types] considers "protected" members as public boundaries #2430

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

Closed
3 tasks done
bladeSk opened this issue Aug 27, 2020 · 3 comments
Closed
3 tasks done
Labels
package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin working as intended Issues that are closed as they are working as intended

Comments

@bladeSk
Copy link

bladeSk commented Aug 27, 2020

The rule considers protected class methods as public, which contradicts the description in the plugin's docs:

Require explicit return and argument types on exported functions' and classes' public class methods

It's probably a matter of debate whether protected functions should be considered "exported" and I think the best solution would be to have this configurable.

This rule is generally pretty annoying, as it requires putting : void next to methods that don't return anything, but that's perhaps for another issue.

  • I have tried restarting my IDE and the issue persists.
  • I have updated to the latest version of the packages.
  • I have read the FAQ and my problem is not listed.

Repro

{
  "rules": {
    "@typescript-eslint/explicit-module-boundary-types": ["error"]
  }
}
export default class Test {
  testMethod() { // this produces an error, as expected
  }

  protected testMethod2() { // this produces an error, **but it shouldn't**
  }

  private testMethod3() { // this does not produce an error, as expected
  }
}

Versions

package version
@typescript-eslint/eslint-plugin 3.9.1
@typescript-eslint/parser 3.9.1
TypeScript 3.9.7
ESLint 7.7.0
node v12.18.2
@bladeSk bladeSk added package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for team members to take a look labels Aug 27, 2020
@bradzacher bradzacher added awaiting response Issues waiting for a reply from the OP or another party and removed triage Waiting for team members to take a look labels Aug 27, 2020
@bradzacher
Copy link
Member

By definition - they are public.
They're not public in the sense that someone that constructs an instance can see them, but they're public in the sense that anyone that extends your class can see them.

If you are extending this class outside of this module, then they are classed as part of the public interface of the class.

I don't think allowing for configuration here is correct.

@tadhgmister
Copy link
Contributor

I agree that protected members should be explicit since they are visible outside the module (even if it's only inside subclasses) but I do see where the confusion comes from, maybe just an update to the docs to say "public and protected members"

@bradzacher
Copy link
Member

Happy to accept a PR to clarify that in the docs!
Closing this as we won't be changing the underlying rule implementation.

@bradzacher bradzacher added working as intended Issues that are closed as they are working as intended and removed awaiting response Issues waiting for a reply from the OP or another party labels Sep 4, 2020
tadhgmister pushed a commit to tadhgmister/typescript-eslint that referenced this issue Sep 21, 2020
tadhgmister pushed a commit to tadhgmister/typescript-eslint that referenced this issue Sep 21, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin working as intended Issues that are closed as they are working as intended
Projects
None yet
Development

No branches or pull requests

3 participants