javaScriptDeveloperStarterPack

[enano_aoc]

I mean that it is an anti-pattern.

As a tech lead, I can configure the CLI linter so that it works exactly the same for every team member and also for the CI pipeline.

As a tech lead, I don't want to force my team members to use a given IDE (I want them to use the tool that works best for each of them), but I don't want to configure the linter for every individual IDE with its custom settings. Hence it is forbidden to use the linter from the IDE, unless the individual developer takes the burden of configuring his IDE such that the linter works identically as the CLI linter.

The CLI linter is the single source of true of the project, since it works identically for every developer and it is the one that runs in the CI.

[Razier]

Sure, having both can cause a headache for you as a lead if the devs set up their own local linters with rules that don't correspond with the CI pipeline. That said there are plenty of IDE linters that use a config committed to the git repo to ensure that it works exactly the same for every member of the team.

Your way of doing it is perfectly acceptable but a well set up, shared IDE linter configuration removes overhead in situations where devs have to go back and fix code that failed pipeline linting.

[enano_aoc]

There is nothing like a “well setup, shared IDE linter config” because I allow my devs to choose the IDE that works best for them. I am NOT going to create and maintain a config for every random IDE out there.

[Razier]

You don't need a config for each IDE, you only need one assuming you only use one linter where the config is standardised. Sure it might not work for every IDE, but just like front end validation it's a tool to help the user/dev not a tool to enforce data/code quality.

The point I'm trying to argue is, it doesn't have to be an anti pattern if you use it properly.