0

In our JS files, we have below structure:

import { html } from 'lit-html';

function when(expression, trueValue, falseValue) {
  if (expression) {
    return trueValue();
  }

  if (falseValue) {
    return falseValue();
  }
  return undefined;
}

export class SomeClass extends LitElement {
  render = () => html`
    <someHtml>
      <p>Some text</p>
      ${when(
        someCondition,
        () => html`<div>on condition true</div>`
        () => html`<div>on condition false</div>`
      )}
    </someHtml>
  `;
}

The when function creates a conflict between our Prettier and ESLint configuration.

Here is our prettier configuration:

{
  "printWidth": 100,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5",
}

and our eslint/indent rule:

 "indent": [
  "error",
  2,
  {
    "SwitchCase": 1,
    "CallExpression": { "arguments": 1 }
  }
]

Can you tell me why I am getting below errors with the above setup?

ESLint: Expected indentation of 4 spaces but found 8.(indent)
ESLint: Expected indentation of 6 spaces but found 10.(indent)
yenerunver
  • 416
  • 1
  • 5
  • 26

1 Answers1

2

Don't use eslint for indentation. From the Prettier vs. Linters documentation:

How does it compare to ESLint/TSLint/stylelint, etc.?

Linters have two categories of rules:

Formatting rules: eg: max-len, no-mixed-spaces-and-tabs, keyword-spacing, comma-style…

Prettier alleviates the need for this whole category of rules! Prettier is going to reprint the entire program from scratch in a consistent way, so it’s not possible for the programmer to make a mistake there anymore :)

Code-quality rules: eg no-unused-vars, no-extra-bind, no-implicit-globals, prefer-promise-reject-errors…

Prettier does nothing to help with those kind of rules. They are also the most important ones provided by linters as they are likely to catch real bugs with your code!

In other words, use Prettier for formatting and linters for catching bugs!

This guidance applies to the eslint/indent rule as well. This conflict (and resolution) is fairly well documented elsewhere:

You most likely would benefit from doing a more pure integration between eslint and prettier as described in Integrating with Linters if you haven't already, and then ensuring that you don't override prettier/recommended afterwards.

anothermh
  • 9,815
  • 3
  • 33
  • 52
  • Thank you for the accessibility remark @anothermh, I edited to content accordingly. About your point, I am not 100% convinced that we cannot use both together because, currently they work very well together except for this very specific case. If I were to somehow tell ESLint that whenever it sees `${when()}`, it should just keep adding indentation, then my problem will be gone. – yenerunver May 12 '23 at 08:53
  • I'm not trying to tell you my opinion, I'm giving you the factual answer from the creators of prettier and backing it up with multiple experts all telling you the same thing: `eslint` is is for code quality and `prettier` is for formatting. If you don't do that then you have frequent conflicts like the one you're describing. That's why [eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier) has the `prettier/recommended` plugin for eslint; it will automatically disable conflicting rules so that you don't experience these issues. – anothermh May 12 '23 at 16:10
  • From that README: *This plugin works best if you disable all other ESLint rules relating to code formatting, and only enable rules that detect potential bugs. (If another active ESLint rule disagrees with `prettier` about how code should be formatted, it will be impossible to avoid lint errors.) You can use eslint-config-prettier to disable all formatting-related ESLint rules.* – anothermh May 12 '23 at 16:10
  • Yeah yeah, I get that. I am not saying they are wrong. I am just saying that my preference would be keeping them both enabled for now, if I can somehow solve this tiny problem. I would prefer keeping ESLint as styling police so that we can keep a certain standard. I fear that, once we disable ESLint for certain rules like indentation, we will lose our standards. – yenerunver May 12 '23 at 19:58
  • I hear you on that. I'm very particular about code quality standards. The approach that I've taken is: *defer to the linter whenever possible*. In my case I use the above plugin so prettier and eslint are integrated. We use every default possible. We also use [standard](https://standardjs.com/) and [ts-standard](https://github.com/standard/ts-standard) to take as much customization out of the picture as possible. Let's pretend we worked together, I'd ask you two questions: why do you have this configuration and do you absolutely *require* this configuration? If not then drop it. – anothermh May 12 '23 at 20:51
  • The excuse I will give would be that we cannot force Prettier or a certain configuration so to keep a certain standard, we should either implement Prettier formatting on push/commit/merge or should force it with ESLint. – yenerunver May 13 '23 at 21:46