GO — Healthy across the board

• Used by 1 trusted project: vercel/turbo
• Last commit today
• 17 active contributors
• Distributed ownership (top contributor 31% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Biome is a unified toolchain for web projects written primarily in Rust, combining a formatter and linter accessible via CLI and LSP. It provides JavaScript/TypeScript code formatting and linting capabilities as a faster, more opinionated alternative to Prettier + ESLint, with semantic analysis enabled by CST parsing and control flow analysis. Monorepo workspace with crates/ containing language-specific modules (biome_js_parser, biome_css_formatter, biome_html_parser, etc.), xtask/ for code generation and CI tooling, and packages/@biomejs/biome as the npm distribution. Core architecture separates parsing (CST), semantic analysis (biome_analyze with macros), formatting (IR-based), and linting (rule engine) into distinct crates.

Web developers and CI/CD pipelines that want a single, zero-configuration tool to format and lint JavaScript, TypeScript, CSS, HTML, Vue, Svelte, and Astro files—particularly teams seeking faster formatting than Prettier and more comprehensive linting than single-purpose tools.

Biome is actively developed and production-ready. The codebase shows mature engineering practices with versioning (0.5.7+), extensive test coverage via changeset entries, and comprehensive multi-language support (JS/TS/CSS/HTML/Vue/Svelte/Astro). The 22.6M lines of Rust code and organized monorepo structure indicate an established project, though the sub-1.0 version suggests ongoing API refinement.

Moderate risk: the sub-1.0 version (0.5.7) indicates breaking changes may still occur, as evidenced by multiple changeset entries for lint rule property changes. The heavy Rust dependency chain and reliance on custom parser infrastructure (biome_parser, biome_syntax crates) means ecosystem lock-in. Single-language maintainability could be challenging given the volume of Rust code, though the project appears well-resourced.

Active development on lint rules and configuration. Recent changesets show ongoing work on rule improvements (use-test-hooks-in-order, no-misleading-return-type-as-const-property), readonly property handling in classes, type conversion rules, and exhaustive switch case checking. The presence of 13+ active changesets and agent files (.claude/agents/) suggests coordinated feature development.

git clone https://github.com/biomejs/biome.git
cd biome
cargo build --release
./target/release/biome --version

For npm package development: cd packages/@biomejs/biome && npm install && npm run build

Daily commands: Development: cargo build compiles the Rust core to target/debug/biome. For CLI testing: ./target/debug/biome format --help. For LSP: binaries expose a language server via stdin/stdout. Node.js binding is published as npm package @biomejs/biome with prebuilt binaries.

• Cargo.toml — Workspace manifest defining all crates, dependencies, and member organization; essential for understanding project structure and build configuration.
• .biome.json — Biome's own configuration file demonstrating the formatter/linter capabilities and serving as the reference config for all users.
• crates/biome_analyze — Core linting engine implementing rule logic and analysis; central to understanding how diagnostics are generated.
• CONTRIBUTING.md — Developer guidelines covering PR workflows, testing, and contribution patterns specific to this Rust-based monorepo.
• .claude/skills/lint-rule-development/SKILL.md — Comprehensive guide to adding new lint rules, including code generation workflows and testing conventions.
• .github/workflows/main.yml — Primary CI/CD pipeline orchestrating tests, builds, and releases across all workspace crates.

• Parser (biome_parser, biome_js_parser, etc.) (Rust, hand-written recursive descent parser, CST data structures) — Convert source code into concrete syntax tree (CST), detect and report syntax errors with precise locations, maintain parent/sibling pointers for traversal.
  • Failure mode: Syntax errors logged as diagnostics; parsing failure should not crash; malformed code still produces partial CST for error recovery.
• Analyzer (biome_analyze) (Rust, visitor pattern, rule registry macro, semantic analysis) — Visit CST nodes, evaluate rule conditions, emit rule violations with fix suggestions, apply auto-fixes to source via text edits.
  • Failure mode: Rule panics caught at rule level; invalid fix suggestions prevent application; rules that fail gracefully degrade to warnings only.
• Formatter (biome_formatter) (Rust, IR builder pattern, multipass formatting) — Transform CST into intermediate representation (IR), apply formatting decisions (whitespace, line breaks, indentation), emit formatted code.
  • Failure mode: Formatting failures prevent output; formatter must preserve AST semantics (no code alteration).
• CLI (biome_cli) (Rust, clap argument parser, exit codes) — Parse command-line arguments, load configuration, orchestrate parser→analyzer→formatter pipeline, emit diagnostics and formatted output to stdout/files.
  • Failure mode: Invalid CLI args show usage; file I/O errors reported to user; non-zero exit on failures.
• LSP Server (biome_lsp) — Implement Language Server Protocol, handle editor notifications and requests, run analysis on file changes, stream diagnostics back to editor.

Add a New Lint Rule

1. Create rule struct with diagnostic metadata in crates/biome_analyze/src/rules/ (crates/biome_analyze/src/rules/[category]/[rule_name].rs)
2. Implement RuleVisitor trait for AST traversal and violation detection (crates/biome_analyze/src/rules/[category]/[rule_name].rs)
3. Register rule in crates/biome_analyze/src/registry.rs macro invocation (crates/biome_analyze/src/registry.rs)
4. Add test snapshots and spec file in crates/biome_analyze/tests/specs/ (crates/biome_analyze/tests/specs/[category]/[rule_name]/spec.json)
5. Run codegen to auto-generate configuration and documentation (xtask/codegen)

Add Support for a New Language

1. Create language-specific parser crate in crates/biome_[lang]_parser/ (crates/biome_[lang]_parser/src/lib.rs)
2. Implement syntax module with SyntaxKind enum and node types (crates/biome_[lang]_parser/src/syntax/mod.rs)
3. Register parser in biome_parser_dispatcher or CLI language detection (crates/biome_cli/src/parser.rs)
4. Add formatter implementation in crates/biome_formatter for the language (crates/biome_formatter/src/[lang]/mod.rs)

Add a New CLI Command or Flag

1. Define command struct with clap attributes in crates/biome_cli/src/commands/ (crates/biome_cli/src/commands/[command_name].rs)
2. Implement execute method calling analyzer, formatter, or linter pipelines (crates/biome_cli/src/commands/[command_name].rs)
3. Register command in main command dispatcher in crates/biome_cli/src/main.rs (crates/biome_cli/src/main.rs)
4. Add integration tests in crates/biome_cli/tests/ (crates/biome_cli/tests/[command_name].rs)

• Rust — Provides memory safety, zero-cost abstractions, and high performance for AST traversal and code transformation; enables fast CLI and LSP implementation.
• Procedural Macros (biome_analyze_macros) — Enables declarative rule registration and auto-generation of configuration schemas and documentation at compile time without runtime overhead.
• Workspace Monorepo (Cargo workspaces) — Allows modular crate organization (parser, analyzer, formatter, CLI, LSP) with shared dependencies and unified versioning.
• LSP (Language Server Protocol) — Provides IDE-agnostic integration for real-time diagnostics and formatting across VS Code, Neovim, Helix, and other editors.

• Implement own parser instead of using tree-sitter

  • Why: Full control over error recovery, better diagnostics, tighter integration with rules, and avoids external binary dependency.
  • Consequence: Higher maintenance burden for parser updates and multi-language support; must keep language grammars in sync.

• Monolithic rule registry with procedural macro generation

  • Why: Type-safe rule management, zero-cost abstraction, and automatic docs/config generation at compile time.
  • Consequence: Rules cannot be dynamically loaded at runtime; users must rebuild to add custom rules.

• IR-based formatting (not direct token rewriting)

  • Why: Decouples formatting logic from AST changes and enables consistent multi-pass transformations.
  • Consequence: Slightly higher memory overhead during formatting; more indirection layers.

• Dynamic plugin system or runtime rule loading (rules are compiled into the binary)
• Real-time continuous background checking without explicit command invocation
• Cross-platform GUI application (CLI and LSP only)
• Custom language grammar DSL (must use Rust code for parser implementation)
• Package manager or dependency resolution (linter/formatter only, not a bundler)

Rust edition 2024: Workspace uses edition = "2024" which is very recent; ensure Rust nightly or very recent stable. Changeset-based releases: Do not edit versions directly; use changeset CLI for versioning. Macro-heavy rule system: Lint rules are defined via biome_analyze_macros derives; raw rule code won't compile without proper macro invocation. Language parity: Each language (JS/CSS/HTML) has separate parser/formatter/analyzer crates; a feature may need implementation in multiple crates. LSP server setup: Running the LSP requires specific stdin/stdout protocol handling; not a standard HTTP server.

• Concrete Syntax Tree (CST) — Biome parses into CST (preserving whitespace/comments) rather than AST; critical to understand why formatting and error recovery work differently than traditional parsers
• Intermediate Representation (IR) Formatting — Biome converts CST to an IR before formatting; understanding this pipeline explains how consistent formatting is achieved across all languages without duplicating logic
• Control Flow Graph (CFG) — Used in biome_control_flow for semantic linting (detecting unreachable code, variable flow); essential for understanding advanced rule logic
• Language Server Protocol (LSP) — Biome exposes linting/formatting via LSP for IDE integration; understanding LSP is needed to contribute to the language server implementation
• Proc Macros in Rust — biome_analyze_macros heavily uses procedural macros to generate rule boilerplate; understanding Rust macro system is essential for adding new lint rules
• Semantic Analysis — Biome performs scope analysis and type-aware checking beyond syntax; the biome_*_semantic crates enable rules that catch real logic errors, not just style issues
• Monorepo Workspace Management — Cargo workspace with interdependent crates and shared configuration; understanding workspace conventions is critical for navigating and modifying the project structure

• prettier/prettier — Direct competitor in code formatting space; Biome positioning is 'faster Prettier with linting included'
• eslint/eslint — Linting standard that Biome rules are often compared against; many Biome rules are ESLint rule migrations
• rust-analyzer/rust-analyzer — Inspiration for LSP-first architecture and semantic analysis patterns used in Biome's control flow and type checking
• tree-sitter/tree-sitter — Alternative parser infrastructure; Biome implements its own CST parsers but tree-sitter is comparable multi-language parsing approach
• oxc-project/oxc — Companion Rust-based JavaScript toolchain (parser + minifier); shares similar architectural goals of replacing JavaScript tooling with Rust

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for Changeset workflow automation

The .changeset/ directory contains 13+ changeset files but there's no visible test coverage for the changeset validation, parsing, and version bump logic. This is critical for a monorepo with multiple crates (biome_analyze, biome_css_parser, biome_deserialize, etc.) to prevent accidental version mismatches or invalid changelog entries. A new contributor could add tests that verify: (1) changeset schema validation against .changeset/config.json, (2) proper version bumping across workspace members, and (3) detection of missing changesets for modified crates.

• [ ] Review .changeset/config.json to understand the changeset schema and validation rules
• [ ] Create crates/biome_configuration/tests/changeset_validation_test.rs (or similar) to test parsing of .changeset/*.md files
• [ ] Add tests verifying that each modified crate in [workspace.members] from Cargo.toml has a corresponding changeset entry
• [ ] Add CI workflow trigger in .github/workflows/ to run changeset tests on PRs that modify crate versions or changelog files

Implement missing LSP diagnostic tests for CSS and formatter rules

The repo has biome_css_analyze, biome_css_semantic, and multiple formatter crates listed in workspace dependencies, but there's no visible comprehensive test suite demonstrating LSP diagnostic output (error/warning messages) for CSS rules. This gap makes it hard for contributors to validate new CSS linting rules or formatter edge cases. A contributor could add parameterized tests that verify LSP diagnostic JSON output format, error ranges, and suggested fixes for each CSS rule defined in biome_css_analyze.

• [ ] Examine existing lint rule tests in crates/biome_analyze/ to understand the test pattern
• [ ] Create crates/biome_css_analyze/tests/lsp_diagnostics.rs with test cases for each CSS rule (e.g., validating diagnostic.message, diagnostic.range, diagnostic.suggestions)
• [ ] Add snapshot tests using insta crate to capture LSP JSON output for various CSS syntax violations
• [ ] Document the LSP diagnostic test pattern in .claude/skills/lint-rule-development/SKILL.md for future contributors

Add compiler span/location tracking tests for parser recovery scenarios

The .claude/skills/cst-parser-engineer.md and .claude/skills/parser-development/SKILL.md exist but there's no visible test coverage for how the parser handles malformed input and reports error locations (spans). Given Biome parses multiple languages (JS, CSS, etc.) with biome_*_parser crates, a new contributor could add stress tests verifying that error recovery doesn't produce incorrect span ranges, which is critical for LSP clients to highlight errors correctly in editors.

• [ ] Review crates/biome_parser/ to understand the span/range data structures
• [ ] Create crates/biome_parser/tests/span_accuracy_test.rs with malformed input samples (unclosed tags, invalid syntax, etc.)
• [ ] Verify that reported error spans match the actual problem location and don't overlap incorrectly
• [ ] Add property-based tests using proptest crate to generate random malformed code and verify spans never exceed input length

• Add missing test coverage for CSS semantic analysis (crates/biome_css_semantic/src is versioned 0.0.0, suggesting incomplete implementation); write integration tests comparing CSS output against known good formatting examples.
• Document the CST node structure for HTML parsing (crates/biome_html_parser); create a reference guide in .claude/skills/ showing how to add a new HTML lint rule (similar to existing lint-rule-development skill).
• Implement exhaustive match checking for switch statements in Svelte files (most rules focus on JS/TS); extend biome_analyze rule examples to cover Svelte-specific edge cases with 3-5 test files.

The Biome project demonstrates good security hygiene for an open-source toolchain. No critical or high-severity vulnerabilities were identified in the static configuration analysis. The codebase uses standard Rust tooling (Cargo), dual-licensed terms, and organized GitHub Actions workflows. Primary recommendations: (1) Implement continuous dependency scanning via 'cargo audit' in CI/CD; (2) Enforce secrets management for GitHub Actions workflows; (3) Maintain security reviews during PR processes, especially for parser and formatter code that processes user input; (4) Regularly audit transitive dependencies for known vulnerabilities. The project's focus on linting and formatting makes it lower-risk for data exfiltration concerns, but input validation and processing logic should be security-reviewed given its nature as a code analysis tool.

• Low · Broad License Terms — Cargo.toml workspace.package.license. The project uses dual licensing (MIT OR Apache-2.0), which is permissive. While not a vulnerability per se, it means the code could be used in proprietary contexts with minimal restrictions. Fix: This is acceptable for open-source projects. Ensure license headers are present in source files if strict compliance is needed.
• Low · Public Repository Configuration — .github/workflows/. The repository is public on GitHub with multiple GitHub Actions workflows visible. This is standard for open-source projects but requires careful attention to CI/CD secrets management. Fix: Ensure all CI/CD workflows use GitHub Secrets for sensitive data (API keys, tokens). Review workflow files for hardcoded credentials or overly permissive permissions.
• Low · Development Dependencies Without Version Pinning — Cargo.toml workspace.dependencies section. The Cargo.toml shows workspace dependencies with flexible versions (e.g., 'anyhow = 1.0.102'). While patch versions are specified, minor/major updates could introduce vulnerabilities. Fix: Regularly run 'cargo audit' and 'cargo update' with security reviews. Consider using a dependency scanning tool in CI/CD pipelines.
• Low · Changeset Files in Version Control — .changeset/. The .changeset directory contains human-readable changelog entries. While not inherently a security issue, ensure no sensitive information is committed in these files. Fix: Implement pre-commit hooks to prevent accidental commits of sensitive data. Review changeset entries during PR reviews.
• Low · Claude AI Configuration Files Present — .claude/. The .claude directory contains AI agent and skill configuration files. While configuration files themselves aren't a vulnerability, they may reflect tool usage that could inadvertently process sensitive code. Fix: Review what code and context is shared with AI tools. Ensure no production secrets or authentication tokens are included in prompts or context passed to AI systems.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/biomejs/biome shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live biomejs/biome repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/biomejs/biome.

What it runs against: a local clone of biomejs/biome — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in biomejs/biome | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of biomejs/biome. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/biomejs/biome.git
#   cd biome
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of biomejs/biome and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "biomejs/biome(\\.git)?\\b" \\
  && ok "origin remote is biomejs/biome" \\
  || miss "origin remote is not biomejs/biome (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f ".biome.json" \\
  && ok ".biome.json" \\
  || miss "missing critical file: .biome.json"
test -f "crates/biome_analyze" \\
  && ok "crates/biome_analyze" \\
  || miss "missing critical file: crates/biome_analyze"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f ".claude/skills/lint-rule-development/SKILL.md" \\
  && ok ".claude/skills/lint-rule-development/SKILL.md" \\
  || miss "missing critical file: .claude/skills/lint-rule-development/SKILL.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/biomejs/biome"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.