Problem
main currently fails the repository's own pinned Prettier configuration, and CI cannot detect it.
$ npx prettier@3.0.3 --check "src/**/*.ts"
Checking formatting...
[warn] src/db/archive-node-adapter/archive-node-adapter.interface.ts
[warn] src/db/sql/events-actions/queries.ts
[warn] src/services/actions-service/actions-service.ts
[warn] src/services/blocks-service/blocks-service.ts
[warn] src/services/network-service/network-service.ts
[warn] Code style issues found in 5 files. Run Prettier to fix.
The cause is that formatting is never verified anywhere in CI:
"lint": "eslint . --ext .ts", // eslint only — no prettier
"format": "prettier --write ." // --write, never --check
The Linting workflow — one of only two required status checks — runs npm run lint, so it exercises ESLint alone. npm run format rewrites files rather than asserting anything, so it is useless as a gate and nobody runs it in CI.
Why this matters
Because drift is invisible, it accumulates and then surfaces as noise inside unrelated PRs. This already happened: #134 contains reformatting hunks in src/db/sql/events-actions/queries.ts that look like unrelated churn but are actually a correction — that file fails --check on main and passes on the branch. Reviewers cannot distinguish "the author reformatted things gratuitously" from "the author fixed pre-existing drift" without running Prettier by hand on both sides.
This is low severity but it taxes every review.
Proposed resolution
Step 1 — fix the existing drift in its own commit, so it never has to ride along in a feature PR:
npx prettier --write .
git add -A && git commit -m "style: apply prettier to the current tree"
Note that #134 already fixes queries.ts. Either land #134 first and reformat the remaining four files, or reformat all five and let #134's hunks resolve to a no-op. Landing #134 first is simpler.
Step 2 — add a --check script:
"format": "prettier --write .",
"format:check": "prettier --check ."
Step 3 — enforce it in the Linting workflow. Add a step to .github/workflows/lint.yaml after the existing lint step:
- name: Check formatting
run: npm run format:check
Adding it to the existing Linting job rather than creating a new workflow means it is covered by the already-required Linting status check, with no branch-protection change needed.
Sequencing
Do this after the production-readiness PR batch has merged (see #211). Reformatting the tree now would conflict with roughly a dozen open PRs for no benefit. .prettierignore already exists and should be reviewed for whether build/ and node_modules/ are covered before the sweep.
Acceptance criteria
Problem
maincurrently fails the repository's own pinned Prettier configuration, and CI cannot detect it.The cause is that formatting is never verified anywhere in CI:
The
Lintingworkflow — one of only two required status checks — runsnpm run lint, so it exercises ESLint alone.npm run formatrewrites files rather than asserting anything, so it is useless as a gate and nobody runs it in CI.Why this matters
Because drift is invisible, it accumulates and then surfaces as noise inside unrelated PRs. This already happened: #134 contains reformatting hunks in
src/db/sql/events-actions/queries.tsthat look like unrelated churn but are actually a correction — that file fails--checkonmainand passes on the branch. Reviewers cannot distinguish "the author reformatted things gratuitously" from "the author fixed pre-existing drift" without running Prettier by hand on both sides.This is low severity but it taxes every review.
Proposed resolution
Step 1 — fix the existing drift in its own commit, so it never has to ride along in a feature PR:
Note that #134 already fixes
queries.ts. Either land #134 first and reformat the remaining four files, or reformat all five and let #134's hunks resolve to a no-op. Landing #134 first is simpler.Step 2 — add a
--checkscript:Step 3 — enforce it in the
Lintingworkflow. Add a step to.github/workflows/lint.yamlafter the existing lint step:Adding it to the existing
Lintingjob rather than creating a new workflow means it is covered by the already-requiredLintingstatus check, with no branch-protection change needed.Sequencing
Do this after the production-readiness PR batch has merged (see #211). Reformatting the tree now would conflict with roughly a dozen open PRs for no benefit.
.prettierignorealready exists and should be reviewed for whetherbuild/andnode_modules/are covered before the sweep.Acceptance criteria
npx prettier --check .exits 0 onmainnpm run format:checkexists and is invoked by theLintingworkflowLintingcheck