Introduce standard.js compatibility flag

[sheerun]

• I’ve added tests to confirm my change works.
• (If changing the API or CLI) I’ve documented the changes I’ve made (in the docs/ directory)
• I’ve read the contributing guidelines.

Hello prettier,

I am the author of prettier-standard library that tries to be similar to prettier while maintaining compatibility with standard that has been present for some time before prettier. Standard is still used by many developers and its rules are preferred by many developers (equivalents of --no-semi --single-quote --jsx-single-quote like + not implemented --space-before-function-paren).

While I enjoy github stars \s prettier-standard is not a perfect solution because it needs to pass every file first through prettier and then though eslint with standard whitespace rules. This makes this process very slow. Ideally this functionality would be embedded within prettier itself so developers can just write prettier --standard instead of prettier-standard. I would gladly deprecate my package and point to new prettier version if you agreed to merge this PR.

There's discussion whether introduce extra flag for inserting space before function name or anonymous function, this won't make prettier compatible with standard as there are many more nuances like spaces around generator stars. This PR introduces --standard flag that has single purpose: make prettier format code as such running standard after it won't complain about formatting of code. I think it's good measure to not introduce many flags into prettier and at the same time satisfy people who even start to fork this project.

I've gathered all whitespace-related rules of standard and added tests for each of them from straight from eslint docs (both correct ones and incorrect ones). I've also included compatibility with the way standard wants to format typescript and flow. You can verify that with this flag formatting is compatible with standard by running following commands or visually inspecting new tests:

# verifies that es6 example is compatible with standard (nothing changes)
standard --parser babel-eslint --fix tests/standard/correct.js # nothing changes
diff tests/standard/correct.js <(node bin/prettier.js --standard tests/standard/correct.js)

# verifies that typescript example is compatible with standard (nothing changes)
standard --parser typescript-eslint-parser --plugin typescript --fix tests/standard/typescript/correct.ts 
diff tests/standard/typescript/correct.ts <(node bin/prettier.js --standard tests/standard/typescript/correct.ts)

# verifies that flow example is compatible with standard (nothing changes)
standard --parser babel-eslint --plugin flowtype --fix tests/standard/flow/correct.js
diff tests/standard/flow/correct.js <(node bin/prettier.js --standard tests/standard/flow/correct.js)

You can find more information how to configure standard for flow & typescript on their home page.

What do you think? This could potentially be last and final flag to satisfy standard.js camp.

[sheerun]

I fixed the tests

Also, one notable project that needs to run standard --fix for fixing formatting so it's 100% compatible with standard because prettier doesn't support it is next.js. After this PR they could just use --standard flag and avoid passing code additionally though standard.

[kachkaev]

Standard is still used by many developers and its rules are preferred by many developers

Just curious: what stats could support this claim? I've done a small personal research recently to figure out if no semicolons are really common these days in JS. My subjective conclusion was ‘no’ as the majority of popular repos I've looked into do use semicolons. I have semicolons in most JS/TS projects too, not only because because they are a part of the language and because they are default in Prettier, but also because things like ;[] and ;() look too ugly to me.

Full disclaimer: I'm not a big fan of standard.js because some of its decisions are based on the reasoning coming from quite a few years ago and so may be suboptimal in ES6 / TypeScript. The name of this just another opinionated set of rules appears to be an issue to me too (it's claiming too much). To avoid a very long argument let me just share these thoughts, with which I agree:
https://hackernoon.com/an-open-letter-to-javascript-leaders-regarding-no-semicolons-82cec422d67d

Given that Prettier is not just for JS and --standard is JS-specific, I'm not sure how the new option can benefit Prettier users in a general case. prettier-standard, a separate project for Prettier and standard.js looks just fine to me given that this solution is for a sub-sub-set of Prettier users only (those who write JS + those who pick standard.js as one of many rule sets).

Anyway, this is just my subjective opinion which is not a blocker for anything the majority of maintainers decide. I'm not a maintainer myself – just hanging around in the repo now and then 😉 Please don't consider my words as criticism of your work @sheerun – I'm just trying to contribute to Prettier core just as you do 😉 🙌 prettier-standard appears to be a useful project indeed given the number of stars it has got! 👍 Thanks for your work!

[sheerun]

Thank you for response.

First of all let me kindly dismiss your argument "look too ugly to me.". As you noticed later it's subjective matter plus provided cases are very rare in real code. Prettier states about itself that it's "opinionated code formatter", it's no different. Standard is just a name. I'm not here to argue which style is better but provide solution for these developers who find standard's syntax better.

I've read this article you provided and it focuses on something that in my long experience is never a problem. It states problem but immediately provides solution (semicolons when line starts with [, ( or tilde, very rare case. It also asks "Moreover, where is code style consistency?", but this style actually has more consistent rules than rules where to put semicolons.

Again I don't want to argue about which style is better so let's focus on more objective reasons.

Just curious: what stats could support this claim?

I've downloaded 1000 most popular npm packages dependent upon and 154 of them use standard while 125 of them use prettier, which is not ultimate stat but I hope it shows standard isn't a niche and your statement that "majority of popular repos I've looked into do use semicolons" might be true but is not relevant.

Also in my experience many projects use prettier but also use --no-semi and --single-quote which is closer to standard formatting than prettier's default one. Sorry but I don't have time to provide analytics for this one, do you?

Given that Prettier is not just for JS and --standard is JS-specific, I'm not sure how the new option can benefit Prettier users in a general case

Actually most of current prettier options apply only to javascript.

some of its decisions are based on the reasoning coming from quite a few years ago and so may be suboptimal in ES6 / TypeScript

Not sure what's the reasoning you're referring to, or what may be suboptimal. What's sure that many project exist with codebases in standard style, a well as many developers who would like to start projects in standard style and they would also love to use prettier for nice whitespace. This PR allows all of them for easy migration to prettier without having whitespace removed after every function name.

The same way, dont' consider my words criticism of your likings. I realise many prefer semicolons and I don't intend to argue about it. I hope prettier realises this is not matter of one team fighting the other but rather respecting and acknowledging each other.

[brodybits]

Thanks @sheerun for your work on this idea. But I have a major concern that it mixes several things together:

• spacing in functions and generators
• no semicolons
• single quotes

I would really favor keeping these items in separate options. This would really help people using "semistandard", for example.

[sheerun]

"semistandard" is much less popular than standard (7 packages of top 1000 use it). Ultimately this decision is up to prettier, what I care only about it that I can use prettier to format according to standard rules. It doesn't really matter to me if I use one flag or 5. I would need official stance of @prettier in form of "if you change this and that, we'll merge this PR"

[lydell]

So … I might be wrong, but here goes: I've been under the impression that people use standard because it's easy to use, helpful and ends many code style debates (no configuration). Not because it uses the exact code style people have been looking for (no semicolons, spaces in some places). If so … does it really matter if Prettier's code style is slightly different?

[brodybits]

I integrated this proposal into the prettierx fork, behind several options as documented here. I would love to see these formatting capabilities integrated into prettier someday.

I think we still need some kind of a higher-level tool like prettier-standard for easy integration between standard semantic rules and the improved formatting capabilities (could be part of standard/standard#811). Maybe based on Babel?

An alternative solution for the improved formatting capabilities may be some kind of plugin support.

[lydell]

@brodybits Have you considered using ESLint directly instead of through standard, with eslint-config-standard + eslint-config-prettier?

[sheerun]

So … I might be wrong, but here goes: I've been under the impression that people use standard because it's easy to use, helpful and ends many code style debates (no configuration). Not because it uses the exact code style people have been looking for (no semicolons, spaces in some places). If so … does it really matter if Prettier's code style is slightly different?

No semicolons is main reason, but it's more than that: Imagine you've created your library in 2015. Because you don't like semicolons you've chosen standard for formatting and linting your codebase. Your project is successful and your codebase grows huge. Then two years later tool called prettier is released that can format whitespace in your project even better, great! Then you realise that you cannot switch to it without reformatting most of your codebase because it doesn't support --jsx-single-quote and --space-before-function-paren. You wait two years for first one to be added and even then prettier cannot decide on adding the second one. This is what's happening.

I integrated this proposal into the prettierx fork, behind several options as documented here. I would love to see these formatting capabilities integrated into prettier someday.

I could do the same for prettier-standard but I'm convinced adding standard or space-before-function-paren functionality directly to prettier would be superior to forking this project.

[lydell]

I used to be an adamant "no semicolons person", but bit the bullet when Prettier came out (initially the --no-semi option didn't exist). I converted at least two bigger code bases from no semis to semis, and the whole thing went pretty smoothly. Prettier caused a lot of diffs anyway. When the --no-semi option came out I didn't bother switching again. These days I even prefer semicolons! (I still don't type them, though – I let Prettier insert them for me).

[brodybits]

Have you considered using ESLint directly instead of through standard, with eslint-config-standard + eslint-config-prettier?

Yes. I personally like to use "semistandard", which is standard with semicolons, through configuration of eslint.

But prettier seems to be missing some formatting capabilities that are proposed here:

• space before function paren (see eslint space-before-function-paren rule)
• generator star spacing (see eslint generator-star-spacing rule)
• yield star spacing (see eslint yield-star-spacing rule)

I'm convinced adding standard or space-before-function-paren functionality directly to prettier would be superior to forking this project.

👍

[j-f1]

PR for the spacing is here: #3903. It doesn’t add a space before the *, though.

[sheerun]

Maybe prettier could introduce --preset flag that could be used like so:

• --preset standard
• --preset semistandard

[brodybits]

PR for the spacing is here: #3903. It doesn’t add a space before the *, though.

PR #3903 seems to miss some other cases that are covered by this PR, prettier-miscellaneous, and my prettierx fork:

• function foo() {...} --> function foo () {...} (space after function name)
• bar() {...} --> bar () {...} member function in an object or class (ditto)
• function baz<T>(a: T) {...} --> function baz<T> (a: T) {...} (space after <T>)

I think it would also be nice if PR #3903 could be rebased or updated with the latest changes from master.

Maybe prettier could introduce --preset flag

Nice idea. But there are quite a few (semi)standard semantic rules for eslint that seem to be outside the scope of prettier.

[kachkaev]

Maybe prettier could introduce --preset flag

In accordance with Prettier's options philosophy, there exist >400 votes against adding --preset or --standard.

[sheerun]

It's not like there are thousands of formatting standards, there is prettier, standard, and maybe semistandard. What @gaearon said was probably a reference to huge number of eslint config options.

[kachkaev]

What @gaearon said was probably a reference to huge number of eslint config options

... which is exactly what standard / semistandard / airbnb / google and other JS styleguides are resolvable to, aren't they? 🤔

[brodybits]

Any ideas for moving forward with the formatting improvements?

Anything better than forking?

[sheerun]

prettier is similar to standard / semistandard / airbnb / google that all are collections of formatting rules, they don't allow you to choose exact formatting options the same way prettier doesn't want to

prettier is at the same something more: it allows for precise whitespace formatting, previous tools were very limited at this. many projects that use other formatting standard like standard would love to have similar feature without passing their code first through prettier and then though other tool

Please realise that most options prettier introduced so far or that are requested, were because people want to configure this particular option but because they want standard and semistandard formatting:

• no-semi: Add option to omit semicolons in output #12 (comment)
• single quotes: unfortunately cannot point to anything, it was available from the beginning
• single jsx quotes: Provide way to use single quotes in jsx #1080 (comment)
• space-before-function-paren: Space after function keyword - MOVED to #3847! #1139 (comment) followed by Space after function keyword in anonymous functions #3847 Space after function name in declarations #3845 Space after function name in declarations #3845 (comment)

So in a way it was possible for prettier to have single --preset option but (maybe because of constant pushback) prettier ends implementing these options one by one, contradicting its own rules.

[lydell]

@brodybits How do you motivate space before function paren, generator star spacing and yield star spacing?

[sheerun]

These are rules used by standard whitespace formatting

It doesn't need motivation as it's arbitrary decision made by standard the same way prettier made arbitrary decisions about formatting. It's about following once set alternative formatting rules that are as popular as prettier's own.

This is why this PR doesn't try to introduce these options one by one, it actually follows your "resisting adding configuration" rule more than any single option you'd add (though --space-before-function-paren is last remaining significant one to be added for satisfactory compatibility with standard).

[lydell]

I mentioned many times it's not only about supporting new projects but existing ones.

But why? Why can't existing projects change? Just trying to understand all the details.

[sheerun]

• Introduce standard.js compatibility flag #5723 (comment)

While changing formatting standard with few developers is fairly easy, it is a big challenge for big projects with many pending pull requests to merge which would cause many conflicts and coordination and disorder of whole team for some time.

I don't like how discussion goes because everyone tells me to prove that standard is better or why somebody would not like to switch to prettier. It is not better or worse, it's different. If prettier was black-hair only hairdresser I suggested to support blonde hair I wouldn't need to explain how popular blonde hair is, hear that it's "ugly", or why blonde people just won't color their hair black, because it's so easy.

[sheerun]

I don't want to argue anymore so I'd like to ask maintainers: what is the solution you propose?

[lydell]

I think you will get many merge conflicts with open PRs even with a --standard flag, so my proposal would be to do nothing on Prettier's side. Instead, research how other big code bases migrated to Prettier.

[j-f1]

Instead, research how other big code bases migrated to Prettier.

I’m wondering if we should make a docs page with some information from people who have done this, since the docs don’t have much information on adding Prettier to an existing project.

[duailibe]

@sheerun We're not asking you to prove why one is better than the other. We just really hate supporting multiple code styles. And in order to keep a single code style, we ask since day one "what's the most common way people write this code by hand" for every piece of syntax. That's also what drives our decisions to add new options or not: we won't add new options unless we believe it will "unblock" lots of people to start using Prettier. That's why you're seeing "pushback" in this thread, we really don't like adding options.

I'd like to remind that while we do want new users and try to support them, we won't do that by supporting other code styles and that's why I think Prettier is not for everyone. We support this tool that formats code automatically as consistent as we can (which is good for a number of reasons), and the users just need to let go of their previous formatting preferences. If they can't do that, maybe Prettier is not for them, but that's fine.

[sheerun]

Could you as compromise agree to accept PR with --space-before-function-paren?

[KidkArolis]

At the risk of going slightly off topic, I wanted to share my perspective.

@lydell one thing I didn't see being discussed in this thread is the non-style related aspects of standard. I happily switched from standard to prettier, the auto formatting is great. I don't mind the specifics of each tool's styling choices, like many, I like to not have to make those decisions. The issue I quickly ran into after switching from standard to prettier is how prettier only formats the code, it doesn't lint against very common issues (aka stuff in eslint:recommended, things like unused variables). I was used to standard's opinionatedness in helping with both style and function (can't think of a better word).

So now I have a few options (back to having to make decisions with linters). Use prettier-standard and standard (less configuration needed, but frustrating that both tools have different interface) or prettier and eslint (fidly configuration required, not clear which tool to run when and which order).

Ideally, I just want a single tool to do both formatting and linting, but maybe I'm in the minority? I guess it's simply not prettier's concern to add --lint flag. But if that, or something equivalent (plugin, separate "official prettier tool", etc.) existed, I wonder if you'd get higher adoption of prettier as people would have less reason to stick with standard.

And just for completeness sake, here's the possible scenarios I see that would solve this problem for me and hopefully many other long time standard users:

1. prettier-standard adds --lint flag as discussed in Default glob pattern like standard sheerun/prettier-standard#35 and prettier-standard --check sheerun/prettier-standard#17
2. prettier adds --lint flag or an equivalent method for running plugin:prettier/recommended
3. standard adds --format that's powered by prettier
4. we switch to another tool that combines both formatting and linting, e.g. https://github.com/jorgegonzalez/zoe (just found this)

Again, apologies if this is a bit off topic. I understand the thread was more about making the interop between prettier and standard better. Especially for reasons @sheerun mentioned in this thread, where long time codebases want to benefit from prettier without having to reformat existing code. But I think there's this other overlooked dimension to the question of why people might want to combine the two tools – which is that both formatting and linting are very valuable and that convention based easy to use tools are also valuable.

[lydell]

@KidkArolis Sounds like you're looking for ESLint + eslint-config-standard + eslint-config-prettier + eslint-plugin-prettier. Then you get a single tool (ESLint) that does both code quality checking and style linting (with autofix). I use this in a project at work (where we used plain standard before) and it works nicely.

[kachkaev]

@KidkArolis the fact that Prettier does not dive into the code semantics its actually a benefit rather than a disadvantage. It leaves you with an option to check the semantics with ESLint, TypeScript compiler, TSLint, StyleLint, and many others. There are lots of languages that Prettier can work with, including those available through plugins. Thus, if Prettier spills over the scope of spaces and tabs, the tool will become too bulky.

I see your point about standard.js caring both about the style and the semantics, this is handy indeed. However, this leaves you with a tool that is JS-only, which is somewhat too narrow these days.

[KidkArolis]

@kachkaev I think that makes sense, which is why my suggested options 1, 3 or 4 are probably better options. I'm just trying to see which one is the most viable.

@lydell if you use ESLint + eslint-config-standard + eslint-config-prettier + eslint-plugin-prettier, don't the prettier rules conflict with standard rules? Or else this GH issue (about --space-before-function-paren and all that) wouldn't exist?

[lydell]

if you use ESLint + eslint-config-standard + eslint-config-prettier + eslint-plugin-prettier, don't the prettier rules conflict with standard rules?

They don't! eslint-config-prettier disables all the conflicting ones.

[KidkArolis]

And now going really off topic.. should look into this myself, but which one is more comprehensive: eslint-config-standard or eslint-config-recommended? If I'm jumping standard ship into the prettier one, might as well reconsider which eslint set I'm using.

[lydell]

which one is more comprehensive: eslint-config-standard or eslint-config-recommended

If you mean the built-in eslint:recommended, eslint-config-standard is much more comprehensive. I've heard eslint-config-react-app is good, too.

[sheerun]

I guess I for now I won't convince anyone from prettier to support flags that make formatting closer to standard, so for now I've released prettier-standard that uses prettierx fork instead, so anyone wants even better standard.js compatibility than prettier-standard provides, please send pull request to it.

[User486375]

if you use ESLint + eslint-config-standard + eslint-config-prettier + eslint-plugin-prettier, don't the prettier rules conflict with standard rules?

They don't! eslint-config-prettier disables all the conflicting ones.

@lydell Have you actually tested and verified this yourself? Because it doesn't in mine and many others experiences when it comes to --space-before-function-paren. Multiple people mention it in both #3847 and #1139. prettier/prettier-vscode#494 is a more specfic example.

[bakkot]

@User486375 Can you give a minimal reproduction? I have a .eslintrc.json containing

{
  "extends": ["standard", "prettier"],
  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": "error"
  }
}

and a .prettierrc.json containing

{
  "semi": false
}

and I do not get any errors when linting a file containing

function f() {
  return 0
}

console.log(f())

So it looks to me like extending "prettier" does, indeed, disable the conflicting rule from "standard". Is that not what you observe?