Prettier reformats if / else into single line

Question

I am trying Prettier out in a project using React and Typescript. However I am having a problem configuring multi-line if / else statements.

When I write:

if (x >=0) {
  // Do something
}
else {
  // Do something else
}

Prettier reformats it to:

if (x >=0) {
  // Do something
} else {
  // Do something else
}

I added this rule to my tslint file: "one-line": false, but Prettier is still formatting my statements.

Is this a core rule of Prettier that can't be changed through the tslint config or am I doing something wrong?

My tslint.json is:

{
  "extends": [
    "tslint:recommended",
    "tslint-react",
    "tslint-config-prettier"
  ],
  "rules": {
    "prettier": true,
    "interface-name": false,
    "no-console": [
      true,
      "log",
      "debug",
      "info",
      "time",
      "timeEnd",
      "trace"
    ],
    "one-line": false
  },
  "rulesDirectory": [
    "tslint-plugin-prettier"
  ]
}

and my .prettierrc file is:

{
  "trailingComma": "es5",
  "printWidth": 80,
  "semi": true,
  "tslintIntegration": true,
  "eslintIntegration": true,
  "jsxSingleQuote": true,
  "singleQuote": true
}

Monandry

Prettier is an opinionated formater, which means it's not meant to be customizable, it's meant to settle endless arguments on format within teams. – Appreciate

If you want more flexibility, ESLint can do wonder on its own in addition to all the common errors it's preventing! – Appreciate

I understand your point. I just thoght that since Prettier says the single-line error came from tslint, I could change its configuration and make it go away. – Monandry

i agree. it is annoying ! – Pythoness

@EmileBergeron While I see the advantage of one way style, I find it a disgrace towards developers. There's no such thing as right style as it varies just like favorite color or preferred flavor does. It's good to have consistent styling within a context but not a global one. Prettier is a great piece of software but it lacking in customization is an abomination in my view. I liked how it imposes the style after preferred configuration. Sadly, I prefer to impose not to be imposed on. Probably going to npm uninstall... :( – Bedfordshire

@KonradViltersten I agree! shrug In the end, having to work on different projects at the same time, I figured it was easier to manage my expectation than to maintain heavy configurations on every project, so I caved in to Prettier. We still use ESLint, but the formatting is left to Prettier. Also, autoformatting integration is spotty for ESLint versus Prettier in the different IDEs I've used over the years, and it's getting worse for ESLint (plugins not maintained anymore, etc). – Appreciate

Does this answer your question? How to fix prettier and tslint error with brackets with single props? – Riff

'Else' being hoisted up onto the if's closing curly is gross, enough for me to draw the line on prettier. Blech. – Triform

Answer 1

There is a nice way around this:

// your comment 1
if (case1) {
 ...
}
// your comment 2
else if (case2) {
 ...
}
// your comment 3
else {
 ...
}

when prettier sees comment lines in between, it won't clip the block into one line.

Incisor

No longer true unfortunately. Prettier moves the comment inside the else if block. – Everest

@Everest for me it works still – Swank

Answer 2

When combining Prettier with a linter in a project:

• Prettier will handle all formatting rules
• Code-quality rules will be handled by the linter (such as tslint)

Changing the config of tslint for formatting will not affect the output of prettier.
See Prettier vs Linters.

In fact, if you're not careful of how you configure tslint you can end up with conflicting rules. Which is why packages like tslint-config-prettier exist.

Prettier has very few configuration options as it is an oppinionated formatter as explained in their Option Philosophy.

Gobelin

Answer 3

Sometimes it is prettier to use switch (true):

switch (true) {
  case CONDITION_1:
    ...
    break

  case CONDITION_2:
    ...
    break
}

Aerate