Resist adding configuration about prettier

[gaearon]

The thing is, I don’t even care about “most common” here as much. I’m fine with @jlongster making common sense decisions as long as it’s something consistent and as bug-free as possible. These style differences don’t really matter, people care way too much about them.

[nzakas]

@jlongster Creator of ESLint, here. First, I just wanted to say that I think this is a really cool project and I'm interested to see where it goes in the future. I never intended ESLint to be a source code formatter, it really was just meant for flagging problems and then later, if possible, fixing them to the best of our ability. Along the way we got requests for fixing some of the simple formatting problems, but there's no way we will ever be able to match a tool that holistic knowledge of style preferences and can format appropriately. As such, I'd like to welcome you into the JS tooling ecosystem.

If there's one thing I've learned in the over three years I've been working on ESLint, the devil is the configuration details. As @gaearon mentioned, you will undoubtedly be met with a large number of requests for additional configuration options. These requests represent the majority of ESLint issues, where everyone wants an exception for their particular use case. As ESLint was designed from the start to be unopinionated, we have a harder time deciding what is important enough to include and what is not (though plugins and custom rules help with this a bit). As prettier is intended to be opinionated, I hope you'll not be swallowed into that hole, as well, and would echo the call to resist over-configuration.

I'd also strongly encourage you to avoid trying to read ESLint configuration. Our configuration system is fairly complex (on account of cascading and inheritance), and we don't have a good way to share that outside of ESLint. Also, rules and rule settings change, and you'd be left in a never-ending race to try to sync up.

That said, the ESLint team has discussed in the past creating a generic style guide format that wasn't directly tied to individual rules (we even thought about using editorconfig for this). That's something we'd be happy to collaborate on in the future to make it easier for people to share tools. (Although, I can completely see people just using prettier for formatting and turning off all style rules in ESLint.)

In any event, I just wanted to reach out to let you know that we're happy to be a resource for you as you get this project up and running. Between the ESLint and JSCS teams, we have a lot of experience in this area, so feel free to reach out any time.

[jlongster]

@gaearon I totally agree. Thanks for opening this issue because we need to discuss here what the real goal of the project is (and put it in the readme). I see three different goals:

1. Converge on generally a single style (with very few basic options to help align with existing projects, like single/double quotes)
2. Cater to a few large demographics (support tabs or spaces, semi or no-semis)
3. Make it completely configurable/pluggable, possibly reading in eslint config and trying to adhere to that

I definitely don't want to do #3. There's just too much complexity already in making sure everything is consistent and I guarantee I will burn out (probably others too) if we attempt that and this project won't work.

I'm not sure about #2. The two most divisive issues in JS are tabs/spaces and semis/no-semis. There are already issues about them: #12 #34. I'm tempted to try to support those two options as a way to bring everyone together. Heck, if you wanted to turn on semis or switch to tabs it's a simple config switch. And like you, I just don't really care anymore which ones people use.

As I noted in the issues though, there are real problems trying to support those styles. Trying to emit semicolon-less JS means we need to detect where we have to emit a semicolon to avoid collapsing code where it shouldn't. Things like that.

When it comes to how function calls, object expression, etc are formatted, yes, I don't think we are going to change anything from how it already is. I'm not going to sit around and argue about specific styles. I'll change something if the majority of the community is asking for it, but otherwise, people don't need to worry so much about the minutiae of syntax.

For the time being, I think we should focus on #1. I'd love any advice for the tabs/spaces & semicolons issues though. I don't think we should do it until this project is clearly succeeding and a large group of people feel like they're missing out. My preference is to let projects evolve slowly so I'll resist until we feel it's right to make those decisions.

[gaelollivier]

@gaearon Agree that style differences don't really matter and any crazy style that has auto-format support is better than one without.

However, for a project that is about formatting I think style questions should be taken seriously. If it's about defining a "standard" that would be used by many people, would be better to chose one that looks nice (to as many people as possible) :)

[natew]

Well, to speak for the commons, I'll throw in my 2c.

First, thank you very much for this project, it's exactly what we should be working on, well done, and will be extraordinarily useful for devs everywhere.

My vote is for at least implementing #2, and generally for making it as configurable as is tolerable for maintainers.

Why? Well, simply this: we are all different, and have different use cases. The more configurable it is (towards real-world desires, see issues + reactions for a good guage), the more helpful it is.

Second: the whole point of formatting is to allow people to have their code look how they want. If you make it look how you want, then you're not really serving the purposes of a community formatter very well, you're serving the purpose of the loudest/most well known/your desired formatter.

To me, luckily, this is not a big issue. We have a great system for tracking desires, we can debate them as they come up.

I also appreciate @gaearon for opening this, because it's good to know that some people desire to limit configurability. I can see one upside for that use case: the global look of JS becomes more similar. But, to me, that is not big enough to warrant subjugating the desires of every user to potentially help beginners, perhaps, though I doubt semis/no-semis and other similar ones make a big difference. Plus, if we're allowing line-length and other config, it's already making decisions on configurability, so drawing lines autocratically seems like a pretty unfriendly decision.

Finally: I hope that we can standardize on a lot of them, avoiding a lot of work for maintainers, & this is a very legit concern to balance.

Sincerely,
Someone who really hates semis 😛

Best of luck!

[munificent]

There is a very pragmatic concern around configuration: if you support, say 10 boolean config flags, then your test suite needs to be 2^10 bigger to cover all of the cases where those configurations interact. And they will, absolutely, interact, in nasty subtle ways.

Even when the formatter isn't configurable at all, there is already a long bug tail just with how different language features interact in the formatter.

Whether it's better for users or not (I personally lean on the side of not), configurability is a nightmare for the maintainer of the formatter itself.

[dangoor]

Golang got around this question entirely by shipping gofmt early on. In JavaScript-land, we've got a long history now of people doing a wide variety of things.

Not implementing options for spaces/tabs and semis/no semis is a good thing to pushing toward a consistent standard across JS projects. The downside is that leaving those options out could hinder adoption among people who feel strongly about the opposing choices and open the door for a fork.

If I was leading this project: I would leave the options out and see where it goes, attempting to achieve for JS what gofmt brings to golang. JS isn't golang, so it's possible that's not the right choice for JavaScript, but I feel like there's little benefit to arguments over styling.

[gilbox]

Pedants of the world fear that a student of economics will, in the course of his due studies, search Google for "a prettier and perfect example of tragedy of the commons" and happen across this post. Unfortunately, there is nothing perfect about this example. For such a common tragedy should involve some shared, limited resource. But what is the resource in this case? Time? Configuration? Code? No, dear student, look elsewhere for your pretty perfect examples. And besides, adding the phrase prettier to your search engine query was pretty silly to begin with--don't you think, pretty boy?

[gaearon]

But what is the resource in this case? Time? Configuration? Code?

Maintainers’ time and energy. That’s what runs open source projects, not code.
Increasing bug surface area through configuration burns maintainers’ time and energy.

Ask any maintainer with the experience of adding configuration options.
I think #40 (comment) is a good explanation of this, too.

[matthewp]

@swansontec People who argue "you shouldn't have an opinion on style" are always the people who themselves have an opinion on style.

Opinionated tools are great and I agree with the less configuration the better. Choose the style you like for your own tool. Just don't try and pretend like you're really doing everyone else a favor by making their decisions for them.

[sapegin]

If we as a community could find the most common JavaScript code style, I’d try to adopt it in my projects. I see a lot of benefits in that for me as a maintainer and for contributors of my projects.

[msegado]

Re. "we should all just pick something and go with it": I respect what standard.js did here, but one problem I see is that the "something" picked wasn't (to the best of my knowledge) the "something" already in use by any major JS projects like jQuery, Node, lodash, etc. If unifying the community around a common style is truly an important goal, I think it's worth trying to garner consensus among maintainers of the biggest/most-popular JS projects before setting anything in stone. The idea would be for several major players to agree on a reasonable solution which they would be willing to adopt in their own projects for the benefit of the community... it might be that such a consensus is only possible with a few flags for things like tabs/spaces and semi/no-semi, but given the experience that such maintainers have with large software projects, I expect they would be some of the most qualified people out there to find a reasonable compromise between flexibility/configurability and testability/maintainability.

tl;dr: if we want a standardized community style, i think we need to involve maintainers of existing large projects, both to gain critical mass and to make better-informed decisions.

[bernharduw]

My 2ct: Embrace forking instead of adding configuration. It keeps this repo and maintaining the tests much simpler, and Github stars or npm installs are a much better way to track the popularity of a styling preference. Once you throw in a config option, you'll basically have to maintain it forever – even if only a single user needs it (and you wouldn't even know).

At least from a user's perspective, this works very well for the standard package. Over time a small ecosystem of forks has evolved (semistandard, uber-standard, happiness etc.). Instead of having to configure a do-it-all-standard package, it's much easier to just npm install semistandard if you prefer. Numerous times I considered forking semistandard to throw in dangling-commas, but the pain of maintaining my own fork outweighed the benefits of using my preferred style.

If someone feels the strong urge to use no-semicolons-style, they are free to create a prettiest fork. If anyone prefers tabs, please fork to a pretty-tabs repo. We'll see which forks gain significantly more traction over others. And maybe eventually it might also make sense to create a common, unopinionated pretty-basic module which all the forks will share - who knows? ;-)

So: no configuration, but happy coexistence of forks.

[sapegin]

The only reason for the most common style is to make less people adapt to a new one ;-)

[jlongster]

How about making the AST rewriting pluggable, much like Babel makes AST parsing pluggable?

I've seen a large desire for zero config tools that just work without having to think about it. My goal is to build a tool for those people. If someone wants to take pp.js which is the core printer algorithm and write another highly-configurable/pluggable printer, feel free to! That's not the goal of this project.

Another way to put the goal: encourage people to forgo their specific stylistic concerns about code. Ever since I started using this, even if I don't love how it formats every single line of code, I just don't have to care anymore. Heck, I can write code however I want it and just format with a single keystroke. This freedom actually allows you to write it however you want; but forces a consistent readable style that looks fine too.

On a practical note it means that it’s okay to add configuration that doesn’t cause exponential growth of bug surface area

That's generally how I'm thinking about it. There are 3-5 high impact options that require only a few tweaks in the code, and I'm fine making that configurable. I don't want more than ~5 options. Any new option we add must be a tweak of an existing option (making bracketSpacing take 2 values instead of boolean) or must replace an existing option.

@munificent That's a good point about string. Right now we do convert strings and escape them if necessary... I think the win of consistent quotes is good enough, and it wasn't too hard. But totally agree that there shouldn't be more config. (I loved your article on dartfmt btw)

Closing this issue as the goal has been clarified. Thanks all for the discussion and the viewpoints. I will update the readme to reflect the goals soon.

[robertknight]

I can see only one upside for that use case: the global look of JS becomes more similar.

Speaking from what I've seen of the Elm, Go, Rust and Python communities, where style is highly standardized, this is a big upside and a desirable outcome. It means that when reading someone else's code you can focus on the more important higher level aspects and not get distracted by unimportant differences.

There are I think significant social benefits as well - it eliminates a source of confusion for beginners (how do I format this to align with this project's conventions?), a source of tension for new contributors to a project (your PR is fine but it doesn't matching the coding style conventions of this project) and it general it gives the whole community a more cohesive feel.

[jlongster]

@natew I empathize with your point at well. I don't think we need to do everything at once. If we try to do too much, there's a real chance this project will die, so all of our efforts are nullified. Right now I want to constrain the scope to make sure we make this robust, and we can go from there.

[swansontec]

I would like to point out the standard.js project, which provides a style guide and a no-configuration linter. Their idea exactly mirrors this thread - we should all just pick something and go with it, even if some people get annoyed. The benefits of tabs vs. spaces or whatever just aren't worth the bike-shedding and general confusion.

Of course, this attitude does no good if all the opinionated tools disagree. Prettier is pretty close to the standard.js style already, and wouldn't take too much work to become 100% compatible. At 10k daily downloads on NPM, standard already has a lot of users who are ready for no-bikeshed, just-works style tools. From testing on my own codebase, which uses standard already, I see the following differences with prettier:

• no semicolons
• indent case statements
• space after function keyword (annoys me too, but hey, standard!)

Single quotes are already supported, but as an non-default option, so that's OK.

[munificent]

A good example is string quotes. It’s fine for them to be configurable because they are unlikely to clash with other options and cause bugs.

Well...

If you normalize all strings to use a single quote style, then you may need to add escapes to some existing strings. Normalizing to double quotes means you need to turn '"' into "\"". That in turn affects the length of the string, which impacts other formatting.

If you're going to do that, does that mean you normalize other escapes as well?

So, off the top of my head, I can imagine configurations for:

• Don't touch my string literals.
• Normalize all string literals to '.
• Normalize all to ".
• Normalize all to ' unless it contains ' in the string.
• Normalize all to " unless it contains " in the string.
• Normalize all to ' unless it contains ' in the string and it isn't already escaped.
• Normalize all to " unless it contains " in the string and it isn't already escaped.
• Normalize to the representation that requires the fewest escapes, with ' as the preferred default.
• Normalize to the representation that requires the fewest escapes, with " as the preferred default.
• Normalize to the representation that requires the fewest escapes, with the original delimiter as the preferred default.

I could go on...

[matb33]

Allowing configuration is a tough call at this stage because this tool today offers two things: a better formatter (parsing into an AST) and an enforced style. I believe many users seeing this project are more interested in the benefits that the parser brings than the enforced style, since we all bring our style baggage with us.

So what it comes down to is to clearly identify what this project is. Is it primarily a great parser with configuration to allow other styles, or is it a specific style with a great parser?

It sounds like it's the latter. I think it's the correct choice to start. Bang out the bugs and edge cases. Someone else can always stand on this project's shoulders and build the former.

[gaearon]

On a practical note it means that it’s okay to add configuration that doesn’t cause exponential growth of bug surface area. A good example is string quotes. It’s fine for them to be configurable because they are unlikely to clash with other options and cause bugs. On the contrary, making semicolons configurable has a vast impact on all other cases.

[jlongster]

Hey @nzakas, thanks for the kind comment! First I want to say that I hope I never came off as disrespectful towards eslint. I wrote my post and readme to focus on a specific problem that I've seen in teams, but nothing that is the fault of eslint. Since this project has taken off and I want to be a good citizen of the ecosystem, I plan on updating the readme to not call out eslint specifically to make sure it doesn't look like we're bashing it.

I can definitely see how eslint evolved that way. A pluggable system like that is incredibly hard to build and maintain since you're scope is broad, but the advantage is that it's flexible and serves hugely diverse set of needs. Kudos to that!

I really like the rules that enforce certain semantic characteristics, and having time to think about it more, I'd like to talk more about how we can make it easy to integrate prettier and eslint. I think this could solve the semicolon debate, too: if I can generate code with semicolons and pass it through eslint's fix process with the "no semicolon" rule on, people who really don't want semicolons could set that up. That allows this project to be focused and opinionated but leverage eslint's flexible toolchain.

Of course, the main use case for integrating would be to use eslint's other rules for semantic checks. It makes no sense for us to reinvent that (nor am I interested in it).

Is there a place we can talk about integration? It's easy in theory, but the devil's in the details, and I'm particularly concerned about performance because a naive prettier foo.js | eslint --stdin probably parses the source twice.

I'd also strongly encourage you to avoid trying to read ESLint configuration.

Thanks, that helps clarify a lot. I had a hunch that it would be difficult, and someone else can create another project that attempts this and passes in the detected options to us if they want. I don't plan on doing this.

That said, the ESLint team has discussed in the past creating a generic style guide format that wasn't directly tied to individual rules

Sounds neat! As you said afterwards, I'm not sure how that would tie into this yet, unless there are a few tweaks we could make to all be on the same page. I'm definitely open to talking about it (not just me, but many other people that are getting involved too, I don't have any interest in deciding these rules for other people, I'm seeking the majority).

In any event, I just wanted to reach out to let you know that we're happy to be a resource for you as you get this project up and running. Between the ESLint and JSCS teams, we have a lot of experience in this area, so feel free to reach out any time.

Thanks! Much respect and love to you all. I look forward to collaborating!

[kentcdodds]

Love what's being said here. In an effort to help, I created prettier-eslint: Formats your JavaScript using [prettier][prettier] followed by [eslint --fix][eslint]. It's basically: code | prettier | eslint --fix (via the node APIs). So there's AST re-parsing going on and stuff. Could definitely improve things. But I think this is a good start :)

And there's an atom package (which needs a little work).

I could use some help on it!

[wmertens]

How about making the AST rewriting pluggable, much like Babel makes AST parsing pluggable? You can ship a default config much like babel-preset-latest that does what prettier does by default, and people can go crazy inventing good rewrites that are too specific for general use, like enforcing camelcase.

I mean, there is a bunch of machinery required for doing the rewriting, and it is great if there is only one place to go to maintain all that, but for individual rules there is just too much variation to make a set of configuration options that will even only please 80%.

Also, this is exactly what Redux does :). Its simple and elegant API allows very powerful configuration.

I'm not really adding much to the discussion when I say this, but I love this project because it already matches my style of coding almost exactly, and it seems like a great way to get some junior devs I'm training on the same page as well. I agree 100% with the lack of support for configuration. The more people throughout the JS community on the same page, the better, I think.

[ITenthusiasm]

TL;DR

I think some (few) options should be considered in the context of visual overload.

---

@j-f1 A million and one thanks for applying keep-unlocked! I was looking for somewhere to talk without opening a type of issue that's explicitly discouraged.

Using a quick ctrl + f word search in Chrome, eyes, eye, and visual never appear (I didn't expand Hidden Items). Searching for read yields 20 results, but in all of the results, it appears as part of a larger word. In only 2 of those 20 results does the word have anything to do with reading. (In fact, both results are reading.) But neither of those results have anything to do with how easy it is to read code. For fun, cognitive never appears once. And load and mind never appear as individual words that are part of the conversation.

I imagine it's obvious where I'm going... I can generally respect the decision to refuse to add more options moving forward from what I've read. There are things that are minuscule that really shouldn't be a point of contention. However, my concern throughout this entire discussion is whether or not Prettier is considering the potential unintended side-effects on visual overload or cognitive load.

I'm asking this question in the context of #840. In general, I think Prettier itself considers this in certain situations... like printWidth. There's a lot of cognitive load that comes with repeatedly scrolling left and right to read code. And UI/UX folks have discovered that people respond much more negatively to horizontal scrolling. It's great if Prettier helps people write code that helps avoid cognitive load. If it stays hands off, that's also fine. But once it unchangeably enforces a rule that potentially adds cognitive load, there's a problem.

---

So... my question becomes... is the team considering cognitive load? (I'm sure they are to some extent if printWidth exists.) And would that help them reconsider certain options? (It could be difficult to identify those options.) I understand if a no is a no; but please consider the following:

From jlongster's comment and jefffriesen comment, semicolons, quotes, and spaces-vs-tabs seem to be examples of major points of contention. Semicolons might have their place (the brain being able to explicitly see where a statement is finished). But quotes and spaces-vs-tabs don't really have a significant impact on the eyes; they are primarily preference-based. One extra ' won't really add overload. Whether spaces or tabs are used, proper indentation is what spares visual overload, not so much the method. So if, in another world, those 2 options weren't available, it wouldn't be a huge deal.

Cluttered lines are an entirely different story, though. And they can cause visual overload. But Prettier can't [and shouldn't] make enforcements here because user cognitive overload is unpredictable. For instance, a collection of related variable declarations without any in-between spaces may help the brain separate and group together related blocks of code. In another circumstance, spaces might make more sense. All prettier can do (and does) is prevent the other problem of having too much in-between space -- which is easier to justify.

In the context of conditionals, Prettier forces

if (condition1) {
  // Do stuff
} else if (condition2) {
  // Do different stuff
} else {
  // Fallback stuff
}

This isn't a big deal if the condition is not complex. But if the condition is complex enough to extend a large width without causing a line break, and/or the final line in the previous block is long enough to do the same, then the eyes may start to have a harder time.

if (smallCondition) {
  // This time my last statement may extend like 40-70 chars
} else if (firstCondition && this_is_a_slightly_complex_condition) {
  // Oh boy. Is it time for another long statement
} else if (this_is_a_single_condition_but_still_kinda_large) {
  // At least my last line is small
} else {
  // Fallback stuff
}

If I'm trying to quickly scan the code, learn new code, or remember old code, this becomes a visual burden for me. I've felt it when developing locally. I've typically gotten around it by doing switch/case, where Prettier can't interfere with line breaks. Avoiding if/else by using return statements also helps. But not all conditional situations can be reduced to such structures. And in these cases it still bites. Comments don't help the problem. If your code is sufficiently self documenting, then comments are redundant at best and add additional visual overload at worst.

if (smallCondition) {
  // This time my last statement may extend like 40-70 chars
}
// The firstCondition && this_is_a_slightly_complex_condition yay more overload
else if (firstCondition && this_is_a_slightly_complex_condition) {
  // Oh boy. Is it time for another long statement
}
// This does that for this_is_a_single_condition_but_still_kinda_large yay more overload
else if (this_is_a_single_condition_but_still_kinda_large) {
  // At least my last line is small
}
// Redundant fallback statement
else {
  // Fallback stuff
}

Redundant comments are a problem because they suggest to the developer that something unapparent in the code needs to be given attention. But if it is redundant, the developer then has to train their brain to ignore the additional distracting text.

One can try to argue about optimizing if/else statements. But the reality is that sufficiently long final-lines or conditions are a real possibility. And honestly, the upcoming conditional and the last line of the preceding block don't even need to be long to be distracting. They can be sufficiently small, but still be distracting because they're approximately the same length. This is avoided by letting people add a newline:

if (smallCondition) {
  // This time my last statement may extend like 40-70 chars
}
else if (firstCondition && this_is_a_slightly_complex_condition) {
  // Oh boy. Is it time for another long statement
}
else if (this_is_a_single_condition_but_still_kinda_large) {
  // At least my last line is small
}
else {
  // Fallback stuff
}

This is why I think breaks before else would be a great option to add. The issue is not merely a preference issue. And I'm willing to bet that several people in #840 who were saying newlines are better are probably experiencing a similar problem. But because cognitive load can be subconscious, many of them probably just recalled the feeling they get when they see "ugly-formatted-code" and just left a basic complaint.

As a reminder, I'm talking visual overload. Not "That irks/annoys me" overload. The former is not something so easy to "get over" or control.

I know that was a lot, but I wanted to make a sufficient case. The code blocks added length too. Thoughts? I really hope the answer is an "okay". If the answer is no, that's fine. I'd just hope for a sufficient set of reasons on the topic of visual overload. And I hope it's at least obvious that something like this is significantly more impactful visually / mentally compared to many other options that can more easily be reduced to mere preference like tabs, quotes, jsx-quotes, trailing-comma, etc.

[SephReed]

For anyone who believes in science, I'd like point out that the level of consensus in this thread is very likely contextual. People who don't like opinionated tools aren't likely to spend more than a few minutes looking at prettier... unless, there's no other options.

On that note, I've been searching around for a non-opinionated code formatter. Does anyone have any recommendations?

[gsklee]

Hi @jlongster, just would like to chime in and let you know that your project has hit the jackpot and solved something that even (the self-proclaimed) Standard and Semi-Standard couldn't solve for me:

Easy team-wide style enforcement that's based on an unbiased 3rd party algorithm to produce a one and only definitive way to indent absolutely each line of code

Such a great feat! Please stick to it no matter how hard someone tries to lobby you into doing something that's against this value. Oh, and no, you don't need to "serve for the purposes of the community" - that's exactly how mobs killed the passion of the Babel team. Just stick to your gut feeling! 😉

[jefffriesen]

Having a single standard helps with PRs on open-source projects. It's easier for a maintainer to specify the style to be prettier than prettier with a list of option settings.

I am very opinionated about semicolons, quotes and spaces/vs tabs, but I would gladly concede if we could standardize on something.

[j-f1]

There is a new page on the website that sums up our option philosophy, which is pretty similar to @gaearon’s original comment.

[rafayepes]

@jlongster do we even need point 1? I'll suggest delaying config options as much as possible. If the tool works excellently without many problems it might start to get traction enough to convert people :)

[marcialca]

Following on @gaearon comment, an idea would be to make a list of all the possible configurations and decide if they produce clashes (like semicolons) or they don't (string quotes) and maybe analyse their introduction to the core, based on this point:

doesn’t cause exponential growth of bug surface area.

That would make a clear point and explanation on why something is not added or is made configurable and it would make a good pillar for the project and it feels like a good middle ground.

[kentcdodds]

is the only reason you want it dropping semicolons?

It's more about being able to take advantage of the advanced formatting capabilities of prettier, without sacrificing the stylistic choices of people already using ESlint to autofix/format their code. Whether that be semicolons or spacing in parameter lists.

There are things that I can do to speed up prettier-eslint (like not applying rules that cannot be fixed). But if we could figure out a way to get the prettier formatted AST and have ESlint consume that, that would probably be the biggest bang for our performance buck...

[ITenthusiasm]

As an added note:

If the consensus becomes that visual overload isn't a significant problem or consideration, it might be useful to add that to the philosophy page too.

[jlongster]

Thanks you @dangoor, that is good insight and I agree. Right now let's focus on making this solid for the demographic of people who use spaces and semicolons at least. We can go from there.

@munificent that's a fantastic point. I've already run into that with the current options, because I use Jest snapshot testing, but they are all generated only with the default options. If someone makes PR, I don't see how it affects the code if the options are turned on. And I'm definitely not going to have a 2^N number of tests folder where N is the number of flags.

[swansontec]

@matthewp I hear what you are saying, but regardless of where you fall on the configurable vs. opinionated spectrum, isn't it better when tools can work together?

[munificent]

I loved your article on dartfmt btw

Thanks!

[hzoo]

I'd like to talk more about how we can make it easy to integrate prettier and eslint. I think this could solve the semicolon debate, too: if I can generate code with semicolons and pass it through eslint's fix process with the "no semicolon" rule on, people who really don't want semicolons could set that up. That allows this project to be focused and opinionated but leverage eslint's flexible toolchain.

That sounds good too 👍

Is there a place we can talk about integration? It's easy in theory, but the devil's in the details, and I'm particularly concerned about performance because a naive prettier foo.js | eslint --stdin probably parses the source twice.

Should we make a new issue here? If we want to pass the AST to ESLint then could possibly just run it through babel-eslint or something similar (or babylon with estree plugin when we get to that). (speaking as someone who has worked on all of these). But AST is weird since it won't keep the info we want (formatting) so maybe look at CST again? (https://github.com/cst/cst for what was in JSCS, but requires some more discussion)

[jlongster]

@kentcdodds That looks cool. That's what I'm aiming for -- keep this project focused and let editor integration be where things like that happen.

I'm curious: is the only reason you want it dropping semicolons? For large files, I believe that will be pretty slow. I'm not happy with prettier's performance itself on ~2000 line files (it's not terrible, something like 600ms, but I want to improve it). I'd like the formatting to feel as instant as possible, and eslint seemed to add another 1s on the large file when I tried it.

[jlongster]

Should we make a new issue here? If we want to pass the AST to ESLint then could possibly just run it through babel-eslint or something similar (or babylon with estree plugin when we get to that). (speaking as someone who has worked on all of these). But AST is weird since it won't keep the info we want (formatting) so maybe look at CST again? (https://github.com/cst/cst for what was in JSCS, but requires some more discussion)

Yeah, let's make a new issue

[rattrayalex-stripe]

Prettier now has a configuration file.

Docs: https://github.com/prettier/prettier/blob/master/README.md#configuration-file
Release notes: https://github.com/prettier/prettier/releases/tag/1.6.0

The ethos of prettier very much remains "resist adding configuration wherever possible" and it is very unlikely that further configuration will be added in the future.