CodeVetter · Repo Unpack · Behavior traces
biomejs/biome
Three load-bearing flows are process startup into the CLI dispatcher, a check/lint pass over a project, and configuration plus fix persistence. A fourth adjacent flow is LSP or daemon startup, which reuses WorkspaceServer instead of one-shot CLI traversal. Function names below are the ones present in the crates read for this brief.
- Startup: main in crates/biome_cli/src/main.rs reads BIOME_LOG_PATH, optionally initializes a log file, then calls biome_cli::run_server (or the pavilion entry used by the binary). Panic hook is installed before argument parsing.
- Parse step inside a language handler: the file handler calls the language parser (for JS, parse_module or parse_script in biome_js_parser), producing a Parse result that carries both the CST and parse diagnostics.
- Lint step: the analyzer pulls rules from the language registry (for example biome_js_analyze::rules), filters by configuration severity and nursery or recommended sets, then visits the tree. Matching rules call diagnose.
- Format step: the language formatter builds a FormatElement IR from the CST and prints it with biome_formatter::Printed. If the printed text differs, a format diagnostic or write-back is produced.
- Persistence of fixes: when --write or --fix is set, the workspace applies text edits and calls FileSystem::open or write. Without those flags the process only reports. Configuration itself is not rewritten except by biome init and biome migrate.
- Init flow: biome init detects an existing config, prompts or writes biome.json with default formatter and linter sections, and can import from Prettier or ESLint when migrate is used instead.
- Migrate flow: read the foreign config (eslint.config or .eslintrc, prettier), map rules through generated and hand-written converters, emit a Biome configuration and a report of unmapped rules.