Rework project formatting tools.

* Changes JS formatting policy to expect trailing commas in most of the places they're allowed.
* Moves format checking out of `npm` and into tool scripts.
* _Documents_ formatting tools, as well as a shot at a policy for format-only changes designed to alleviate low-value review.

This was originally part of [another proposal][pr-6]. I've broken it out to make the intent clearer, and to make the proposal easier to get a handle on in isolation from other, related changes. Thanks to @wlonk for their input on this!

[pr-6]: https://codeberg.org/ojacobson/pilcrow/pulls/6

Merges prop/project-formatting into main.

1 files changed, 30 insertions, 0 deletions

diff --git a/docs/formatting.md b/docs/formatting.md
new file mode 100644
index 0000000..5339be0
--- /dev/null
+++ b/docs/formatting.md
@@ -0,0 +1,30 @@
+# Formatting
+
+We use automated tools, rather than human effort, to maintain a consistent code formatting convention, where possible. This is handled by two tools:
+
+- Javascript, Markdown, and JSON files are formatted using [prettier].
+- Rust is formatted using [rustfmt].
+
+[prettier]: https://prettier.io
+
+[rustfmt]: https://doc.rust-lang.org/cargo/commands/cargo-fmt.html
+
+## Tools
+
+- To check that code formatting rules are being followed, run
+  `tools/check-format`. This should be run any time you're making changes, and is part of the optional
+  `git-hooks/pre-commit` hook script.
+
+- To reformat the whole project, run `tools/reformat`.
+
+You can also run the individual formatting tools directly. The tool scripts listed above contain the specific commands needed.
+
+## Formatting and code review
+
+Checking in changes produced solely using
+`tools/reformat` or its constituent commands doesn't require review if it's the only thing you're doing. We assume that these tools make sound changes, and that the code style configured for the project is acceptable by default.
+
+However, formatting changes carry an outsized risk of merge conflicts, so they almost always require
+_coordination_. This risk is more severe for larger formatting changes. If you make a formatting fix, it's incumbent on you to follow up on it and to assist other developers with conflicts.
+
+In general, we try to avoid these by fixing formatting issues before they pile up, but if you plan to commit a formatting fix, please check for outstanding work that may conflict with it. You may even want to delay or rescope formatting fixes to accommodate others' in-progress changes.