Search code examples
visual-studio-codeeslintprettiertypescript-eslint

How to prevent VSCode prettier and eslint clashing with projects configuration


I can't find setting how to disable eslint errors and auto formatting for type assertions as per below example. I use as keyword right after object I am returning from arrow function, but eslint shows me error.

Code before formatting

const someResult = someArray.map(
    () =>
        ({
            // Object props
        } as SomeType),
);

I get this warning

enter image description here

Code after formatting - when I save file code is formatted for split second to this, but then returns to original as I believe there is a clash between vscode configuration and project configuration.

const someResult = someArray.map(
    () =>
        ({
            // Object props
        }) as SomeType,
);

I want to give priority to my project eslit/prettier configuration and only format and show errors that are cause by not following project configuration rules. What settings should I change?


Solution

  • Quick fix: it looks like your code is using eslint-plugin-prettier. That's a plugin that runs Prettier (a formatter) inside ESLint (a linter). Remove references to prettier from your ESLint config, and you'll stop seeing these complaints.


    In more detail: there are two kinds of tools in play that are structurally different and better at different tasks. Speaking to how these tools work in the web ecosystem:

    • Formatters (e.g. Prettier): generally only apply changes to code trivia/whitespace that don't impact runtime, such as tabs vs. spaces or when to insert newlines. They run very quickly because they don't have to deal with code logic and can reformat each file in one pass.
    • Linters (e.g. ESLint): generally run a set of discrete rules that can understand code logic. They can be very powerful and change logic for the better, but are slower because lint rules have to think more (especially when you enable more advanced features such as typescript-eslint's linting with type information) and re-run if any fixes are applied automatically.

    The line used to be more blurry because ESLint used to provide and recommend rules that enforced formatting. This was nice because you could use one tool for both formatting and linting - and because each lint rule is configurable, you could customize your formatting preferences very granularly.

    However, because lint rules each deal with a unique area of logic and all have to be re-run if any fix is auto-applied, formatting with a linter is notoriously slow, prone to missed edge cases, and difficult for the lint teams to work with. Most lint teams now recommend against using a linter for formatting:

    What's happening is that you've enabled granular formatting lint rules in ESLint, and also enabled the general prettier/prettier rule with different preferences. When ESLint is run in auto-fix mode, such as in your editor, it'll try to keep re-running and applying fixes up to 10 times. The granular formatting lint rules are applying one style and the general Prettier rule is applying a different style. So ESLint keeps switching between them.

    This question is a partial duplicate of Is Prettier really needed when using Eslint? (hence the copy & paste of part of the answer from there).