* Replace `package-lock.json` with `pnpm-lock.yaml` * Update `package.json` * Update `lefthook.yml` * Update GitHub workflows * Update references to `npm`/`npx` * Update `CONTRIBUTING.md` * Update `linting.md` and `comments.md` * Update comment in `create-test.js` * Add missing dependency `chalk` for `create-test.js`
3.4 KiB
Linting & Formatting
Writing clean, readable code is important, and linters and formatters are an integral part of ensuring code quality and readability. It is for this reason we are using Biome, an opinionated linter/formatter (akin to Prettier) with a heavy focus on speed and performance.
Installation
You probably installed Biome already without noticing it - it's included inside package.json
and should've been downloaded when you ran pnpm install
after cloning the repo. If you haven't done that yet, go do it.
Using Biome
For the most part, Biome attempts to stay "out of your hair", letting you write code while enforcing a consistent formatting standard and only notifying for errors it can't automatically fix.
On the other hand, if Biome complains about a piece of code, there's probably a good reason why. Disable comments should be used sparingly or when readabilty demands it - your first instinct should be to fix the code in question, not disable the rule.
Editor Integration
Biome has integration with many popular code editors. See these pages for information about enabling Biome in your editor of choice.
Automated Runs
Generally speaking, most users shouldn't need to run Biome directly; in addition to editor integration, pre-commit hook will periodically run Biome before each commit.
You will not be able to push code with error
-level linting problems - fix them beforehand.
We also have a Github Action to verify code quality each time a PR is updated, preventing bad code from inadvertently making its way upstream.
Running Biome via CLI
If you want Biome to check your files manually, you can run it from the command line like so:
pnpm exec biome check --[flags]
A full list of flags and options can be found on their website, but here's a few useful ones to keep in mind:
--write
will cause Biome to write all "safe" fixes and formatting changes directly to your files (rather than just complaining and doing nothing).--changed
and--staged
will only perform checks on all changed or staged files respectively. Biome sources this info from the relevant version control system (in this case Git).diagnostic-level=XXX
will only show diagnostics with at least the given severity level (info/warn/error
). Useful to only focus on errors causing a failed workflow run or similar.
Linting Rules
We primarily use Biome's recommended ruleset for linting JS/TS, with some customizations to better suit our project's needs1.
Some things to consider:
- We have disabled rules that prioritize style over performance, such as
useTemplate
. - Some rules are currently disabled or marked as warnings (
warn
) to allow for gradual refactoring without blocking development. Do not write new code that triggers these warnings. - The linter is configured to ignore specific files and folders (such as excessively large files or ones in need of refactoring) to improve performance and focus on actionable areas.
Any questions about linting rules should be brought up in the #dev-corner
channel in the discord.
-
A complete list of rules can be found in the
biome.jsonc
file in the project root. ↩︎