They can see the policy working...

We have linting set up in our codebase, I had to switch and focus on one half of our project, and I nearly lost my mind when I came back to the other side and realized that every time someone said they were 'addressing linting issues', that actually meant they were putting eslint-disable everywhere until the pipeline stopped complaining.

Code reviews?
- "It passed CI, LGTM"
- The developer I report to was in charge of that side of the code base and doing all the code reviews for it .... I thought he had a handle on it :/
I might get physical in that sitiation. And I'm very tame.

Hot take: Clean up your darn imports. Otherwise you just make the links between modules confusing and messy.

Sounds like a perfectly normal take.
- Really, OP might have had the hot one with "unnecessary imports sitting around is fine".

The duality of Programmer Humor: You get posts complaining about bloat, and posts complaining about this.

Competent people vs incompetent people.
- Also, slightly less competent ppl vs slightly more competent ppl.

Except those imports were used by a huge section of code you temporarily commented out, and now you'll need to manually select a dozen imports to get it working again when you come back to it.

(Sure you could have just commented out the unused imports, but the linter auto-sorted them and you're feeling too lazy to copy-paste a dozen scattered lines)

That is what version control is for.
- This. Commenting out code is bad practice
Use a good IDE, and readding the imports is pretty easy.
I find commented code to be a bit of a smell on its own, just delete it, and if you really need it again, dig it out of source control.
- Yeah. My last job, a PR with commented out code typically wouldn't get approved. Either leave it in version history, or stick it on a branch
Hum... Ignore linter advice for code that you temporarily mangled.
It's not like you have to act upon it as soon as a blue line appears under your code.
- Depending on the configuration, a linter may cause the compilation or a CI pipeline to fail.
During code review, we reject PR’s with commented out code. Problem solved.
Honestly I'll disable linting across entire files during these kinds of refactors because it's annoying having build output littered with unused imports and format warnings while I'm still working on a solution. Requires some extra diligence to re-enable and clean up before pushing though.
- Use pre-commit with a linter config that checks all files, local dev can have a different config to disable as needed.

The Trade Federation greatly appreciates useful imports.

Case 1:
- Just typed the ending '>' for the include and see the annotation come up.
Case 2:
- Did not include the header, so not getting the code completion recommendation, making me have to type the function/class/whatever name.
Case 3:
- The code completion comes up with an option of including the header (except that it is including the wrong header, despite me having already included the correct one)