Prettier: Space after function keyword in anonymous functions

[lydell]

NOTE: This issue is raised due to confusion in #1139.

This issue is _only_ about _anonymous_ functions:

const identity = function (value) {
  //                     ^ space here
  return value;
}

(Prettier currently does _not_ put a space there.)

🗒 NOTE: This issue is _not_ about having a space after the function name:

function identity (value) {
  //             ^ space here: SEE #3845!
  return value;
}

Space after function name is tracked in #3845!

The key argument is:
Consistency: This means that there's _always_ a space after the function keyword.

[allex]

why not provide a --space-before-function-paren option

[azz]

@allex please read https://prettier.io/docs/en/option-philosophy.html

[alexburner]

+1 for space after function keyword. Crockford supports this:

If a function literal is anonymous, there should be one space between the word function and the ( left parenthesis. If the space is omitted, then it can appear that the function's name is function, which is an incorrect reading.

[allex]

y, For a generic tools, we need keep simple options as possible. but lots of project lint with standard with the space-before-fuction-paren enabled by the default.

[k15a]

@allex Don't lint stylistic issues when you use Prettier and all the problems are gone.

If you say that generic tools should provide simple options why is standard not providing an option to turn stylistic linting off?

[j-f1]

How should a generator function be formatted?

const identity = function *(value) {
  //                     ^ space here
  return value;
}

// or:
const identity = function* (value) {
  //                      ^ space here
  return value;
}

// or:
const identity = function * (value) {
  //                     ^ ^ spaces here
  return value;
}

[lydell]

Since this is all about consistency with named functions, the spaces should be exactly like for a named generator function. function* gen() {} and function* () {}

[josephfrazier]

I agree with @lydell. In this case, I'd consider the keyword to be function*, not function.

[coolemur]

Just something to mention:

Yes, you can turn off your linters and use whatever predefined style "Prettier" offers.

But when you consider a project template that comes with default linter rules on and you have N projects to create (and by N I mean "many"), it is not efficient to turn linters in every project. It would be more efficient to adapt prettier options.

I am never a fan of forced rules. Let it be a default (recommended) set of rules and let us tweak them so they would be flexible enough to work with projects which have their own code styles.

That would be fair enough.

[j-f1]

Let it be a default (recommended) set of rules and let us tweak them so they would be flexible enough to work with projects which have their own code styles.

https://prettier.io/docs/en/option-philosophy.html

[coolemur]

@j-f1 Yes, I do know this link. But still it doesn’t help to make developers of custom projects use “prettier” efficiently. If only “prettier” developers try to read what their tool users are saying.

Philosophy can have its flaws. Hitler had his philosophy too. That didn’t go well... And this philosophy of creating rock solid code standard without any flexibility in options is so wrong.

This is just an opinion. Don’t mind my efficient and flexible ideas. Do not reply trying to convince me, because any reply won’t fix this issue. Not for me. While creating many projects turning off linters for every project is just one more step that this tool is creating. This forces me not to use prettier in those projects. :(

I bet there are many users who see same problem here. But they just chose to deal with it by either unefficiently tweaking linters or just stop using “prettier”.

[j-f1]

Prettier’s goal is not to be flexible. As the page I linked above says:

By far the biggest reason for adopting Prettier is to stop all the on-going debates over styles.
The more options Prettier has, the further from the above goal it gets. The debates over styles just turn into debates over which Prettier options to use.

As you said above:

But when you consider a project template that comes with default linter rules on and you have N projects to create (and by N I mean "many"), it is not efficient to turn linters in every project. It would be more efficient to adapt prettier options.

If we added a whole bunch of options, you would have to configure them all each time you created a new project.

While creating many projects turning off linters for every project is just one more step that this tool is creating.

You have to enable Prettier for each project, too. Prettier makes this step pretty easy:

$ npm i -D eslint-{config,plugin}-prettier
$ npm i -D --save-exact prettier

then, in your .eslintrc.yml:

extends:
  - plugin:prettier/recommended

That will disable all rules that conflict with Prettier’s styles, while enabling a rule that gives you a description of what needs to be changed to follow Prettier’s styles.

[coolemur]

@j-f1

You have to enable Prettier for each project, too.

Even if I use prettier plugin?

If we added a whole bunch of options, you would have to configure them all each time you created a new project.

Why would I need to configure all of them? If I could configure only the ones i need to ?

[jameshhood]

I came here looking to figure out if there was a solution for this but only found a bunch of arguing. Its sad when lint has a flexible standard and a formatter tool cant be just as flexible and down right rude about it. When it boils down to it, every developer should be able to configure their project how ever they like. lint has the developers in mind for this and it seems prettier does not. Thanks but no thanks. I will find another tool backed by developers that care about other developers.

[coolemur]

@jameshhood EXACTLY !

[duailibe]

@jameshhood

Its sad when lint has a flexible standard and a formatter tool cant be just as flexible and down right rude about it

Yes, that's pretty much why we oppose adding options for everything. A lint can be as flexible as you want (it can even let you add your own rules, for that matter) because it will just complain if it finds something that doesn't "comply" with the rules. A formatter though has to format every single piece of code consistently and correctly, and adding options means adding overhead to maintainers: more code, a bigger surface for bugs, tests increase exponentially to check different combination of options, etc.

I don't understand your claim that we don't care about other developers, if that was the case we wouldn't bother doing unpaid work to maintain this tool. And I also didn't find anything rude in this thread, other than your comment.

every developer should be able to configure their project how ever they like

I completely agree with this. Developers have the option of using Prettier or not, and configuring the options Prettier has. That doesn't mean we have the obligation to support every JavaScript style out there. Also, the fact this issue was opened by one of the maintainers (and wasn't yet close) mean we're open for discussion and might be willing to support an option if there's significant demand for it (as we have done in the past).

You are also free to use whatever tools available to have a better developer experience, it's great that we have so many quality tools available, for free! We believe Prettier does a great job in that, and if you disagree, we're always open to talk and maybe meet halfway.

[jameshhood]

I understand the dilemma yall would have from an internal design and scope perspective but I think this is what many people are running into with this situation. People are wanting more customization because they like your tool and a lot of people promote it. However, the whole purpose of a lint is to standardize your code to a best practice for your project not the other way around. I personally write a bunch of vue apps so I like to use the eslint standard for vue so it basically does an automated peer review. I dont really expect a formatter to 'hold me to a standard' especially since it doesnt throw errors because something isnt syntactically correct. Best practices and javascript changes on a daily basis, so it would be nice is Prettier was as configurable so the community could share configs and be able to make it as customizable as tools like eslint. I like Prettier, it just cant do what I want it to do so I was left using the built in VS Code formatter. Maybe one day it will :)

[coolemur]

and might be willing to support an option if there's significant demand for it

You have demand for it.
You even have a case to reproduce a problem (vue initial project with lint ruleset which comes out of the box).

I don't think there is a point for you to try to convince people that we can use your defined and forced rules. Because if they won't fit developers needs - they just won't use your tool. Common sense.

Have a nice day. Bye.

[j-f1]

@jameshhood

it doesnt throw errors because something isnt syntactically correct.

I’m pretty sure it does:

Prettier 1.10.2
Playground link

Input:

a b c

Output:

SyntaxError: Unexpected token, expected ";" (1:3)
> 1 | a b c
    |   ^

@CodinCat

Because if they won't fit developers needs - they just won't use your tool.

That’s OK. The same point applies to Standard or AirBnB or any other style guide — you don’t have to use it, and we’re fine with <100% adoption.

If this really affects you, I said in my PR for this:

If you want to test this out on your codebase, you can run:

$ yarn add --dev j-f1/prettier#space-after-function

[covertbert]

It's a shame that you guys don't want to add a fairly simple configurable setting like this. I appreciate that you guys have quite a strong opinion on what Prettier enforces and that's fair enough as it's your baby after all, but there are those of us who have no choice but to use JS Standard and you're essentially saying that we can't use your plugin.

I get that it's a free plugin and I get that you have no obligation. It's just a shame is all, especially given that JS standard is the No.2 most commonly use JS style guide.

I hope you guys will reconsider as, after all, you could add this option and then just forget about the small part of your soul that you've sold and we can all move on with our lives.

[lydell]

Shame on us!

[covertbert]

I think you may have misinterpreted what I meant by "shame" but I won't get caught up in language semantics with you.

A collaborator mentioned earlier in the thread that, if there was enough demand, our request may be considered. I intended my comment as merely a polite voicing of my support for the proposal; pointing out why I believe it's worthwhile for you guys to tackle the issue while acknowledging that you're under no obligation to adhere to the request.

I wasn't trying to be a dick and I apologise if it came across that way.

[alexander-akait]

@covertbert all good, just say you opinion with facts/example usages/problematic/etc. and add vote. We already add this to 2 version. And seems it will be in 2 version looking at the number :+1:

[covertbert]

Awesome, cheers mate and that's fair enough I could have approached it differently

[noproblama]

Sad story, but well, you can add "eslint.autoFixOnSave": true rule to Settings of your IDE, so it will be auto fixed accordingly to eslint requirements on save. At list, it works for space before function parenthesis.

(It works for VSCODE! not sure about other editors).

[j-f1]

@WhoseSomebody You can also use prettier-eslint.

[coolemur]

@j-f1 Use another dependency that developers wont support in an emergency situations? Thank you, but no, thank you. :)

[duailibe]

@coolemur Please be respectful. That attitude won't help at all with getting this feature implemented.

[coolemur]

@duailibe
Sorry if you misunderstood what I was trying to say.
Customers/clients/users won't choose badly supported tools/products. This is obvious I think...
I have no disrespect at all.

[coolemur]

covertbert:
Re: [prettier/prettier] Space after function keyword in anonymous functions (#3847)
@coolemur I think you're in danger of being misunderstood again with what you're saying as, at a glance, it looks like you're saying that prettier is "badly supported" but I think you're referring to prettier-eslint?

@covertbert I am referring to both tools. But I am aware that in next version MAYBE this issue will be fixed. :) So this is a good thing for now. But if prettier devs don't fix their issues and then tells users to use their prettier-eslint.... Common... use your common sense.... Maybe prettier-eslint will also have some issues which they will refuse to fix.

No disrespect, but it sounds strange for me that people say "forced options" are ok. Everyone have a right not to use such tools then... that's it...

Every time I code vue projects I turn prettier off. :) I bet I am not the only one. I will mute this thread for now, I don't see a point to help or give test cases/response to people who just don't care.

[j-f1]

@coolemur We’re willing to fix bugs in Prettier (I’m sure the prettier-eslint folks are too), it’s just that formatting changes take a lot of discussion to ensure that we make the best decision. Right now it looks like we’ll be changing this behavior or adding an option, but I can’t say for sure. prettier-eslint will allow you to run whatever ESLint rules you’d like over your code after Prettier runs, and ESLint is actively maintained so you shouldn’t have issues there.

[pakastin]

Yes please, this is a deal breaker for me!

[dustturtle]

@WhoseSomebody this do not work for me . I don't know why

[noproblama]

@dustturtle I just had it here...
Are you using VSCode, too?

I have no ideas, why, too :)

[dustturtle]

YES, VSCODE, set like yours. @WhoseSomebody

[dustturtle]

Any updates?

[brocoli]

Please notice that this reduces consistency in at least one way:

Before this, argument lists were always either touching a word-token on their left side, or were followed by an arrow =>, while parenthesis used for grouping were always detached from word-tokens.

see:

• named function def: function myFunction(args) {}
• anonymous function def: function(args, of, anonymous) {}
• functionCall: myFunction(all, the, args);

In javascript breaking this consistency is not that bad because javascript does not have tuples and tuple primitives, only arrays, but the fact that we have two mutually exclusive consistency rules may point to this being the use-case for an option setting.

As for my personal feelings on this, seeing a function definition like this

function (value) {
  return value;
}

feels as uncanny to me as when people write function calls with the arguments separated from the function, i.e. myFunction (all, the, args) + something (other, entirely);, because of the extra space before the arguments list.

[redler]

@brocoli, Putting aside aesthetics arguments, for me the usefulness of the space-before-paren on function definitions/declarations is that it makes it easier to search for invocations of a function, as distinct from its definition/declaration. I realize IDEs take care of much of this, but old habits die hard, and those old habits leave me feeling that a search for myFunc( is materially different from a search for myFunc (.

I like Prettier, and I'd get used to spaceless parens. But since the space-before-paren decision is arbitrary, the change to one's habits if you're used to "the other way" likewise feels unnecessary.

[j-f1]

@redler Discussion for that is happening in #3845.

[joshburgess]

Honestly, I wish spaces were the standard for all functions. Anonymous or not. (This is how things are in StandardJS).

It feels like the non-spaced convention is just some old carry-over from C that people still use today in JS out of habit, despite it not really having any real reason to not be spaced.

[joshburgess]

@brocoli I understand your point about consistency, but I don't think you should compare function calls and function definitions there, as they're doing different things. If anything, having definitions spaced and calls not spaced is a nice convention that helps readability. At a very quick glance you know exactly what you're looking at.

[j-f1]

If anything, having definitions spaced and calls not spaced is a nice convention that helps readability. At a very quick glance you know exactly what you're looking at.

There’s another way to figure that out quickly — the function keyword just before the name.

[albanx]

Since this is an open source project, what does it stop people of making and merging a PR (like this https://github.com/arijs/prettier-miscellaneous/pull/22) into prettier?

Or that is opinionated only to a few bunch of admins?

[duailibe]

@albanx The fact this is Open Source doesn't mean we have to accept every PR made. The PRs are merged at the discretion of the maintainers, which it's not related to our personal preferences; but the project's present and future vision, impact on current users, cost of maintenance and other reasons.

It does mean you are free to modify this tool (and distribute) as you wish.

[albanx]

@duailibe
You're a bit contradictory, seems that the impact on the users doesn't really affect the project present and future vision.
A lot of users wants this feature, and instead of sticking to a single tool for a single purpose, we have to install additional packages and run more 3 commands to have the desirable effect.

So if it is true that it is not related to the maintainers personal preferences, then make the life easier for developers, add this option like the other options you have already added.

[j-f1]

@albanx Please read our option philosophy if you haven’t yet.

[lydell]

A lot of users wants this feature, and instead of sticking to a single tool for a single purpose, we have to install additional packages and run more 3 commands to have the desirable effect.

You don’t _have_ to install additional packages. You can also accept that things are the way they are. After all, it’s just a space.

So if it is true that it is not related to the maintainers personal preferences, then make the life easier for developers, add this option like the other options you have already added.

The idea here is that adding options makes the life for developers _harder,_ because now you have one more thing to disagree about in your team.

[albanx]

@lydell When I will go in north korea to work I will accept things they are, so as far as I can think in freedom I will do so :) .
The base idea is wrong, we agree on team base what option to use, and not on third party opinion. In practice in our teams this is making developer's life harder, we have prettier for code formatting, with eslint and airbnb integration.
Prettier dictatorship (fixed) rules conflicts with airbnb one's, both them have things in common and not in common which we want. In the concrete case the space is conflicting.

[suchipi]

I for one welcome our new prettier overlords

[Diokuz]

LOL ) Such a small thing, and I have to search for other tools.

[ztolley]

I agree with the philosophy published, but:

Whats wrong with the linter being responsible for the enforcement of styles and the formatter responsible for formatting the code automatically to the chosen style standard, be it standard js, airbnb or XO ?

[j-f1]

@ztolley It’s very difficult to make a formatter conform to every possible style that someone could possibly want (that’s the trap ESLint fell into), so we instead decided to be opinionated and only allow a few different styles to make development easier.

If, however, you want to create a pluggable, configurable formatter that allows people to pick any style they like, I encourage you to do so! It seems that many people would appreciate such a tool and a little competition is always healthy 😀

[atomiks]

So after 5 months and 90%+ agreement, will this be changed?

[coolemur]

@atomiks 5 months is enough to learn write a clean code without formatter.

[bovas85]

Any luck on this to be approved/ reviewed?

[j-f1]

Can someone tweet this from @PrettierCode to get more 👀 before we make a decision?

[albanx]

I think this is not agains the prettier philosophy, which I like and agree with it. We do not need a custom setting for this, we want just consistency. This can be as a definitive change.

[rattrayalex]

@j-f1 can you DM someone with that power if you feel strongly? Frankly, though, the 👍 / 👎 numbers here are pretty large and seem sufficiently compelling to me (it's pretty rare for an upvote counter to top 200 IIRC).

Otherwise, this feels like a strong candidate for prettier 2.0 and we might as well opt to mark this as "accepting pull requests".

[g-plane]

There are 200 upvotes now. Will this feature be implemented?

[Th3S4mur41]

Would be great to have this one changed or at least added as an option.
While I like the fact that prettier is opiniated and doesn't have hundreds of options, when a single rule is subject to this much controversy, chances are high that either the tool has this one wrong or should at least consider provide an option for it.
As mentioned above, 200 upvotes does not happen often and should be an indicator that a change is necessary

[j-f1]

Given the upvote-downvote ratio, I’m wondering if we should add an option or just change the behavior in 2.0.

[alexander-akait]

I think better change the behavior.

[lipis]

just change the behavior

[o8e]

Scrolling slowly through 9 months of comments advocating this change. Yet here I am at the bottom, disappointed.

Is this not a no brainer? Prettier is autofixing me and ESLint is telling me it's then wrong. I'm stuck.

[alexander-akait]

@o8e disable rule in eslint?

[DotCoyote]

I simply set https://eslint.org/docs/rules/space-before-function-paren to 0, since there is no better workaround

[covertbert]

@o8e disable rule in eslint?

Not really a great suggestion when a lot of the time you can't just change linting rules that affect everyone else on your team

[lydell]

@covertbert We recommend turning off all rules that conflict with Prettier: https://prettier.io/docs/en/eslint.html. If you can't do that, use prettier-eslint or don't use Prettier at all. Trying to adjust Prettier to follow other tools' rules is a constant uphill battle that Prettier isn't going to do.

@o8e No decision in Prettier is a no brainer.

Now, let's keep the issue on topic again.

[j-f1]

FYI: there’s a PR ready to go at https://github.com/prettier/prettier/pull/3903.

[hawkrives]

@j-f1 Just remember that the people who are happy with the current implementation probably won't downvote this issue, because they'll never see it.

[lipis]

and I guess half of these people don't care about this option either way.. there are some good arguments for the space.. let's just add it :) we can also tweet something to see some reactions..

[kirillgroshkov]

Please ❤

[JamiesonRoberts]

I know there has been lots of conversation around this one, and I know the philosophy is to not add functionality warrentlessly (IE once its added its hard to take it away). But I think for the sake of keeping the opinionated side of things it should be an option. That way people who don't care about setting it otherwise can keep the default opinion, and those that have been asking for a long time for some flexibility on this one can modify.

[Makoehle]

A quick workaround with VS CODE is to activate standard.autoFixOnSave. Then you hit the save button twice.

[leizhao4]

+1 for always having a space after the function keyword, but NOT after function names.

Crockford:

If a function literal is anonymous, there should be one space between the word function and the ( left parenthesis. If the space is omitted, then it can appear that the function's name is function, which is an incorrect reading.

Airbnb:

7.11 Spacing in a function signature. eslint: space-before-function-paren space-before-blocks

This is common/standard enough to at least deserve an option. In my opinion it should be the default.

[Jessidhia]

If that gets added it would be a separate option anyway.

[kirillgroshkov]

Pretty please ❤

[rattrayalex]

This has been implemented in https://github.com/prettier/prettier/pull/3903 . That PR is _temporarily_ closed as we wait for work on Prettier 2.0.

I'm very excited for this, and I hope others are too. I also hope we can be patient 🙂

[j-f1]

I’m wondering if we should start a new branch so we can do beta releases of breaking changes while still iterating on features.

[j-f1]

https://github.com/prettier/prettier/tree/next

[rtymchyk]

@j-f1 Are we planning to merge it into next or am I misunderstanding?

[duailibe]

@rattrayalex That PR is not waiting for Prettier 2.0 as:

• it doesn't need to wait for 2.0
• it might not get merged even in 2.0

There's a misconception that we need to wait for a major release to introduce stylistic changes, even though we've never waited before. Stylistic changes can and will be introduced in any release (usually in minor).

That PR is closed because @j-f1 wanted to, it could might as well be open, but not merged until the maintainers decide to merge it.

@j-f1 I don't want to create expectations for Prettier 2.0 because we don't know if we'll ever come to it and we don't know what we'll release in it.

[kirillgroshkov]

Exactly. If it's an option - the change is non-breaking, hence minor release.

Prettier 2.0 _can_ make breaking change by changing the default behaviour. But that's separate discussion.

[zomp]

@duailibe So would it be possible to add it as a user-defined option to the next (minor) release please?

[j-f1]

@j-f1 I don't want to create expectations for Prettier 2.0 because we don't know if we'll ever come to it and we don't know what we'll release in it.

Should I delete the branch then?

[atomiks]

How is this is more of a breaking change than other previous minor stylistic changes? I've updated Prettier minor versions and running the formatter changed my code and had to be recommitted, so how was that not a "breaking change" too? Shouldn't this just be included in the next minor (no option needed) considering it's already had a PR for over a year?

[mkay581]

I've updated Prettier minor versions and running the formatter changed my code and had to be recommitted, so how was that not a "breaking change" too?

wait what? 😆 That should never happen in a minor update. Especially since my team is using Prettier as a pre-commit git hook. Prettier is also verified on all files during PRs. So a change like that would essentially fail and break PR builds. 😬

[DotCoyote]

Happend to me with the html-support in vue files as well... wasn't able to update prettier in my project anymore because the prettier ruleset collided with the vue:recommended rules for html-markup. So nothing unusual...

[mkay581]

In the spirit of staying on topic and not introducing unrelated noise in this thread, it may be better to start a new issue on what classifies as a minor vs major change. There seems to be some misunderstandings there but is a separate issue unrelated to this thread. I personally would like to know whether minor upgrades will cause issues with my team's workflow I mentioned previously.

[atomiks]

Just a recent example: 1.16.0 reformatted React Hooks. That's not a breaking change?

https://prettier.io/blog/2019/01/20/1.16.0.html#improve-the-pattern-used-by-react-hooks-5608-by-j-f1

Edit: yes I agree a separate thread explaining what constitutes breaking would be helpful. I'm not really sure at the moment

[lydell]

Yes, “breaking changes” has nothing to do with this issue. Prettier introduces formatting changes in every minor release. Strictly speaking, even in patch releases. The contract is that Prettier takes a string as input and returns _a_ string as output, but doesn’t say anything about what that string looks like. We only bump the major version when we’ve changed other things than the formatting output in breaking (API, CLI, option defaults, Node.js compatibility, etc) ways. Otherwise basically _every_ release would be a major version bump.

The best way to use Prettier is to lock down the version exactly so that everyone in the same team uses the exact same version.

Feel free to open a new issue if you have more questions about breaking changes – that shouldn’t affect any decisions taken in this issue.

[atomiks]

Okay, so if this can be introduced in a minor release, why hasn't it yet? I don't understand..

[lydell]

Because we haven’t decided what to do yet.

[atomiks]

The community decided ages ago with the reactions though, what's the hold up? Not to mention the styling change itself is so minor it might be imperceptible to most people, except for the people who are frequenting this thread :-)

I just don't see any reason for the indecision on this.

[rattrayalex]

Coordinating a group of volunteer collaborators can take time – these are trickier decisions than they seem*. Please be patient 🙂

* For example, this most minor of changes would likely force many users to update a large percentage of their JS files (potentially hundreds of thousands) in git; even people who don't mind the stylistic change may have a problem with the disruption. Personally, I think that tradeoff is worthwhile, but reasonable people may disagree on this.

[atomiks]

Okay, that's a fair point. I'm just wondering how this decision is going to be made in the end. In August, you guys were going to tweet it out to ask for further opinions. It's now 6 months later, just seems to be taking longer than it should. Is there something we can do to help finalize the process?

It's kind of funny though - I don't actually care about this issue as much as I did early last year. Getting notifications on this thread is the only thing that makes me think about it again 😅 When Prettier formats on save, you learn to accept the styling it gives you. e.g. when a codebase has a .prettierrc that is different to my preferred one, when formatting on save, the change in style doesn't bother me much. I love how Prettier has fixed this mentality over stylistic choices.

[zomp]

Our team has not started to use Prettier in a broader scale because of this single issue. The missing space leads to misreads of the code. We have our code formatted differently and we do not mind to reformat it, but we mind bugs and misunderstandings caused by the misreads.

Personally I do not mind waiting for a near future breaking version or to use an option, but if it appears nothing like that is implemented, we will use a fork, use a different tool or do without a code formatter.

[ColCh]

Personally, I think that it's not blocker anyway to use prettier :) Hey @zomp it's possible to use prettier with eslint and this rule space-after-function-name to achieve that. How to use eslint with prettier? There is prettier-eslint package ready to use.

For example, we are using Prettier + TypeScript + tslint and we have much faster code reviews now. Prettier ❤️

[leizhao4]

I'm on the same boat with @zomp. Would love to know if our team should wait for Prettier to fix it, or just switch to a different tool. It _is_ a deal breaker for us.

[lydell]

@zomp and @leizhao4 can you provide some real-world piece of code where the missing space caused confusion for you, and say what the confusion was?

[g-plane]

@lydell That is just a popular code style, and it may not be a confusion.

[leizhao4]

@lydell Personally it's more about inconsistency than confusion.

If you have

if (...) { ... }
for (...) { ... }
while (...) { ... }

then it would make no sense to not have

function (...) { ... }

These are all _keywords_, and there is always a space between the keyword and the left parenthesis.

Not having the space is basically having it confused with the function invocation syntax, and treating function as a name rather than a keyword. This is inconsistent, and it's academically a (common) mistake, rather than just a style.

[lydell]

Thanks! @zomp Since you specifically mentioned confusion, I’d still be interested to hear from you!

[kirillgroshkov]

It _is_ a deal-breaker for us as well. We _do_ use TSLint after to fix it, but it's so annoying. Because tslint --fix may change some other things too (e.g it removes "unused imports"), after that we need to do another round of "prettier + tslint", cause prettier will reformat it again (because e.g line became shorter after tslint removed it)... So, it's non-deterministic how many such rounds of "prettier+tslint" we need to "stabilize" our formatting... Very annoying.

And this specific stylistic things is important cause we came from StandardJS format and that's the only thing that conflicts with it and has no option to comply.

[zomp]

I misread it usually during committing or reviewing something via git. I use the standard git command line tool, there is no highlighting (the function keyword is not in bold), so I read it as a common function invocation.* This also happens to me when I edit something remotely via simple console tools or reading some code in the browser (in FF there is no JS highlighting on Ctrl+U).

* To identify the building blocks (function expressions) is IMO more important than their later usage (buggy function used on ten places causes ten issues vs. one issue cause by one buggy usage).

[lydell]

@zomp Can you provide some example code?

[zomp]

E.g. something as simple as

let test = function(phrase) {
  ...

can be misread as

let test = function(phrase);
...

(Especially if there are other invocations around or if the indentation around is changing a lot or if the variable is named in a way it could represent an action (verb _test_) or a property (noun _test_).)

[rattrayalex]

Unfortunately, it has been decided that this will not merge due to concerns that the diff churn would be too high.

💔

We're aware that this is a very popular request, and I'm sure many people will be disappointed. Thanks for your patience and understanding 🙏

I'll be closing, but not locking this issue. You're welcome to discuss; please keep the conversation civil ♥️

[Jessidhia]

I don't understand why the issue itself is closed. The veto was against changing the default, not the presence of the option.

[rattrayalex]

Thanks, I should have explicitly mentioned that. I don't think there's any chance of an option getting accepted for this, since collaborator opposition was so strong, but I may be wrong.

[alexander-akait]

Keep open

[alexander-akait]

We can change default output for 2 version, not for 1 (it will be very painful for many projects)

[rattrayalex]

@evilebottnawi why keep this open? I don't want to prolong the suffering. If we're considering an option we should reach a decision promptly.

Edit - ah, sorry, just saw your second message. Can you lead an effort to reach a decision on that shortly?

[alexander-akait]

@rattrayalex

I don't want to prolong the suffering

Don't do it, it is just one space

If we're considering an option we should reach a decision promptly.
Can you lead an effort to reach a decision on that shortly?

No need rush, based on votes many people want have space, but as i said above it is painful for many projects and can't be solved very fast, we avoid new options, but maybe it is case when we need this again :disappointed: Anyway let's keep open issue, also i want to listen @vjeux

[atomiks]

I personally don't see the need for an option for something most people agree should have a space (since it's a keyword). It's not as controversial as the space after function name, which is a lot less common. I think it should be default in v2, but not worth changing in v1 due to the churn as listed earlier

[leizhao4]

I agree with @atomiks. Most people seem to either agree or don't care about adding the space. The only major obstacle is the churn. If this is the case, then making it the default behavior in 2.0 would make everybody happy.

(And, it would be really really _really_ awesome if we start publishing pre-release versions to NPM so people like myself can be unblocked.)

[bntzio]

I think ALL ESLint/TSLint rules should be highly compatible with Prettier.

[alexander-akait]

Just idea: we can create next branch and merge all PRs for 2.0 into this branch (also rebase this from master before each release), it is allow:

• Use developers (who can't wait) new formatting (like this)
• Allow testing/reporting next problems (on real projects)
• Some other cool stuff

[azz]

I'm 👎 on changing the behaviour (even in a major version) due to the unnecessary churn it will create.

[avrelaun]

We already had a lot of churn in precedent prettier version, eg. when html / vue files support was added. Not to say that it should be done again per se, but if the users wants it so badly it's the most popular issue and the :+1: count is 10x the :-1: count, it should be added.

Contrary to #3845 which should be an option since the prettier community is split.

[alexander-akait]

/cc @azz what is problem in changing behavior?

[albanx]

@avrelaun Then what are you waiting for? (https://github.com/arijs/prettier-miscellaneous to takeover?)

[albanx]

Again, this is only about consistency, prettier is not consistent in the space rule, nothing more, we do not need an options for this, eventually just change the default behavior. This seems to be a bug rather than a wanted feature.

[j-f1]

Just idea: we can create next branch and merge all PRs for 2.0 into this branch (also rebase this from master before each release), it is allow:

Already exists @evilebottnawi!

[aMarCruz]

For those interested in an alternative, I just published eslint-plugin-prettierx.

PrettierX is a good fork of Prettier and has options that make it quite compatible with StandardJS. The plugin offers a preset for it and is very configurable.

Right now I'm testing it with a medium sized project in TypeScript with the VS Code ESLint extension and with a git hook.

[SplicePHP]

Had the same issue. I just installed Prettier+ and it worked for me.

[loojacob]

'space-before-function-paren': [ 'error', { anonymous: 'never', named: 'never', asyncArrow: 'never' } ]

add the upper role to [.eslintrc.js -> rules], works for me.

[xnng]

@loojacob good idea, and i like this: { anonymous: 'ignore', named: 'ignore', asyncArrow: 'ignore' }

[Smithx10]

why... is this still not a thing?

[amritk]

@Smithx10 I don't think they will implement it, just use an eslint plugin

[friederbluemle]

It is perplexing how an obvious bug in Prettier

1. made some people start believing that this was intentional.
2. still - after years of discussion - remains open.

Why on earth would the function keyword be the only keyword not followed by a space character? 🤷‍♂️

[Smithx10]

@friederbluemle just add an option and call it a day ... isn't this the exact problem that prettier is supposed to solve? "Help people style javascript?"

[friederbluemle]

@Smithx10 - How do you add an option to make it work with ESLint and eslint-plugin-prettier without conflicts?

[Smithx10]

@friederbluemle Idk, idc .... I've stopped using prettier because of this :) Just piling on to how silly it is that this is still open and not added.

[lipis]

I'm down to have that as default without an option for Version 2.

[friederbluemle]

@lipis Yes, please!! 👍

[lydell]

@friederbluemle To answer your question about ESLint: We recommend turning off all ESLint rules that conflict with Prettier: https://prettier.io/docs/en/integrating-with-linters.html

[friederbluemle]

@lydell - Yes, I know that. But to my knowledge, it is currently not possible to have both consistent formatting (i.e. spaces after all keywords) and ESLint active (with eslint-plugin-prettier). Please correct me if I'm wrong.

[lydell]

@friederbluemle prettier-eslint

[sosukesuzuki]

I think we should reopen #3903 and merge to next branch

[friederbluemle]

@lydell - Thanks, I checked out prettier-eslint, and it looks promising, but unfortunately I still can't use both tools together. I feel like it _should_ work, however I discovered a bug in ESLint which makes this impossible: The keyword-spacing rule does not detect missing spaces after the function keyword. Because it remains undetected, of course ESLint also can't fix the space that gets removed by Prettier, even if ESLint runs _after_ Prettier. I opened an issue over here: https://github.com/eslint/eslint/issues/12523

[bzhang]

@lydell I've tried prettier-eslint a while ago. It worked okay in the "fix" mode, but not so much in the "check" mode. The fix mode worked because ESLint was able to revert the incorrect changes made by Prettier, but in the check mode, ESLint didn't stop Prettier from throwing a false error.

[lydell]

Removing the “help wanted” label, because we already have #3903. Code is the easy part here. This requires some core coordination to get done.

[brainkim]

See #7028 for a related discussion about generator stars. I think consideration of generator stars is the strongest argument for adding a space after the function keyword.

Also IMO having this done as an option is the worst of all possible choices.

[sosukesuzuki]

I modified the milestone to 2.0. if there is problems please let me know

[thorn0]

fixed by #3903