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

Rule proposal: no-constructor-return #12481

Closed
Assignees
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion feature This change adds a new feature to ESLint rule Relates to ESLint's core rules

Comments

@golopot
Copy link
Contributor

golopot commented Oct 23, 2019

Please describe what the rule should do:

Forbid return statements in constructors.

What category of rule is this? (place an "X" next to just one item)

[x] Suggests an alternate way of doing something (suggestion)

Provide 2-3 code examples that this rule will warn about:

class Foo {
  constructor () {
    return Math;
  }
}

class Goo {
  constructor () {
    return this;
  }
}

Why should this rule be included in ESLint (instead of a plugin)?

In Javascript return value in constructor is allowed, and the return value is the evaluated value when the class is new-ed. A class created with pattern behaves very differently from a normal class in the OOP paradigm, for example, in that every new instance should be a separate object. There seemed to be no practical usage of this pattern. Forbidding this pattern prevents mistake resulting from unfamiliarity with the language or copy-paste error.

Are you willing to submit a pull request to implement this rule?

Possibly.

@golopot golopot added feature This change adds a new feature to ESLint rule Relates to ESLint's core rules triage An ESLint team member will look at this issue soon labels Oct 23, 2019
@kaicataldo kaicataldo added evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion and removed triage An ESLint team member will look at this issue soon labels Oct 24, 2019
@kaicataldo
Copy link
Member

I support this proposal.

@g-plane
Copy link
Member

g-plane commented Oct 25, 2019

@kaicataldo Will you champion this? If so, it'll be better that remove your 👍.

@platinumazure
Copy link
Member

I've added 👍 so any of us can champion and this is accepted.

@ljharb
Copy link
Sponsor Contributor

ljharb commented Oct 25, 2019

Would it be valuable to add an option, so that any named non-arrow non-generator non-async function also was warned by this rule? (it'd probably want to ignore any return new in that case)

@g-plane g-plane self-assigned this Nov 5, 2019
@g-plane g-plane added accepted There is consensus among the team that this change meets the criteria for inclusion and removed evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion labels Nov 5, 2019
@kaicataldo
Copy link
Member

@ljharb Seems like a good idea to also check non-class (is there a better term for that? Prototypal?) constructor functions, though I would advocate for adding that in later since we already have a PR.

@ljharb
Copy link
Sponsor Contributor

ljharb commented Nov 6, 2019

ah, didn't realize #12529 existed.

I'd call them legacy constructors.

@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label May 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.