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

Add func-style exception for single-expression arrow functions #1897

Closed
matthewwithanm opened this issue Feb 28, 2015 · 8 comments
Closed

Add func-style exception for single-expression arrow functions #1897

matthewwithanm opened this issue Feb 28, 2015 · 8 comments
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 enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules

Comments

@matthewwithanm
Copy link
Contributor

With the addition of arrow functions, I think it would be great to have an exception for the declaration func-style rule. Namely, you should be able to enforce declaration style for all functions other than single-expression (implicit return) arrow functions.

It would look something like this:

"func-style": [2, "declaration", {"allowSimpleArrowFunctionExpression": true}],

and would behave identically to the normal rule, but allow the following:

const isOdd = (n) => n % 2 == 1;

This is a purely stylistic option that I imagine would be used primarily for exempting map/filter/reduce predicates.

@nzakas nzakas added the triage An ESLint team member will look at this issue soon label Feb 28, 2015
@nzakas
Copy link
Member

nzakas commented Feb 28, 2015

At first glance, this seems like a far too specific exception that doesn't fit with the purpose of the rule. I could see an argument to exempt arrow functions from this rule and then create a new rule that has options for how you want to format it.

@matthewwithanm
Copy link
Contributor Author

Yeah, separate rules for arrow functions probably would be the smartest approach.

@nzakas
Copy link
Member

nzakas commented Mar 2, 2015

How would you envision such a rule working?

@matthewwithanm
Copy link
Contributor Author

Honestly, I think the exemption is the important part. That way you could prefer function declarations but carve out an exception for disposable, lightweight functions like those predicates.

@gyandeeps
Copy link
Member

did we land somewhere?

@nzakas
Copy link
Member

nzakas commented Jun 8, 2015

I think we can create an option allowArrowFunctions to exempt arrow functions from this check.

@nzakas nzakas added enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules accepted There is consensus among the team that this change meets the criteria for inclusion and removed triage An ESLint team member will look at this issue soon labels Jun 8, 2015
nzakas added a commit that referenced this issue Oct 7, 2015
Update: `allowArrowFunctions` option for `func-style` rule (fixes #1897)
@robcolburn
Copy link

Is there a release planned for this? master doc currently incorrect :(

@mathieumg
Copy link
Contributor

@robcolburn Seems released now in 1.7.

@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Feb 7, 2018
@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 Feb 7, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
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 enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules
Projects
None yet
Development

No branches or pull requests

5 participants