There's a bit of an issue with the concept behind this module (as much as I love it!), in that Prettier always steps up to reformat the entire enclosing statement (which, of course, makes sense: it can't print a partial AST node.)
Here's an example:
class Foo {
// ...
function blubber() {
console.log("Awww!")
}
// ...
}
If I modify the name of that function, then technically, the entire class statement needs to be reformatted.
This limitation, being inherent to the process and methodology, is something that a human is probably going to need to guard against. However, part of the point of precise-commits, at least from where I'm standing, is to make the size of the user's diffs less of a concern while they're working on an in-transition-to-prettier codebase — right?
Here's the solution I suggest: simply count the number of lines changed by the user (something precise-commits is already aware of); then count the number changed after applying the prettier change. Report the difference. (Or both numbers?) That way, if the user changed one line of code, reasonably expecting the project's tooling to only reformat that one line, they'll be made aware when a pathological case like the above has inflated their diff to thousands upon thousands of lines of change.
(If you're feeling generous with your API surface and featureset, perhaps even offer a --limit-additional-changes= option, that will cause precise-commits to exit with an erroneous exit-status if it ends up having to reformat too much additional code, for those of us using pre-commit hooks and CI-checks?)
There's a bit of an issue with the concept behind this module (as much as I love it!), in that Prettier always steps up to reformat the entire enclosing statement (which, of course, makes sense: it can't print a partial AST node.)
Here's an example:
If I modify the name of that function, then technically, the entire
classstatement needs to be reformatted.This limitation, being inherent to the process and methodology, is something that a human is probably going to need to guard against. However, part of the point of
precise-commits, at least from where I'm standing, is to make the size of the user's diffs less of a concern while they're working on an in-transition-to-prettiercodebase — right?Here's the solution I suggest: simply count the number of lines changed by the user (something
precise-commitsis already aware of); then count the number changed after applying the prettier change. Report the difference. (Or both numbers?) That way, if the user changed one line of code, reasonably expecting the project's tooling to only reformat that one line, they'll be made aware when a pathological case like the above has inflated their diff to thousands upon thousands of lines of change.(If you're feeling generous with your API surface and featureset, perhaps even offer a
--limit-additional-changes=option, that will causeprecise-commitsto exit with an erroneous exit-status if it ends up having to reformat too much additional code, for those of us using pre-commit hooks and CI-checks?)