Preventing conflict between Prettier (code formatter) and ESLint/TSLint
Asked Answered
H

2

24

I am working on an Angular project in VS Code, using the "Prettier" plugin for code formatting, and the ESLint/TSLint plugins for standards enforcement.

I know this isn't an "error" but I strongly prefer clean builds and like to remove warnings whenever possible.

  groupMouseDown = d => {
   ...
  }; <--- This semicolon is the issue

The above is a function in Typescript, using the "fat arrow" syntax so that the function is inline. Notice that, at the end of the line, is a semi-colon.

I'm not here to start an argument about whether or not the semi-colon should be here, there are lots of those on the web. Rather, I just need to deal with it.

Prettier is considered an "opinionated" formatter, and their stance on the subject is that they believe it should be there. Which is fine, but they also refuse to add an option to NOT put it there, hence the "opinionated' part.

The linters on the other hand, believe that a semicolon should NOT be there, and so they flag it as an unnecessary semicolon. So far, I have not found an option to NOT report this as a warning unless I remove it for every case.

So, at the end of the day, I have to tools the disagree and leave me with no options to just ignore this and do what I want them to do, which is play nicely together.

Has anyone else come up against this? Is there a way to either: 1) Stop prettier from adding the semicolon ONLY IN THIS SPECIFIC CASE, or... 2) Stop the linters from reporting this as a warning ONLY IN THIS SPECIFIC CASE?

What I DON'T want to do is tell Prettier to not put ANY semicolons where needed, nor do I want to tell the linters to ignore ALL unnecessary semicolons.

Hinckley answered 14/6, 2019 at 19:53 Comment(0)
M
19

No accepted answer here so I'll share my two cents :

I totally agree with @Josh on the fact that you should let prettier do its thing and make the linter agree with its style choices. However I don't want to depend on an additional plugin and the TSLINT article is a little bit too long to read so here's the specific rule your need to adjust :

If you're using TSLINT, you can add the following rule to your tslint.json file

I'm not using ESLINT (yet) so I don't know if the linter complains about this use case, and if it does I didn't find any option to deal with it

Miyasawa answered 5/5, 2020 at 10:49 Comment(1)
Side note: TSLINT has been deprecated as of 2019Lucifer
E
8

Generally, when using Prettier, it's best to let Prettier do all formatting work. Use linters only for non-formatting concerns such as bug detection.

There are plugins for both ESLint and TSLint that turn off all style rules:

If your linter is still complaining about some formatting rule, you can file a bug on those GitHub projects and in the meantime configure your linter to disable that rule:

Alternately, you can disable rules on a line, block, or file basis:

Which is fine, but they also refuse to add an option to NOT put it there, hence the "opinionated' part.

Just in case someone lands here from Google and gets confused: Prettier does have configuration options, just not quite as granular as the post might want. https://prettier.io/docs/en/configuration.html

Endbrain answered 15/6, 2019 at 14:2 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.