[Mehdi2277]

My team started with an untyped codebase a year ago. I added a rule to CI that every pr that touches files with type errors must decrease the type errors in touched files by at least 5. When we started we had like 30k type errors. A year later and it’s about 5k left. This was a small wrapper script over mypy/pyright that just called them twice once on master and once on your branch to compare error counts.

I did occasionally get pushback on it but stricter checks will be inconvenience at first and I argued it’d help over time. Now that we’ve had it a year it’s pretty well accepted in same way many would accept run formatter.

[icedchai]

The problem with these sorts of "rules" is they create needless changes outside of the PR's primary focus. The PR's purpose is to do X: add a feature, fix a bug, whatever. Now because I've done X, you want me to do Y, a set of totally unrelated changes that ultimately are a distraction.

[ok_dad]

Why wouldn’t you submit two different branches to review? One where you fix errors for types and another for the feature with the fixes:

    (git main) > git checkout -b abc-1234/type-fixes
    <do work on types and commit it>
    (git abc-1234/type-fixes) > git checkout -b abc-1234/feature-branch
    <do work on feature and commit it>

Then you can submit the feature branch as a PR on top of the type fixing branch and a PR for that branch to main. You only see the type fixing changes on that PR and only see the feature changes on its PR.

[icedchai]

Seems fine to me, but in my experience these “rules” are often tied to a single PR and various automated CI checks.