[makerdiety]

> Most places I've worked in the last 6 or so years are obsessed with tooling and add so many lint rules that it's often impossible to merge your pull request if you decide to format your code in a way that violates the rules in some trivial way.

Shouldn't all the lines of code uploaded in a pull request be automatically formatted into the coding style preferred by the reviewer anyway? It should be like an automatic translation done by some bot or something.

[sokoloff]

That desire is in conflict with a desire for the reviewer to see only the changes and many of the diff tools don’t diff this reformatted code against that reformatted code but rather work on the pre-reformatted.

It could obviously be done, but involves a yak shave that isn’t clear that it brings enough value to be worthwhile.

[swader999]

That's my main concern, I want to review the changes, not formatting opinions.

[worik]

I do not get it.

If it is formatted to the formatting rules before every commit, how can there ever be formatting opinions?

What am I missing?

[wombat-man]

We can't check in anything that fails the linter, but we can also automatically format the code very easily.

[vbezhenar]

What bot? You create a branch, you push button in github UI, merge request is created. There's no bot.

[Shacklz]

It's not a bot but formatters like prettier for example make it very easy to set them up as git-hooks, where the formatter is applied on commit. Meaning, unless you specifically commit without hooks, all committed code should comply with the formatter.

For linting (e.g. eslint in the JS-space), this is also possible, however, most linting-processes tend to run just long enough to be annoying when run on every commit. In the monorepo I work on we created a command "prep-pr" which specifically addresses this issue - run it before creating a PR, and the CI-pipeline will mostly be green, at least in terms of linting/unit-testing.