o1-labs / o1-labs/Archive-Node-API

Prettier is not enforced in CI, and main currently fails its own format check (5 files)

Open
#212 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug P2 production-readiness
Dominant language
TypeScript
Stars
19
Forks
9
Avg merge
14h 20m
Merged PRs (30d)
8

Description

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

  • npx prettier --check . exits 0 on main
  • npm run format:check exists and is invoked by the Linting workflow
  • A PR that introduces misformatted TypeScript fails the required Linting check

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with package.json, .github/workflows/lint.yaml, and .prettierignore; run the pinned Prettier check to confirm the five listed files and review ignore coverage. Apply the existing formatting configuration, add the format-check script and workflow step, then verify that the check passes on main and fails for misformatted TypeScript.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, typescript
Domain
ci-cd, tooling
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.