Prettier: Space after function name in declarations

[justrhysism]

NOTE: This issue is raised due to confusion in #1139.
NOTE: Feel free to use the 👍 and 👎 buttons to indicate your preferences, but please refrain from commenting unless you’ve read every comment and made sure yours says something that has _not_ been said before.

This issue is _only_ about outputting these spaces:

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

function identity <T>(value: T): T {
  //             ^ space here
  return value;
}

class A {
  method () {
    //  ^ space here
  }
}

const obj = {
  method () {
    //  ^ space here
  }
}

(Prettier currently does _not_ put spaces in those positions.)

🗒 NOTE: This issue is _not_ about anonymous functions:

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

Anonymous functions are tracked in #3847!

The key arguments is:
Searchability: You can find any function or method declaration my searching for e.g. method ( or identity <, or even just name[space] (mostly).

It also provides a clear and immediate difference between _declaration_ and _invocation_.

(There are many existing comments in favour of this style, notably: https://github.com/prettier/prettier/issues/1139#issuecomment-316096507 and the majority of the discussion from https://github.com/prettier/prettier/issues/1139#issuecomment-361515396 onwards.)

[brianjorden]

This is one of the reasons I've had to step away from adopting Prettier. I would be quite happy with just an optional flag. The original issue talked a lot about configuring and adding in eslint to re-process and alter the output of the code AFTER prettier has a go at it. My understanding from what I read is that was being suggested to "reduce configuration" that people generally needed to do and obviously it is just trading where configuration is being done.

Additionally, many people don't actually use ESLint, so the suggestion is to actually bolt on another entire tool to the build chain. That falls down further when talking about a combination of TypeScript + Vue + Vetur + Single File Components as right now I don't believe there is a working implementation to combine TSLint + Prettier + Vetur.

I currently maintain a fork of Prettier mainly for this reason, but it breaks constantly. An additional challenge comes in with Vetur not currently using the locally installed version of Prettier, but the Prettier VSCode extension doesn't run on .vue files. I've resorted to manually overwriting the installed version of prettier in three node_modules locations every time things get updated (local project, global, and vetur). Needless to say, it breaks a lot.

Many people/companies/projects can't simply change certain aspects of their code spec requirements on a whim. Prettier matches, or is close enough to the vast majority of rules we're using, and obviously the rules in some of the most popular sets of standards used with things like ESLint, except this ONE item. Most other variations can be dealt with through a prettier-ignore comment, but obviously this is extremely wide spread and a major point of contention.

I hope that all those involved will look at and consider the rather large number and volume of voices just asking to incorporate an opt-in ability to handle adding a simple space. The arguments of this being "bike shedding" feel a bit silly to me. The alternatives are to either disable rules within the most popular sets of linting rules OR add an entire extra set of tooling/parsing of every file.

[j-f1]

@brianjorden You might be interested in our hot-off-the-presses docs on why we don’t accept most option requests.

[brianjorden]

I get all of that, but on that same logic, why would the core and ONLY option of Prettier then violate the extremely popular much older linting/coding standards on this exact issue? I totally get doing things in a very opinionated way, but the standard and airbnb rules have been downloaded millions of times per month since long before Prettier existed. Honestly, I personally don't even like a lot of those "out of the box" rules. The oddity to me is that this is the ONE item that seems to violate the prior defacto-standard sets of rules that a lot of people have been using for a long time. I may be wrong in my overall understanding, but if the concept is to avoid the "holy wars" and "bike shedding" cliche concepts, why is this one rule different than some of the popular standards?

[lydell]

First off, please note that we're not stubbornly saying no to this. This issue is _open,_ and is now part of the process for adding options. That process isn't formally written down (like ESLint's) but it has kind of started to grow out of itself.

We're now waiting for that :+1: counter to increase. Give it some time.

The original issue talked a lot about configuring and adding in eslint to re-process and alter the output of the code AFTER prettier has a go at it. My understanding from what I read is that was being suggested to "reduce configuration" that people generally needed to do and obviously it is just trading where configuration is being done.

Additionally, many people don't actually use ESLint, so the suggestion is to actually bolt on another entire tool to the build chain.

The suggestion is generally to _let it go and just use Prettier._ But if you can't do that, there's always the option of using prettier-eslint. Or not using Prettier at all. Or wait, and see if people change their minds.

except this ONE item

Everyone says that in every issue :) "This is the ONLY thing preventing us from using Prettier." We'd have a lot of fix-somebody's-only-problem options at this point if that was a convincing argument :)

Many people/companies/projects can't simply change certain aspects of their code spec requirements on a whim.

This might be a silly, but this is how I imagine that scene playing out:

_employee:_ I've found a tool that could reduce the time we spend on formatting code and fixing lint issues. Can we give it a try?
_boss:_ Does it comply with our style guide?
_employee:_ Yes! Except one rule.
_boss:_ Sorry, our arbitrary choices are more important than the productivity of our employees.
_employee:_ Can we at least give it a try to evaluate it?
_boss:_ No! Those spaces are part of the company's core values.

I mean if Prettier complies with all of your style guide except _one_ item, isn't that a huge success? If you can't even change _one_ item of your style guide – that's even about just a single space – I'm not sure if you should use Prettier at all. Every new Prettier version runs the risk of inroducing some minor conflict with your style guide.

Honestly, I personally don't even like a lot of those "out of the box" rules. The oddity to me is that this is the ONE item that seems to violate the prior defacto-standard sets of rules that a lot of people have been using for a long time. ... why is this one rule different than some of the popular standards?

Because it's not that easy. In fact, I've very rarely worked on a code base that use the space-after-function-name rule. Hadn't even heard of it before I found standard. Remember, when James Long first implemented the core printing he had _a lot_ of decisions to make. Perhaps he hadn't worked on many code bases with space-after-function-name either and didn't think about it. Or he just needed to choose something to be able to move on, so Prettier could be released and not stuck in decision making forever. We try hard to choose non-controversial style decisions (for markdown we even used bigquery to gather stats), but we also have to consider the churn of making changes that affect all existing Prettier users. So sometimes we're stuck with decisions made in the past, and it takes time to find the best way forward. So this is _not_ about the Prettier authors trying to impose _their_ style preferences to the world. It's about historic decisions, which plague all software and specifications.

It is also not a clear "defacto standard". ljharb from airbnb says (https://github.com/prettier/prettier/issues/3503#issuecomment-352845480):

the most common and consistent standard for function keyword spacing in the ecosystem is "function keyword", "space", "optional name", "argument list".

I hope that all those involved will look at and consider the rather large number and volume of voices

We certainly will! Consider the fact that the original issue was split and re-opened through this one a good sign. Now, we need to let things settle a little. Give it a think-through. Gather some more :+1:s and comments.

(Or perhaps somebody makes a PR that is merged next week. Who knows.)

[bakkot]

Neither AirBnB nor Google recommend this style. It is not the style used by jquery, react, preact, bootstrap, babel, TypeScript, flow, express, angular, v8, spidermonkey, RxJS, lodash, istanbul, node, ember, d3, socket.io, qunit, jest, ava, jasmine, webpack, polymer, chartjs, gulp, bluebird, ramda, esprima, yarn, handlebars, immutable, uglifyjs, grunt, jsdom, glamorous, koa, eslint, or indeed prettier itself.

Not to say prettier's style is universal; there are exceptions: browserify, moment (sometimes), mocha, rollup, vue, npm. But these are much, _much_ rarer.

I was going to say something about how the style suggested in this issue wasn't the de facto standard in the ecosystem, but now that I've gone and looked, I'm going to make a stronger claim:

There is in fact an overwhelming de facto standard in the ecosystem, and it is what prettier already does.

I don't think we should worry too much about votes. The ecosystem is far larger than this issue tracker could possibly reach. This seems like a place prettier should stick to its guns.

Edit, 2018-05-11: both mocha and rollup have adopted prettier and the no-space style; I've struck them out from the list of non-examples.

[brianjorden]

First off, I was completely wrong on the AirBnB thing (and just wasn't sure on the Google suggestions). Second, although I don't know that I should go back and edit my prior comments, they did likely come off way too harsh/judgy/stubborn on my part, and sorry for that.

As to the usage and frequency in the ecosystem, there are some fairly sizable projects/groups that rely on standard and therefore likely are following this rule. (I had put together a little list before I saw bakkot's above.) Things like NPM, GitHub, Electron, Atom, Moment, Vue, Zeit, MongoDB, Zendesk, Mocha, Karma, WS, and https://raw.githubusercontent.com/standard/standard-packages/master/all.json

I'll admit, by no means a consensus or majority, but some non-trivial sized groups involved there. Also, the idea of "how that conversation would go" thing is amusing, but doesn't quite fly in the consulting world when talking about deliverables, contracts that call for code spec conformance, and a multi-layered IT department of even a moderately sized corporation. The suggestion of "just use eslint" doesn't quite work when I had explained that isn't actually an option (TypeScript + Vue + Vetur).

You also mentioned that this isn't just people being stubborn, and although of course the maintainers/original creator has every right to be stubborn, it does feel like there is a bit of that honestly. Couple small examples:

• https://github.com/prettier/prettier/issues/1139#issuecomment-294503338
• https://github.com/prettier/prettier/issues/3503#issuecomment-352880482

In reading through some of the 2.0 comments, it has become pretty clear I need to back off and find a new approach though. I know it got retracted a bit, but even comments about possibly removing TypeScript support came up over there. I do like and appreciate what this group has contributed and look to be contributing in the future. I'd love to actually do the PR to add the config option for this, but that proposal got completely shot down in the other threads. Just seems like sometimes groups (not just this one) can be a bit uninviting to new contributors or even discussion about a possible contribution.

My only point in trying to put so much effort into showing that there aren't realistic options to "just use another tool as well" and that a decent number of people/groups/projects would benefit from this, is that I think the "bike shedding, closing issue" thing can be a bit misused at times. To me and I think to many others, it is more "my bike has 3 wheels and can't fit through the door, could we make the door slightly wider?" and the response is "most bikes fit, go away".

[lydell]

@brianjorden Don't worry, this issue is open and isn't going anywhere! Just be patient :) (The original issue was closed when Prettier was just a couple of months old and we didn't know how to handle Prettier's popularity growth yet.)

even comments about possibly removing TypeScript support came up over there [in the 2.0 discussion]

You're misunderstanding – TypeScript support will never be removed. If anything it could be moved outside the Prettier core, but I doubt that.

[j-f1]

As one of the people advocating the removal of the TypeScript parser, I’d like to clarify: Babylon 7, our JS parser, has support for TypeScript. However, we currently use TypeScript’s parser to parse TypeScript. I was suggesting moving the code that uses TypeScript’s parser to an external plugin, then use Babylon to parse the TypeScript, decreasing the bundle size.

[bakkot]

Things like NPM, GitHub, Electron, Atom, Moment, Vue, Zeit, MongoDB, Zendesk, Mocha, Karma, WS, and https://raw.githubusercontent.com/standard/standard-packages/master/all.json

Interestingly enough, GitHub, MongoDB, and Zeit are already using prettier (elsewhere?). Mocha has been discussing adopting it, and a couple of the owners specifically mention not caring about this particular issue. So I don't think the lack of an option here is all that much of a barrier in general, even though it might be on some specific projects.

[TrySound]

Btw rollup is also gonna adopt prettier, so its own code style will be eliminated
https://github.com/rollup/rollup/pull/1896

[justrhysism]

a couple of the owners specifically mention not caring about this particular issue

Those that don't care, by definition, wouldn't care if it was implemented.

[j-f1]

Those that don't care, by definition, wouldn't care if it was implemented.

Apathy isn’t a good reason to add a new feature :)

[justrhysism]

Apathy isn’t a good reason to add a new feature :)

Agreed. With respect to adding weight to an argument, apathy is neither _for_, nor _against_ an argument - which is the point I was trying to make.

[ahimta]

I need to have spaces after function because this conflicts with Standard and I have to run a lint script manually that runs Prettier then Standard. Because I can't have save-on-format in my editor to do the same thing.

I don't disagree with Prettier not having spaces after function, it's just very inconvenient for me.

Thanks and keep up the good work!

[j-f1]

@Ahimta Have you seen prettier-standard?

[duailibe]

Agreed. With respect to adding weight to an argument, apathy is neither for, nor against an argument - which is the point I was trying to make.

In this case, apathy is an argument against implementing this.. if most people don't care about it, there's no reason for us to carry the burden of supporting in the future.

[ahimta]

@j-f1 what I really want is editor support. Otherwise, I could easily use git hooks or watch scripts -_-.
If Prettier decides to add an option for a space after function I may have enough motivation to implement it myself :).

[lydell]

@Ahimta It sounds like you have confused this issue with #3847.

[ahimta]

@lydell sorry I mean both (all function declarations). Since this is the one thing that Standard doesn't allow.

[lydell]

sorry I mean both (all function declarations).

Whitespace is _mandatory_ between the function keyword and the function name. This issue is _not_ about a space after function. It is about a space after the function _name._ See the OP.

[ahimta]

@lydell I mean exactly these two cases:

1. function () { }
2. function f () { }

[justrhysism]

@Ahimta:

1. function () { } => #3847
2. function f () { } => #3845 (this issue)

[ericanderson]

I have never seen javascript code that puts a space between the method name and the paren in the declaration. Is there any prior art for this that this has any commonality?

[justrhysism]

Yes. For starters: https://standardjs.com/

[ericanderson]

Libraries that don't follow this "standard":

• Lodash
• jQuery
• React, going back to 0.14 to show pre-prettier
• Redux, going back to 1.0.0 to show pre-prettier
• Angular, 4.0
• Typescript
• jshint
• tslint
• webpack
• Gulp
• Ember

[pvdlg]

standard doesn't allow any option nor to configure any eslint rule. So the fact that standard users put a space after the function name doesn't necessarily means they "like" this style, it can also means they "tolerate" it because they found other benefits using standard such as having a predefined rules, no config etc... There is no way to know other than conducting a survey.

If standard would allow to turn that rule off or to change its config and if those users made the deliberate choice to enable (or to not disable) the space after the function name, then that would be an argument in favor of the popularity of this style, but it's not the case.

A better indicator is: How many people not using standard (therefore making a deliberate choice regarding each particular style) write code with a space after the function name?

From the various comment it seems browserify, moment, rollup and vue do not use standard and choose to use a space after the function name.
That can be compared with the many other projects mentioned in this thread not using a space after the function name.

That said, even if a particular choice made by standard is not a good indicator of popularity among users, it should be taken in account to determine the amount of code changes generated when using Prettier on a project using standard.

[pvdlg]

Another indicator of popularity for one style or another, is what is used in the popular JS language online docs:

• Mozilla
• W3schools
• Microsoft

In this particular case, all 3 of them do not put a space after the function name.

[lydell]

Please read through the entire thread before commenting, so we don't go in circles. Which projects do and don't use this style was already mentioned in https://github.com/prettier/prettier/issues/3845#issuecomment-362211847 and the following comment.

[pvdlg]

I did read through the thread and I was mentioning that only a subset of the projects listed in https://github.com/prettier/prettier/issues/3845#issuecomment-362211847 do not use a space after the function name and do not use standard (therefore only this subset made this deliberate choice).
I'm sorry if it wasn't clear.

[pakastin]

Yes please, this is a deal breaker for me!

[franleplant]

Please take in account that standard is _not_ in any way the official standard for javascript code styling, it's just a very inconvenient name that gives it a great marketing but confusing non the less.

[gillesdemey]

Whether it’s false marketing or not is completely irrelevant to the topic, and frankly mildly insulting to all the good folk who’ve put in their time and effort into making it a great linter.

[ahimta]

:sweat_smile:

[dinoboff]

does standard have an issue (even closed) about adding an option to change that style?

[coolemur]

https://standardjs.com space before function parenthesis is used by:

NPM, GitHub, elastic, nearForm, Brave, ZEIT, zendesk, mongoDB, Typeform, GOV.UK, express, WebTorrent, IPFS, dat, BitcoinJS, ATM, ELECTRON, OLTRA, TREASURE DATA, clevertech, Study Notes, optiopay, JAGUAR, LAND-ROVER, BUSTLE, zentrick, NODESOURCE, GREENKEEPER.IO, ARMA, TASER, neo4j, RENTOGRAPH, eaze, Ctrl Alt Deseat. And many more ("In addition to companies, many community members use standard on packages that are too numerous to list here.").

Not to mention all developers that have issues with that one rule and complaining in GitHub.

And your contra-argument is that it's not a standard? What would make it a standard then? :)

And please don't take this message as an insult.

To make rules configurable when users have issues with forced ones sounds like common sense.

And at this point they just don't care... Do they even try to understand what people are saying?..

[duailibe]

Having re-read this thread many times, I noticed a few things:

• It doesn't seem to bring any major benefits
• A lot of big projects don't follow this code style
• biggest reason for changing this or adding an option is "standardrequires it".

standard won't change it (https://github.com/standard/standard/issues/89, https://github.com/standard/standard/issues/217, https://github.com/standard/standard/issues/311) yet people ask that we do it?

standard has zero options. From their README:

No configuration. The easiest way to enforce consistent style in your project. Just drop it in.

And yet people ask that we add "just this one option"?

Quoting standard's own author:

Let's be honest: this is an pretty unimportant issue. You might be able to find some minor reasons why your preferred style is better than the other style, but others can come up with reasons why their choice is better than yours, too.

It doesn't matter which choice we pick. Both choices are valid. Neither choice will lead to more bugs or programmer errors. So, we just need to pick something.

What exactly are you proposing? That we change the rule and force 100K+ monthly users to change all their code? Sorry - not happening.

Which I couldn't agree more.

So my personal opinion is that we shouldn't do this.

Again my personal opinion and not Prettier's oficial decision, the issue will still be open for discussion, and I'll happily implement this change/option if we collectively decide on this. Keep this in mind before you start attacking us.

I just wanted to add another point of view on the issue.

[coolemur]

@duailibe

What exactly are you proposing? That we change the rule and force 100K+ monthly users to change all their code? Sorry - not happening.

You don't need to force nothing when you make this OPTIONAL. Because it is optional....

This is just another excuse (not a good one) to dodge implementing this functionality...

It's sad that you try to force your own rules (that you think is best for all of us) on your tool.

[jorgegonzalez]

@coolemur

It's sad that you try to force your own rules (that you think is best for all of us) on your tool.

That's the point.

Prettier is an opinionated code formatter.

This is the first line in the README. The more options Prettier adds, the less opinionated it becomes and the more it distances itself from this goal. See Prettier's option philosophy and this discussion.

[coolemur]

@jorgegonzalez Great. There is no point to discuss this here I guess.

Stop wasting other devs time then. And close this issue.
I see you have a strong opinion over this one.

And just write in your documentation that if we need one tiny space that is against your will - then this tool is not for us. ;)

[coolemur]

BTW its so funny that your TEAM is just giving thumbs down for your tool users comments. :))

Because this means a lot in this "discussion"... Where everything is decided already. :))

[jorgegonzalez]

@coolemur

Stop wasting other devs time then. And close this issue.

BTW its so funny that your TEAM is just giving thumbs down for your tool users comments. :))

The unproductive and condescending language is unwarranted. Maintaining a project as large as Prettier takes a ton of time and energy, and attempting to satisfy everyone's use case is impossible.

[j-f1]

@coolemur We keep this issue open because we are considering making this change if there’s enough support for it. Right now there really aren’t enough 👍s to counteract the 👎s.

[coolemur]

@j-f1 Tell me about large projects.

When I read your team comments, they are stated like there is no way to convince you. So why even keep the issue opened? How much "thumbs up" are enough ? Please tell me exact number. Then I can decide if there is a point to wait for this "feature". :))

[coolemur]

It's really odd that people voting for OPTIONAL FLAGS. :)))) It's like voting against door that can be unlockable. But I guess people just want to have it closed. :))

[coolemur]

Good luck with the project I guess. xD

[coolemur]

@jorgegonzalez loool. Spam. Nah. I won’t support the principle “the right one is the loudest one”. Let them have it. :D

[j-f1]

@coolemur

When I read your team comments, they are stated like there is no way to convince you.

I read through all of the team member comments on this issue, and almost all of them said that we’d add the option if there was enough support for it. @duailibe’s comment says that they personally don’t support this, but they’d be willing to implement the option if there’s enough support.

This is just another excuse…to dodge implementing this functionality.

It would be really easy to add an option here. It would also be really easy to add an option to put three semicolons at the end of each line or two spaces on each side of operators. We don’t do that because there isn’t enough support to do so.

BTW it is so funny that your TEAM is just giving thumbs down for your tool users comments

BTW it is so funny that you are giving thumbs up to your own comments

[alexander-akait]

@j-f1 let's do this and finish this holy war.

Almost each day I start with mark this issue as read.

Who will be support this option from this thread, who will really improve and fix problems, and not just talking about the good and the bad?

I do not want to brag about myself, but when i have difficulties with css/scss/less/css-in-js, I just click fork and started to fix problems and improve pretty output. Who can take on the same thing?

[coolemur]

@j-f1 I gave thumbs up for my own comments so you would notice how stupid it looks when someone licks his own balls. lol. I am glad that you noticed. xD

[ahimta]

I use a workaround for this by running Standard and then Prettier and it works and passes without any errors:smiley:. I have a lint script that does this and pre-commit hooks using lint-staged and husky (can't stage specific lines at the moment though:sweat_smile:).

The pre-commit hooks are especially helpful, since they ensure your code is always linted and the linter is only run on staged/committed files (very important for large projects).

Having the option for space after function will definitely be convenient for me to have both Prettier and Standard run, on save, when using my text-editor. But I understand how this might not be the right thing to do in the long run. I have my own side-projects and my full-time job and in all the projects I'm working on, users focus on the solution (adding space after function in this case) and forget the problem.

I personally think that the space after function is a valid option since it complements the one-and-only (as far as I know) opinionated JS linter (Standard) and I understand that this might not be the right solution to the problem in the long run.

Thank you and please do ignore the rest of the comment:sweat_smile:

And finally, I think both Prettier and Standard, to reach enlightenment, should have braces in their own line and a comma in the last line of an array/object (just saying:sweat_smile:).

Braces in their own line:

if (x)
{
}
else if (y)
{
}
else
{
}

Comma in the last line of an array/object:

{
  x: [
    1,
    2,
  ],
  y: 3,
}

[j-f1]

@Ahimta for trailing commas, you can set the trailingComma option to es5 or all.

[UncleInf]

It is a bit ridiculous - there are people that this issue is a blocker at using prettier, they are vocal about it but they are not a majority and therefore they wont be heard. When this is an issue for majority of people it is already too late.

Help us be in this prettier hypetrain not by bragging in the home page about who uses pretter, but by listening to every Joes who rely your tool.

[lydell]

If you cannot change your tools to play nice with Prettier it is a strong indicator that you shouldn’t use Prettier. Even if we do add this you are very likely to run into problems down the line. The tiniest change we make (perhaps to fix somebody else’s problem) could cause a conflict (preventing you from updating Prettier) for you and we’re back on square one again.

If we add this as an option, we just spread out this discussion from this single issue thread to every team out there using Prettier. We’ve already “failed” on single vs double quotes, semis vs no semis, tabs vs spaces, etc. Which is why we’re hesitant on just slapping on another option.

Sometimes it is easy to see the problem, but not the best solution. For example, why is it Prettier that should do something, and not the conflicting tools (standard)? (Mostly a rhetorical question.)

[coolemur]

For example, why is it Prettier that should do something, and not the conflicting tools (standard)

Because "standard js" is more popular than prettier and more companies use it.
"Stronger" companies, I would say. Like vue.js. Which is progressive JS framework. And another question - on what basis do you create new "standards" like this one ? Just based on your opinion ? Without any research ? Because it is "opinionated tool"? That's sounds weak... (no offence please)

The tiniest change we make (perhaps to fix somebody else’s problem) could cause a conflict (preventing you from updating Prettier) for you and we’re back on square one again.

"Could cause". Perhaps. You haven't tried it yet. Right? "preventing you from updating Prettier" ? How would optional flag prevents anyone from anything?

The only con I see in allowing users to optionally turn on whitespace before function parenthesis is that somehow other teams will turn it on when they shouldn't turn it on in their own projects. But hey, people have brains and they use them. Default value of this flag should be "off".

And again. Same team votes for your comment. Do you support the comment ideas (that is written in the comment you are upvoting). Or do you support just a fact that you have your preconceived opinion not to fix this issue ? :)

Sometimes it is easy to see the problem, but not the best solution. For example, why is it Prettier that should do something, and not the conflicting tools (standard)?

Is your solution = "don't do anything" ?

Can you please give decent reasons why optional flag with default value "off" is a bad thing ?
Not giving a decent reasons and just picking the side sounds like a worst case scenario...

[bakkot]

Because "standard js" is more popular than prettier and more companies use it.

I don't think this is the case. See my list above, or compare npm stats.

[coolemur]

@bakkot

It is not the style used by

You are joking right? ???? You just giving the companies tha DONT use it ?

Not to say prettier's style is universal; there are exceptions: browserify, moment, mocha, rollup, vue, npm. But these are much, much rarer

Optional flag with default value "off" would open bridges for these ..what you call "exceptions".

[bakkot]

You just giving the companies tha DONT use it ?

Um. My comment lists both projects which use the function f() style (the much longer list) and the function f () style (the much shorter list). I don't understand your comment.

[coolemur]

@bakkot

Neither AirBnB nor Google recommend this style. It is not the style used by jquery, react, preact, bootstrap, babel, TypeScript, flow, express, angular, v8, spidermonkey, RxJS, lodash, istanbul, node, ember, d3, socket.io, qunit, jest, ava, jasmine, webpack, polymer, chartjs, gulp, bluebird, ramda, esprima, yarn, handlebars, immutable, uglifyjs, grunt, jsdom, glamorous, koa, eslint, or indeed prettier itself.

This is a list of companies that doesn't use standard style. Not the companies that use prettier style. Am I wrong ?

[coolemur]

Can you please give decent reasons why optional flag with default value "off" is a bad thing ?
Not giving a decent reasons and just picking the side sounds like a worst case scenario...

[nicolo-ribaudo]

@coolemur Standard and prettier are two conflicting tools: they both enforce some formatting rules, so you should choose either one or the other.
If you really want to use both, you can use https://github.com/standard/eslint-config-standard and disable the rules which conflict with prettier.

[bakkot]

This is a list of companies that doesn't use standard style. Not the companies that use prettier style. Am I wrong ?

It's a list of projects, not companies, but yes, not all of them use prettier. If you're just interested in comparing the number of projects using prettier vs standard, rather than which style is more common, I'll point you again to the npm stats.

Can you please give decent reasons why optional flag with default value "off" is a bad thing ?

See the Option Philosophy document or this issue, which are linked above.

[coolemur]

@bakkot Your links didn't answer my question. "Can you please give decent reasons why optional flag with default value "off" is a bad thing ?"

Your links are for general cases.

I still have no answer to a question why it is bad to have optional with default value off ?

a) Because your tool is opinionated ?
b) Does it cause bugs in your tool ? Well hey, that is what developers do - compare configurations and solve conflicting issues right ?
c) Because you had a bad practice with other options, so you can't even try this one ?

Have missed npm stats link. So my apologies for this one.

[bakkot]

I still have no answer to a question why it is bad to have optional with default value off ?

The Option Philosophy says right at the start:

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.

That is why it is bad.

[coolemur]

@bakkot This is not an answer. This is just a philosophy.

That is why it is bad.

Based on your philosophy?

P.s. sorry for asking questions, but this is how thinking works. This is how you make people think about their decisions. :)

The only valuable comment is to use https://github.com/standard/eslint-config-standard.
You might want to add this into Prettier documentation or FAQ.

This might cool down so called "holly war" a bit.

[j-f1]

@coolemur Feel free to fork Prettier and add any options you need. Code changes for options are generally pretty small and easy to make. In fact, such a project exists: https://github.com/arijs/prettier-miscellaneous. Note how many stars it has compared to Prettier. To me, that indicates that people actually think Prettier’s lack of configurability is a feature, not a bug.

[jaredthirsk]

1 out of 24 people who star this project also fork it -- 1124 forks. Maybe the forks are the "options"? But that is a lot of forks to wade through :(

[j-f1]

From my experience clicking through the forks of another project, I’d estimate upwards of 90% of people don’t modify the fork.

[nijikokun]

Is prettier a standard or is it a formatter? If it's a formatter, it shouldn't matter what projects use, it should be dictated by what the language allows and expose functionality / options based on that.

Standard, is a standard. It having no options makes sense, that's what it prescribes. Prettier? Formatter. Completely different field and doesn't matter what "popular" or "not popular" projects use, but what the language allows.

Language allows having the space there, prettier should abide and allow the formatting as such.

To argue otherwise, huge waste of time, especially given the length of this thread and to quote yourself:

Code changes for options are generally pretty small and easy to make.

[ericanderson]

Prettier is a tool. It’s maintained by a select set of people. It has policies about its updates and it is opinionated. Don’t like it? Fork it. Standard is no more of a “standard” than prettier. I’d be willing to bet more lines of code use the “prettier standard” than any other.

It has been made abundantly clear that this isn’t changing in the 1.x timeframe. It has a 0.001% chance of showing up in 2.x. Just move on.

[carlos-algms]

I Just have migrated to Beautify, and there is no problem anymore.

Prettier has its Philosophy, so migrate, don't discuss.

It would be great if they accept the option to just add 1 single space to an anonymous function, but if don't, we move forward.

[j-f1]

just add 1 single space to an anonymous function

The issue for that is #3847, and it seems more likely to be approved.

[carlos-algms]

I don't think so :

https://github.com/prettier/prettier/issues/3847#issuecomment-390713301

It seems to me that the developers already have decided about it.

Maybe I'm wrong, but it is they philosophy.

Em Sex, 25 de mai de 2018 11:06, Jed Fox [e-mail]
escreveu:

just add 1 single space to an anonymous function

The issue for that is #3847
https://github.com/prettier/prettier/issues/3847, and it seems more
likely to be approved.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/prettier/prettier/issues/3845#issuecomment-392068841,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEa39a1ObuKJ_jQ3v0o3Ihv3kutpp4Ybks5t2A_YgaJpZM4RzZNv
.

[bakkot]

@carlos-algms, that comment just says prettier is unlikely to add an option. (Which is good, because options are bad.) However, it might unconditionally change its behavior for that case. (But probably not this one).

[aboyton]

@coolemur To answer your question, here's my reason for for not wanting options (as a user of Prettier, I'm not a maintainer nor even a contributor).

As someone who manages the JavaScript of a large company I have better things to do then worry about code style. That's why at work we originally used Airbnb's Style Guide, it seems to be why a lot of people love Standard, and why at work we've been so happy switching to Prettier. Every option Prettier adds is a discussion "why don't we turn this option to foo" which goes against the very reason I love it.

As an individual I agree, I can just ignore an option, but for a large company each option can become a discussion. And it these discussions that I'm trying to avoid by using Prettier.

Do I agree with everything that prettier does? Not at all. Personally I prefer the symmetry from having parens for multiline statements (see https://github.com/airbnb/javascript#arrows--paren-wrap), but I'm more than willing to put up with so at work I can be focusing on more important things.

Prettier doesn't agree with Standard just like it doesn't agree with Airbnb (I documented as list of differences in https://github.com/airbnb/javascript/issues/1548 when I asked on Airbnb's style guide about switching to Prettier which unfortunately got locked as I didn't know how to use Github very well). When we switched to Prettier we had to disable some Airbnb rules but we found at work no-one really minded switching to a new list of rules as long as Prettier fixed their code for them. I'd strongly encourage you to try the same.

[coolemur]

@aboyton I think it's always a good thing to discuss best coding style in your company.
Are you just a company manager or do you code all day long and deal with code styles?
Because people who code discuss best style and use it as convention. Despite tools that force them to use bad styles. If conventions are broken by "tool forced style", then you throw this tool to trash bin. That's it.

Btw: large company or small that doesn't matter. Developers must communicate with each other.

And to be clear... problem with prettier is not the style that "I don't like", its the style that "doesn't work out of the box with initial vue projects". So please keep this in mind...

There was a suggestion to configure eslint options.
That works just fine.

But... I will have to configure every single future project. Just one additional step in workflow. This is less efficient than change one option in text editor.

But people doesn't care about efficiency..... :/

[aboyton]

I run a small team that manages the way we do our JavaScript (and TypeScript) across the whole company so I spend most of my day coding and reviewing other people’s code. As a coder I spend a lot of time reading code (both my own and others) and I think a consistent style really helps with readability and understanding.

For me a consistent coding style across a company is incredibly useful, but for my team (and company) I’d like these discussions to be at a more architectural level: what data model do we go with, how should we do asynchronous code (promises, async, or RxJS), how much should we enforce immutable state, how far down the functional programming spectrum should we go, etc., etc., etc. This is what a lot of my time is devoted to (deciding what to go with and then implementing it) as the implications here are huge and hard to change later (and new trends come and go each day).

When it comes to things like white space (which honestly is all Prettier does) I just don’t really care. Find something people can roughly agree on and move on. We tested Prettier, found it was good enough (and a lot better than the wildly different styles we had scattered across our codebase) so after some trials across teams we turned it on and haven’t looked back. Obviously you are free to do what you like, this is just my experience.

[coolemur]

@aboyton

When it comes to things like white space (which honestly is all Prettier does) I just don’t really care.

Clearly, you haven't faced any serious problems that one white space can cause... so why you even try to convince us, that "it's fine", "it's ok" ?

For you it's just a white space.

For me it's white space that cause project not to function anymore without additional project configuration.

Let me remind you again, that the main problem is initial vue projects that use standard linter.
Each time we create new project we will have to configure it.
That is LESS efficient than change one prettier option for all projects...

[jorgegonzalez]

So just about everyone who is in favor of this change is citing Standard; why don't you request that Standard make this rule configurable? Why should Prettier conform to Standard and not the other way around?

[gillesdemey]

Standard can be configured every which way you want by either using standardx or the shareable eslint config – so standard doesn't have to make any changes, it's already very flexible.

Those who cite standard simply would like it to be compatible with prettier out of the box.

[coolemur]

@gillesdemey THANK YOU!

[carlos-algms]

@gillesdemey

Standard can be configured every which way you want by either using standardx or the shareable eslint config – so standard doesn't have to make any changes, it's already very flexible.

It is not an option to TypeScript users.

Also, I agree with @coolemur, about the prettier config does not work out of the box with initial projects.
Change the style-guide suggested by a framework, like Angular or Vue, is not good for the community.

[bakkot]

@carlos-algms

It is not an option to TypeScript users.

I'm missing the context; what does this refer to? The only thing I could think of is TSLint, but the relevant rule is more than flexible enough to accommodate either style.

Change the style-guide suggested by a framework, like Angular or Vue, is not good for the community.

Sidebar: I disagree; it is good for the community to converge on consistent style when there's a clear consensus on what that should be.

[coolemur]

@bakkot So why this rule doesn't work with one of the most popular JS frameworks out of the box?
I think the consensus is clearly wrong...

[carlos-algms]

@bakkot
StandardX is not an option to TypeScript users, because it uses .eslintrc file to specify the rules.

I don't like the space on named functions as well, sorry, I was talking about the space after an anonymous function. (I know, wrong thread)

[carlos-algms]

Also, after think about it, I do agree with consistent style guide across all frameworks and libs!
One will be used with the "visual" steps and fell comfortable reading any source code.

But I still prefer the space after anonymous function 😄 and no space after named functions.

[coolemur]

@carlos-algms I prefer styles that work out of the box. And I don't prefer subjective people preferences.

[ericanderson]

Prettier is no more subjective than “standard” or anything else.

Can we please lock this. It’s far beyond usefulness

[coolemur]

@ericanderson “standard” is not the main problem here. The problem is that vue projects doesn’t work with prettier out of the box. If you solve issues by locking them or closing them but not fixing them - I have nothing to say to you, personally.

[coolemur]

By the way, I read arguments such as “our opinion is strong on this one because we have a link that explains that we have our opionated rule”.

My main argument is “this doesn’t work”.

[ericanderson]

I hardly see how Vue projects not working out of the box should be a prettier problem. Go tell Vue “this doesn’t work” because it’s not compatible with prettier out of the box.

Would you demand that Sony makes Halo Xbox discs work in their system? Or perhaps demand ford “fix” their engines so they fit in a Honda? Or that Victory Secret leave bulge space in their women’s underwear? Or a butcher to offer vegan options?

You may choose to use this tool or you may choose to not. It’s that simple

[coolemur]

@ericanderson So you change framework, but not the tool ?

If something doesn't go together would you change a programming language or a tool ?
Would you change OS or fix a program ?

My argument is to change SMALLER thing which is tool, but not the BIGGER thing which is framework.

And what is your rational explanation to change vue framework?

[coolemur]

@ericanderson By the way, your "Sony" here is the vue framework, not your "prettier" tool..............

How do you think comparing software with THINGS (cars) is right way to substantiate your statements ? :)

I hardly see how Vue projects not working out of the box should be a prettier problem.

Developers create tool and if it wont work they say "it's not my problem"?

You may choose to use this tool or you may choose to not. It’s that simple

I am not even using your tool for my vue projects.
I'm trying to point out what could be better and fixed in prettier.

Don't try to convince people that "this is our opinion", "this is not our problem", "this is not a problem" etc. Cause that makes no sense, you just changing your discussion arguments from time to time.

All I am saying this doesn't work with initial vue projects. You should fix it OR close this issue and write "not for vue developers" in documentation. 🗡

[ericanderson]

Dear Ford. Please update your engine manual to specify that your engines will not work in an unmodified Honda. Thanks!

[coolemur]

@ericanderson It's just a suggestion to make it better. Keep your sarcasm to yourself. Do you really think comparing software with hardware is smart thing to do ?

Prettier is not a Ford. It's text formatter. Which should format javascript. Javascript rules are defined by latest trends and giant frameworks, not your opinions.

[ericanderson]

Re Sony and Halo. The request to MS “fix” Halo is just as absurd. If the prettier documentation said “Works with vue out of the box”, then there would clearly be something that needs to be fixed (code or docs) but absent that, and given the quoted policy in options, there is nothing “wrong”.

Another absurd example: go ask eslint to support typescript so you can use standardx

[coolemur]

I will repeat myself:

Prettier is not a Ford. It's text formatter. Which should format javascript. Javascript rules are defined by latest trends and giant frameworks, not your opinions.

[coolemur]

I think it's absurd to state "this is our opinion", "this is not our problem", "this is not a problem".
Would you hire developer who always would have these excuses ?

[coolemur]

@ericanderson

Another absurd example: go ask eslint to support typescript so you can use standardx

We can always leave things as they are and never fix anything or make things better. Right ?

[ericanderson]

Your subjective opinion of better is no more valid than anyone else’s subjective opinion.

I’m done arguing with you. Good luck with your projects.

[carlos-algms]

Please guys, don't take it personal, is just a space.

I know, is difficult to understand why it shouldn't be an option. But OK.

In last case scenario, fork it and do it yourself.

But please, don't offend each other.

[coolemur]

@ericanderson Rules that are made by fameworks are not my opinion. Sorry if my discussion arguments offended you. Didn't meant to.

[duailibe]

I don't think anything else valuable can be added in this discussion, all the arguments have already been laid out, I'm locking this for now.

[j-f1]

That’ll stop people from 👍-ing the issue, though :/

[lydell]

Yeah, can we unlock it again so people can vote? Contributors are free to hit the "Unsubscribe" button on this particular issue to avoid unnecessary notification noise. We can also mention in the OP that votes are welcome, but that there's no need for more discussion right now.

[austinkelleher]

I realize that I am a little late to the party here, but I want to re-iterate what I had communicated in the original issue, since it doesn't appear to be discussed here.

Providing an option for a space before function parens can improve project search quality.

I still would very much like to see this change made. This is not an issue of "Standard" vs. "Prettier" or whether Prettier is a "formatter" or a "standard", to me this is more of an issue of what makes more functional sense from a searchability standpoint. I don't see any real benefits at all to the current formatting. Why are we even having this conversation in the first place? If there is absolutely no benefits to the current formatting, why haven't we switched to the new format? If we change the formatting to put a space before function parens (or at least provide an option), and some people do not want to write the space, that's fine because Prettier will format it for you. Then there would be better searchability for people not using a feature-rich editor.

/cc @lydell @j-f1 @duailibe would love to hear your thoughts on this. Thanks in advance.

[lydell]

@austinkelleher Searchability is mentioned in the OP, and these are my thoughts on it: https://github.com/prettier/prettier/issues/1139#issuecomment-361665087

[BenoitZugmeyer]

For those interested, I'm maintaining a branch implementing a new option functionParenSpace: true/false (default to false). Setting it to true should insert spaces between the function names and the next opening paren, as required by standard. I won't open a PR until a consensus has been achieved, but you can try it to see if it fits your needs.

npm install 'BenoitZugmeyer/prettier#feature/function-paren-space'

[akalineskou]

How can you guys (the prettier devs) be so stubborn?
Just add this option and be done with it!

[karlhorky]

@alex2005git it's in the benefit of all users for tools to stay low- or zero-configuration as much as possible. Simplicity and low configuration allows for quicker turnaround on issues, lower complexity, lower chance of options conflicting with each other and increased maintainability.

I looked into this a bit for a talk that I've held a few times ("rise of low configuration tooling").

I think @gaearon put it well in #40:

You’re going to be under a lot of pressure to make X, Y, and Z, configurable.
Configuration is a perfect example of tragedy of the commons.

Everybody wants to add just a tiny piece of configuration to satisfy their use case. As a result we end up with inconsistently designed tools, with unexpected combinations that don’t work correctly, with bugs and regressions that, when fixed in one configuration, break something else with another configuration.

The requests for configuration are vocal. The requests to stay simple are often silent.

[coolemur]

when fixed in one configuration, break something else with another configuration

Comparing configurations and satisfying use cases is one of developer responsibility tho...

If only I could tell my boss "we wont create something because it might cause other issues"...

No offence, but I call this "laziness".

[coolemur]

It's funny that you mark comments as "off topic" that express other opinion than yours. :)
How can you call this "discussion" when you force opinions ???
Don't remove this, please. :)

[austinkelleher]

@karlhorky The argument of minimum configuration is valid, but why isn't this the default behavior anyway? The only argument I've seen is that it was just the initial opinion during development. It has no real functional benefits at all. Is introducing this change of behavior so bad? See my argument here: https://github.com/prettier/prettier/issues/1139#issuecomment-316096507

[karlhorky]

@coolemur I'm not sure why it was marked as off topic, but maybe because topics like "developer responsibility" and corporate hierarchy like something that your boss told you to do are less applicable to the discussion here, which is to try to figure out how to cater to the use cases brought up in the least impactful way for everyone involved (Prettier users who support this change, those who don't, the maintainers of the library, users who want something in the future, etc) - or whether the prettier project wants to cater to it at all. An employee may have less options for saying no, but corporate hierarchy doesn't really fit here.

Re: laziness, it's hard to connect the of trait of laziness with the behavior of the maintainers and other people here that are going to great lengths to try to fairly and justly come to the best decision that will affect many users. The topic of making a small change may seem simple, but the total cumulative impact of the change, also in the future, makes it somewhat more complex.

[coolemur]

@karlhorky I can't see this as a fair discussion when devs team are down-voting/deleting comments that they just "don't like". Could anyone explain, why having customisable default values is bad if it has defaults?
Can you give me any decent use case where having customisable default value would crash a project?

I don't think it's a good idea to base your statements with "we think this might not work". :)

[karlhorky]

@austinkelleher I actually agree with your point (and I actually override prettier's default with prettier-eslint in order to achieve this):

Searching for a function definition can be challenging. Having a space after a function name can help narrow (and often point exactly to) the function definition.

However, regarding integrating this in prettier, I would not support such a change, because it is not the predominant JavaScript style and has low adoption compared to the alternative (no space). I have seen a lot of JavaScript code from various sources (repos on GitHub, forums, Stack Overflow, books, etc) in the last ten years, and it's my feeling that this is an uncommon syntax construction. For me, the point of making certain (maybe not widespread?) developer tooling flows easier has less importance than supporting a common, idiomatic code style.

[karlhorky]

@coolemur

Could anyone explain, why having customisable default values is bad if it has defaults? Can you give me any decent use case where having customisable default value would crash a project?

Sure, here's an example as to when things can get out of hand, from webpack (known as having many configuration options): https://github.com/webpack/webpack/issues/2145#issuecomment-294361203

Yes, it can be argued that this is a hyperbolic example and that should never happen with "one small change", but it's always one small change until it becomes unmanageable.

[coolemur]

@karlhorky
So you comparing webpack configuration options to text formatter options (that prettifies code)?

Also you think that alowing people to optionally configure code style can do damage to project such as webpack configuration issues ?

Yes. This is hyperbolic.

[duailibe]

No offence, but I call this "laziness".

How would you feel if I called you lazy for complaining on this topic for 2 months instead of forking and writing this feature yourself? :-)

I can't see this as a fair discussion when devs team are down-voting/deleting comments that they just "don't like".

People are free to downvote whatever they want. I marked off-topic comments because they were off-topic. It has nothing to do with "don't like" (there are several comments that I don't like but are still here :-)). No comment was deleted AFAICT.

Can you give me any decent use case where having customisable default value would crash a project?

This has been discussed over and over. Yes, having more options will make development harder (and we maintain this tool on our free unpaid time), but it also goes against Prettier's core value. If you disagree with those, you are free to fork or use another tool.

[coolemur]

@duailibe
Your team is forcing opinion without giving facts.

karlhorky gave a fact and a link. People like him must be appreciated.

We all know what happens when projects are forked.
It is better to have centralised coding, than many custom forks.

Instead of forking a project I do project-testing work for you.
Have you tested this issue with real life scenario ? Because I did. And prettier failed.

Yes you can fork it, fix it by yourself, use workarounds, etc.
But this is not an option. I stopped using prettier months ago.
Just disabled "format on save" option.

This worked like a charm.

Just trying to help you make your tool better. Nothing less, nothing more.

You could call me lazy if I stopped coding my own projects. :)

This discussion is pointless when you already have your decision which cannot be changed.

[carlos-algms]

I agree with @karlhorky and @gaearon. We should keep it simple and avoid the Tragedy of the commons.

But what looks confuse to me is:
Why something that seems to be used a lot is not the common ?
Airbnb styleguide is the most cited styleguide out there,
and the prettier, that is the tool perfect for the job, can't agree with it.

Why no-space is the common?
Where is it documented?
Is it as famous as Airbnb Styleguide?

[coolemur]

I still wait for a decent use case where this option could break any projects.
Just fear that "something might happen" is not an argument...

[bakkot]

@carlos-algms, what prettier currently does for this issue _is_ what AirBnB's style guide recommends and is what the vast majority of large JavaScript projects use. See this comment.

You may be thinking of issue #3847 rather than this one.

[j-f1]

@coolemur

Your team is forcing opinion without giving facts.

Fact: You’ve complained on this issue for two months.
Fact: Some popular style guides don’t follow the space-before-paren-and-after-name style. (Note that there are some that do)
Fact: This issue has 122 👍 reactions and 146 👎 reactions, which means that there’s not an overwhelming majority one way or the other.
Fact: We have limited time to maintain Prettier.
Fact: You can fork Prettier and add as many options as you’d like. Maybe everyone will flock to it and use it instead of ours! If so, congratulations!

karlhorky gave a fact and a link. People like him must be appreciated.

I agree. Please do!

We all know what happens when projects are forked.
It is better to have centralised coding, than many custom forks.

Exactly our argument! Prettier has one centralized style (mostly), instead of many different styles that can be used.

Have you tested this issue with real life scenario ?

Yes and yes! Also, Facebook runs it on 100% of their JS.

Because I did. And prettier failed.

That’s OK! Feel free to use another formatter or format your code by hand. Not every product works for everyone.

Yes you can fork it, fix it by yourself, use workarounds, etc.
But this is not an option. I stopped using prettier months ago.
Just disabled "format on save" option.

Great! Then what we do with the project doesn’t affect you!

Just trying to help you make your tool better. Nothing less, nothing more.

Being rude makes us want to stop working on Prettier. That doesn’t seem like helping to make it better.

You could call me lazy if I stopped coding my own projects. :)

Nope! What you do with your free time is not my business. If someone needed something fixed and you didn’t fix it, you could fork it. Also, it’s not like we’ve stopped working on Prettier.

This discussion is pointless when you already have your decision which cannot be changed.

It can be changed, but the way you’re discussing isn’t helping.

[coolemur]

@j-f1 Is my complaining for two months sounds like a serious fact why this issue isn't closed yet? Either fix it or close it. Or perhaps you like when people gets frustrated...

I will repeat myself third time: is there a decent use case where custom options (with default value) can cause a project to fail ?

One use case was a comparison with webpack configurations. But it is a different thing than code style configurations. Like your comparison of prettier forks with prettier options are two different things. But for arguing it sounds legit (?).

[Frondor]

First of all, I don't implement this rule, but I'm no standard-Nazi either. I can live with both approaches as long as my team doesn't specify one style for this.

I've been reading a lot of comments; we all see how far this has gone and yet, you look like enjoying other's people begging. Because all I see is a _"No. / look at our 26k stars / Facebooks uses prettier... / We don't care about standard js / etc..."_, this specifically is disgusting to read.

In my opinion, if the developer wants to run this formatter in certain way, that he'll be implementing a code style used by nobody else, he should be able to do that! Why not? Oh! The "philosophy".

It's not like there are zero professional teams implementing this rule. Man, Vue has more stars than react (since some of you are kinda worried about stars) and they can perfectly live with that!
Just stop being mean! Don't laugh at others just because they want to use this formatter in a different way that you use to.

Just put a new flag, I don't know, --uglify-your-functions, --do-whatever-you-want, --fck-my-philosophy or simply --bad-opinions and that's it. Let prettier be opinionated by default, but also let people run it as they want, read their extra configuration, format their code, close all this nonsense.

[coolemur]

@Frondor Logic is not allowed in this discussion!

[alexander-akait]

A lot of bla,bla,bla, but there is no one PR, if you look on label, you can see it is doesn't have discussion. The time that is constantly wasted on conversations here could be profitably spent on implementation. I apologize if for some developers my words will sound rude.

PS: with a ready pr it is easier to evaluate how difficult it will be to introduce it.

[BenoitZugmeyer]

@evilebottnawi check my comment above :pray: https://github.com/prettier/prettier/issues/3845#issuecomment-400252269

[alexander-akait]

/cc @vjeux looks issue doesn't have discussion. Can we accept PR?

[Frondor]

@evilebottnawi It's unbelievable the amount of nonsense I've read from you in all these threads. With all due respect, how do you expect someone to send a PR if your attitude towards the idea is so negative and childish? Nobody is going to waste time writing something that has an ongoing discussion (except @BenoitZugmeyer apparently), and a lot of negative feedback from the contributors because it will most likely be rejected in no time.
All I'm saying is that this issue has not been addressed professionally enough, and people obviously felt mocked.

[alexander-akait]

@Frondor I do not see anywhere a negative, the only thing worth mentioning here: some want this behavior by default, we reject this proposal (a lot of developers do not want this, other part want, better use option for this)

[coolemur]

@evilebottnawi I can't see anything bad with default as it is now and letting users optionally configure it.

And nobody can still give a decent reason why we shouldn't have this option.

There was a try to compare options to webpack configurations. But thats nonsense.

[alexander-akait]

To clarify - I'm not against the option

[sprlwrksAprilmintacpineda]

Same experience here. Currently, prettier is conflicting with eslint's rule space-before-function-paren.

"space-before-function-paren": ["error", {
  "anonymous": "always",
  "named": "always",
  "asyncArrow": "always"
}]

It would remove all those spaces, what I'm doing right now is just npm run eslint --fix which would put those back. I think it'll be better to default these spacing option in prettier as false, those who want to use it would have to enable it.

Let's face the fact that some eslint rules also deal with code formatting as well so unless we want to use one and not the other we should find a way to somehow give the users the option to turn off formatting options that might conflict with eslint. I don't even see any sensical reason not to give the users those options.

I'm not even sure what other formatting option prettier enforces that would conflict our eslint configurations. So I'll just copy-paste our eslintrc here:

{
  "parser": "babel-eslint",
  "parserOptions": {
    "ecmaVersion": 8,
    "sourceType": "module",
    "ecmaFeatures": {
      "classes": true,
      "experimentalObjectRestSpread": true,
      "jsx": true
    }
  },
  "extends": [
    "plugin:inferno/recommended",
    "inferno-app"
  ],
  "rules": {
    "prettier/prettier": "error",
    "no-throw-literal": 0,
    "default-case": 0,
    "jsx-a11y/anchor-is-valid": false,
    "no-duplicate-imports": ["error", {
      "includeExports": true
    }],
    "rest-spread-spacing": ["error", "never"],
    "semi": ["error", "always"],
    "quotes": ["error", "single"],
    "jsx-quotes": ["error", "prefer-double"],
    "prefer-spread": ["error"],
    "no-useless-call": ["error"],
    "no-trailing-spaces": ["error"],
    "space-before-blocks": ["error", "always"],
    "no-unused-vars": ["error"],
    "no-floating-decimal": ["error"],
    "comma-dangle": ["error", "never"],
    "array-bracket-spacing": ["error", "never"],
    "object-curly-spacing": ["error", "always"],
    "switch-colon-spacing": ["error", {
      "after": true,
      "before": false
    }],
    "space-unary-ops": ["error", {
      "words": true,
      "nonwords": false
    }],
    "space-before-function-paren": ["error", {
      "anonymous": "always",
      "named": "always",
      "asyncArrow": "always"
    }],
    "keyword-spacing": ["error", {
      "before": true,
      "after": true
    }],
    "key-spacing": ["error", {
      "singleLine": {
        "beforeColon": false,
        "afterColon": true,
        "mode": "strict"
      },
      "multiLine": {
        "beforeColon": false,
        "afterColon": true,
        "mode": "strict"
      }
    }],
    "generator-star-spacing": ["error", {
      "before": false,
      "after": true
    }],
    "no-debugger": "warn",
    "no-console": "warn",
    "no-alert": "warn"
  }
}

[sprlwrksAprilmintacpineda]

Or maybe, we could have prettier automatically detect eslint rules that would conflict to it's formatting options. If it finds any, it warns the user and tell them how to deal with it, maybe an option that would allow users to make SOME eslint rules take precedence over the conflicting prettier formatting options.

[lydell]

@sprlwrksAprilmintacpineda Using Prettier and ESLint at the same time without conflicts is already a solved problem – you are looking for this: https://prettier.io/docs/en/eslint.html and https://prettier.io/docs/en/related-projects.html#eslint-integrations

[sprlwrksAprilmintacpineda]

@lydell yeah, already done that. If I integrate eslint with prettier, prettier seems to ignore rules I set into my eslint. It would start complaining about space-before-function-paren.

[j-f1]

@sprlwrksAprilmintacpineda You probably need prettier-eslint then, which runs eslint --fix after Prettier. Also, if you install eslint-config-prettier, it provides eslint-config-prettier-check which will look through your ESLint config for any rules that could conflict with Prettier.

[RomainLanz]

Any news on this?

[phlogisticfugu]

I just spent a few hours drilling through error messages and issues to finally get here. This is a continuing issue for many people. In the Vue world, most of the out of the box configurations I use (nuxt, vue-cli) are associated with the standard eslint rules.

Could we perhaps update the prettier documentation at https://prettier.io/docs/en/eslint.html to mention something along the lines of:

"Compatibility Notes: Prettier is a highly opinionated formatter, and is known to have differences with the default settings of several popular eslint configurations including:"

https://github.com/standard/eslint-config-standard
https://github.com/vuejs/eslint-plugin-vue

... etc

and, if someone could please also document on that same page some steps one can take to resolve such issues. It's not entirely clear for someone who doesnt normally monkey about in eslint what does what on that page.

[tmorehouse]

It appears adding in an option to allow the space beween method name and opening parenthesis is gaining more plusses:

I definitely prefer having the space in there when defining methods (and no space when calling methods).

[avrelaun]

This and https://github.com/prettier/prettier/issues/3847 are the only things missing for relying on prettier alone for style on all our company projects...

[alexander-akait]

/cc @prettier/core What is your opinion now? Based on count :+1: and :-1: we should add new option here and move ahead.

[suchipi]

Indifferent, but I agree that if we add it it should be an option

[duailibe]

I don't think we should change it. I'm always 👎 for adding options.

[alexander-akait]

@duailibe not change, just add new option based on :+1: and :-1: , a lot of developers want this, i also don't love new option, but here it looks like holy war option.

[bakkot]

This is very far from being a holy war. Tabs vs spaces was a holy war. Semicolons was a holy war. This is not.

[lipis]

My vote is to change it and make a release with broken changes.. Having space is better and makes sense, and there is no need for adding new option!

[alexander-akait]

@lipis hm, for me space here is very ugly :smile:

[duailibe]

@evilebottnawi I don't think this is holy war.

I don't think this change justifies a new option. But that's me..

[alexander-akait]

/cc @vjeux we need your opinion here :smile:

[vjeux]

Looking at the top issues, the first two are about space after functions. If we're going to add a new option, this is the one we should add. I'm not against it given how many people seem to want it.

[stevefan1999-personal]

This 'feature'/misbehavior really irritate me on using TSLint, StandardStyle and Prettier.
It has been YEARS and people is still arguing about it. Just add it as an option that is disabled by default in a new config key called compat

[bakkot]

There will always be a top issue. If prettier adds an option for this, something else will be the top issue. I really think it is important to stick to the options philosophy and resist adding configuration, especially when there is an overwhelming de-facto standard in the ecosystem which matches what prettier currently does.

[aprilmintacpineda]

Here's what you can do guys:

npm run prettier --write && eslint --fix

Run in in that order and you get eslint to fix what prettier kind-of messed up. This is assuming you are using both.

[duailibe]

@aprilmintacpineda There's a tool that combines both: https://github.com/prettier/prettier-eslint you should check if it suits your requirements.

[avrelaun]

@aprilmintacpineda We already do that at Beekast, but this is definitely not optimal: Almost all our codebase files are rewritten by prettier on the filesystem then again by eslint. This is slow and painful for the storage.

In order to ditch eslint for style we can ignore pretty much all our eslint rules without much compromise except this for this one and #3847

Relying on eslint for errors only and prettier for style does makes sense for us.

[coolemur]

One year later.

👍 counter approves the change.

Prettier team still debates if they should or should not change it.
And they still looking for other reasons not to implement the option.

I just don't get it, why you keep this discussion open if you already have an opinionated decision for it. 👎

[lydell]

Unlike other issues with lots of :+1:, this one has lots of :-1: too.

[coolemur]

Unlike other issues with lots of 👍, this one has lots of 👎 too.

Thats just an excuse anyway.
👍 > 👎.

[gillesdemey]

Those that have voted 👎 would still be comfortable because the rule would be opt-in.

[josefaidt]

would you say the spread warrants an option addition rather than including it in the default spec without the ability to opt-out?

[coolemur]

would you say the spread warrants an option addition rather than including it in the default spec without the ability to opt-out?

Without option those who voted 👎 would have the same issue that those who voted 👍 have currently.

[duailibe]

I just don't get it, why you keep this discussion open if you already have an opinionated decision for it.

@coolemur Why does that bother you?

[mrmckeb]

I too don't understand the downvotes on this issue. It would be optionally, and clearly a lot of people prefer this format. If it was the other way around, those that are downvoting would be complaining I'm sure.

[lydell]

Yeah, the downvotes are a little ambiguous. There are several interpretations:

• I don’t want Prettier to change to this style and this style only.
• I don’t use this style and want to show that to get a more accurate picture of how common this style is.
• I don’t want this as an option to argue with colleagues on which value to choose.

[coolemur]

It's strange that downvotes is questionable now. It's quite clear that they are ambiguous.

The word "option" (that was mentioned by brianjorden on Feb 1, 2018 in second comment of this discussion) is self-explanatory. Option = it won't affect current users.

[karlhorky]

@coolemur not sure if you're trolling or not, but the third point from @lydell's comment quite clearly shows that this will affect current users:

• I don’t want this as an option to argue with colleagues on which value to choose.

This is one of the main benefits justifying the no-configuration philosophy. These discussions happen often in teams of all backgrounds. No option, no discussion.

[coolemur]

@karlhorky Not trolling. Just using some logic.

Contra question: do you argue about every option you have in development ? (Because there are plenty of them)

[karlhorky]

Not trolling. Just using some logic.

Ok, provocative, adversarial or inflammatory statements just look like trolling, especially if you don't address significant arguments brought up in the comment directly before yours.

To your question, given unlimited time, eventually in a project I question every option, yes. But that's not really the point - I am a single person.

Zero config tools have the greatest impact in teams, especially composed of people with diverse opinions. The team collectively decides for the decisions made by the tool and to be productive instead of spending time bikeshedding on options.

[coolemur]

@karlhorky

Where did you insight "provocative, adversarial or inflammatory statements" in my comment ?
It was only a notice that option shouldn't affect users by definition.

I don't see a problem in using prettier defaults and using custom options only when projects needs it.

[alexander-akait]

@coolemur first and last warning, otherwise you will be banned due in violation of the norms of communication

[coolemur]

@evilebottnawi Could you please give me a link to the norms of communication that you are referring ?

[alexander-akait]

@coolemur https://opensource.guide/code-of-conduct/

[coolemur]

@evilebottnawi Based on https://opensource.guide/code-of-conduct/ "Give the person in question a public warning". Could you please explain how my behavior negatively impacted others and which sentence in my comments is inappropriate ?

[alexander-akait]

@coolemur stop this behavior and if you want this option just send a PR (https://github.com/prettier/prettier/issues/3845#issuecomment-456269173), you messages marked as off-topic

[coolemur]

@evilebottnawi I am politely asking you to explain what did I say wrong.

[nijikokun]

@coolemur ignore them. Waste of time, politics. They rather write comments debating obvious desire and worry over futures that might happen than code at this point.

You are treated as such because you are right but not the right they seek.

Further discussion is pointless all that can be said has been said. The communities answer is there clear as day, positive upvotes.

Controversial only because of the way it’s discussed and handled.

See, they treat this the same way even though it’s very much, on topic. Not the answer they desire which is, no do not implement.

[azz]

Further discussion is pointless all that can be said has been said.

https://github.com/prettier/prettier/issues/3845#issuecomment-456269173

PRs welcome.

[gillesdemey]

Hey folks, I'm working on a PR that would add a spaceBeforeFunctionParen option so it's time to figure out what color to paint the shed! :)

This option is tangential to #3847, should we consider that a separate configurable option or should we have different string values for the spaceBeforeFunctionParen option such as 'always' | 'never' | 'noAnonymous' | 'onlyAnonymous'?

Another alternative is to simply have one spaceBeforeFunctionParen option that applies to both anonymous, regular, and arrow functions — this is the behaviour I have on my local branch.

Thoughts?

[bakkot]

I want to continue to express disagreement with the idea of adding this option as strongly as I possibly can.

Options are bad, and this is not a question on which the community as a whole is especially divided. (Since I wrote that comment, a third of the major projects I was able to find which used the style requested here have since switched to prettier's style!)

There is a loud minority of people for whom this is not their preferred style, and those are _of course_ the people who are the most active in this issue thread. But prettier's whole value-add for a lot of people is that it allows them not to worry about options. Those people aren't going to come across this thread. This is a much less divisive issue than bracket spacing, and the bracket spacing option is specifically called out in Prettier's docs as the sort of option which we should avoid. I don't understand how adding this option is at all in keeping with Prettier's stated philosophy.

I don't know if my "collaborator" hat gives my voice any more weight (or my "18th largest contributor" hat, ha). I don't really think these things _should_ give my voice more weight; I would prefer people judge these arguments on the merits. But this comment was about as strong of an argument as I can imagine there being against adding any particular option, and it seems to have been mostly ignored in the considerations, so now I don't know what else I can do.

@vjeux, _please_ reconsider. Or, failing that, at least delete the option philosophy part of the docs, as it will at this point be pretty much pointless.

[aprilmintacpineda]

There's really no point discussing this. You can simply run prettier and then run eslint.

[avrelaun]

@aprilmintacpineda Except that's terribly inefficient as it has to rewrite almost all files, and takes 3x the time of executing prettier alone. As I said before, relying on eslint for errors and prettier for style does makes sense IMHO, and this issue concerns style not errors.

While I agree that prettier should not add too much options, this one and #3847 would be our only exceptions. In our large codebase we found 7 prettier rules conflicting with our eslint config. We dropped 6 of them without feeling regressions in terms of code readability. The space between function name and anonymous function to separate declaration and invocation is the only issue remaining and we consider it major enough to hold on relying on prettier alone for style.

[aprilmintacpineda]

Yes that may be true, but if we want integration between the two, then that's the only option. Another option is to fork the repo (which I am not willing to do).

[mrmckeb]

I'm now using Prettier+ESLint and it's not so bad, but I would prefer to have this in Prettier - as I think it's an important style choice. However, we also have to accept that this is not a democracy and Prettier's goal is creating a standard that stops arguments in teams.

It confuses me why people are strongly against this, unless they're against the choice due to fears of arguments within their team about what's the right style? But that's why teams have leaders.

[jekrb]

Hey all, just want to voice my perspective. Prettier is becoming a more and more popular way to improve developer experience, but without this option, Prettier also conflicts with a common and valid style, which I don't think should be dismissed.

I know you can run formatting tools _after_ running Prettier, but that's adding more moving parts to a project, which I think counteracts the DX a bit. I think it would be easier for me to go all in on Prettier if it supported styles of writing JS where there is a space after function name.

That said, I know open source is hard and often thankless. Prettier is great and I appreciate your time on it!

[thevirajshelke]

Is there any way to enable or disable this feature in the prettier config file?
Something like this would help us a lot:-

{
    space-before-function-paren: true
}

The advantage of giving this facility is that we will be able to use standardJS.
StandardJS follows single-quote prettier follows double-quotes but then this is configurable in prettier config file! So something similar for space-before-function-paren will help a lot to use both Prettier and StandardJS together!

[lydell]

@thevirajshelke We recommend turning all linter rules that conflicts with Prettier off. It’s possible to use standard’s helpful code quality rules together with Prettier via https://github.com/prettier/eslint-config-prettier.

[thevirajshelke]

@lydell I wanted to use standardJS rules strictly.
But then I wanted to use prettier to format my code.

But since we are not able to customize this space-before-function-paren it's creating an issue. So as of now instead of turning rules off for linter, I have used prettier ignore config file and I am ignoring all js files by using *.js. So the Javascript files are formatted using StandardJS default formatter and rest is taken care of by prettier.

Thanks for the help.

[lydell]

I wanted to use standardJS rules strictly.

Then you shouldn't use Prettier. The two projects use slightly different code style.

[josefaidt]

I think it's important to understand is Prettier's ultimate purpose to be a code formatter, or a specific code style (like Standard.js, AirBnB, etc)?

[bakkot]

"Prettier is an opinionated code formatter."

[j-f1]

So the answer is “kinda both.”

[thevirajshelke]

I wanted to use standardJS rules strictly.

Then you shouldn't use Prettier. The two projects use slightly different code style.

Yeah, I understood this. So now I am ignoring all the JS files & other files like (HTML, CSS, etc.) are being formatted by Prettier. I don't want to discard Prettier completely because I liked the project :)
You guys are doing a good job :+1: My best wishes :)

[FredericLatour]

I had no idea before getting frustrated with Nuxt/vue and prettier formatting option and reading this discussion that Prettier was not a tool only but was also advocating a specific style.

I don't understand why Vue is still proposing Prettier support in the tooling configuration chain while Prettier is not able to comply with their own formatting/linting rules. From this discussion I get that Prettier is promoting a style guide that is in incompatible with Vue own style guide. Considering the strong opinion of Prettier devs on this matter, Prettier support should be removed completely (nothing would prevent to use it by installing the necessary parts though). It would clarify things up and will prevent people from wasting time.

On a more general standpoint, I would be all for some kind of formatting standard from a committee for javascript / typescript but in the absence of such a standard, I would rather follow framework's style guide rather than Prettier style guide. That's a practical matter besides any strong preference which I don't really have.

Of course, Prettier maintainers can do whatever they want but it sounds somewhat counter productive. Prettier devs should differentiate the 'style guide" they are promoting (Prettier Standard) and the tool itself. If prettier is supposed to be a tool dedicated to a specific Standard (Prettier's one) why not removing all configuration options altogether ? Either it's too flexible or not enough.

Time to find a more agnostic tool I guess.

[lydell]

@FredericLatour I think you should talk to the Vue maintainers about removing Prettier from their tooling. Mentioning it here won't help.

See also our option philosophy – I think it should answer most of your questions.

[FredericLatour]

@lydell I mentioned it here because I wanted to expose my point of view and possibly being pointed out something I'm missing. Seems like you are implicitly admitting that it does not make sense that Vue offers Prettier as a configuration option when it conflicts with it's recommended settings/ (which are configured by default by the way), unless they change their style guide. There's no use in making people frustrating looking around and ending in being even more frustrated. I will therefore open an issue on vue's github.

Indeed, your option philosophy is clear enough. That said, I would make two comments:

1. Many people are adopting prettier because it's configured or available in the configuration options of their framework. They just don't really care about the details. I don't mean to be provocative but there are already so many things to take care that going into the details of the tool or plugin that is supposed to formal the code properly is not really high priority. It is therefore easy to miss that Prettier is more of a "style guide" (supported by a tool) than a generic tool.
2. Your reasoning on this philosophy page makes sense. However, when a framework with 146 000 stars have a somewhat inconsistent approach by promoting Prettier to some extent and adopting an incompatible style guideline, you could possibly get in touch with them to clarify things up.

[lydell]

@FredericLatour Could you please link to the vue issue you opened when you've done so? I think it could be of interest to others following this thread.

[FredericLatour]

@lydell I have to do a bit of homework here because the problems I faced are on Nuxt.js (which is based on Vue.js). Most probably, I will encounter the same problem (I can read many people are complaining about inconsistency between prettier and vue rules) with Vue.js but I have to check first by creating a simple project.
That being said, I did some research and it doesn't seem to really exist a formatting tool like Prettier (especially when editor integration is concerned) that can take care of most languages used in the web development area. Every alternative seems to be lacking in a way or another.

Because, I doubt that people will get to accept one formatting standard, there is a real need for an agnostic formatting tool à la Prettier (that works nicely with editors) so that people can apply either Prettier, Standard or Airbnb style (hopefully the list won't expand). And honestly, the difference is so tiny between those standards that it won't really miss the goal of having a consistent code base that feels familiar.

With such a tool, you'll end up with with Agnostic Prettier, and ESlint, Rules Plugins and you are done. Instead of the current messy situation where people are trying to make things work all together with mixed success.

On a personal standpoint, both Prettier and Standard style guide are fine. I may have some aesthetic preferences on some specific point, however, I'm more than ready to adopt another rule for consistency.

On another note, when possible important changes are concerned, I find the "+1" approach quite limited. Having 200 (+1) versus 30 000 stars !!
You should opt-in people that are willing to vote when important matters are concerned and then send them a request for voting when necessary. You may not decide to follow the vote but at least you would have a more representative situation.

[lydell]

@FredericLatour Sorry, I tl;dr-ed on your comment. Let me know if there was something you wanted me to respond to.

[FredericLatour]

@lydell no tx (short enough?)

[glen-84]

Hey folks, I'm working on a PR that would add a spaceBeforeFunctionParen option so it's time to figure out what color to paint the shed! :)

_If_ an option is added, it should be named similar to spaceAfterFunctionName, and not spaceBeforeFunctionParen, as the latter would conflict with the topic of #3847.

[SashaSirotkin]

A bit late to the party here. I just saw always add a space after the function keyword item in the changelog for the 2.0.0 release and my first reaction was "huh, that's weird". The function space change was a significant unconventional styling change and there was no explanation of its utility in the blog post. Decided to rummage through the repo issues to get more context.

Most other decisions that Prettier makes seem to represent the most wildly accepted practice at the time. However, the changes regarding function name () (and function ()) seem to be contradictory to that which is highlighted by this comment by @brianjorden.

As Prettier gains more adoption and becomes defacto code formatter it steadily gains a kingmaker position for the what is "the most widely accepted practice". That is a lot of responsibility! Prettier is an opinionated code formatter and it would be too much to explain every decision, but up to this point the opinions haven't been surprising (even the ones I disagree with). Now, it looks like that is beginning to change and this puts a larger responsibility to explain their decisions in a more publicly consumable format than 100+ comment github issues.

~Finally, the following statement by @bakkot gave me significant pause:~

~There is a loud minority of people for whom this is not their preferred style, and those are of course the people who are the most active in this issue thread.~

~As it considers the current common coding convention to be the loud minority when in fact it is the silent majority given the current state of the internet per @brianjorden's comment.~

EDIT: I shouldn't scan the thread at 3am! Sorry @bakkot!

TL;DR: As Prettier becomes the defacto code formatting standard it will transition from "this is a curated set of formatting best practices" to _being_ the best practice. This puts more of an educational responsibility on the maintainers to explain and justify decisions in a more curated way than just github issues (i.e. on the website blog). Otherwise it can reduce trust in the project.

[bakkot]

@SashaSirotkin

However, the changes regarding function name ()

I'm not sure what changes you're referring to. Prettier has not changed the style it uses for named functions.

Finally, the following statement by @bakkot gave me significant pause:

There is a loud minority of people for whom this is not their preferred style, and those are of course the people who are the most active in this issue thread.

As it considers the _current common coding convention_ to be the loud minority when in fact it is the silent majority given the current state of the internet per @brianjorden's comment.

Did you see my survey of the styles used in major JavaScript projects above? I feel it rather firmly justifies my belief that the style asked for in this issue is not in the majority, silent or otherwise. If you disagree, on what grounds?

---

But I think we might be talking past each other, since the focus of this issue is the formatting of _named_ functions, which has not changed. It was only the style for _anonymous_ functions (https://github.com/prettier/prettier/issues/3847) which changed (from function() to function ()).

[SashaSirotkin]

@bakkot Sorry! I misread your statement! I will update my post accordingly.

[franleplant]

Im really glad I dont have to have these discussions inside my company or
projects anymore, thank you prettier for existing ando sorry to fill your
issues with bikesheding

On Sat, 28 Mar 2020 at 03:55 Sasha Sirotkin [e-mail]
wrote:

@bakkot https://github.com/bakkot Sorry! I misread your statement! I
will update my post accordingly.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/prettier/prettier/issues/3845#issuecomment-605405720,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOEIJ7UCYIMLYWP5XPTDCTRJWNN7ANCNFSM4EONSNXQ
.

[thorn0]

It's clear by now this isn't going to change.