OpenWikibiomejs/biome

Overview

Purpose and Scope

Biome is presented in this repository as a web project toolchain rather than as a single-purpose formatter or linter. The package README describes it as a performant toolchain for maintaining project health, with public emphasis on formatting, linting, and a unified developer experience for web languages. That framing matters because most user-facing workflows combine several capabilities: a project installs the distribution package, developers run commands through the binary, configuration coordinates multiple tools, and editor integrations reuse the same language-service behavior. This page gives a first map of those pieces before the narrower guides explain each subsystem in depth.

Sources: packages/@biomejs/biome/README.md, crates/biome_cli/README.md

The root repository README is intentionally minimal and points readers to the package README. That is an important repository signal: the public project introduction lives with the npm distribution package, while the root of the repository acts as the monorepo workspace. The package README is therefore the best entry point for user-facing identity, badges, localization links, and the list of major tool capabilities. The workspace manifests then explain how the implementation is split between Rust crates and JavaScript packages. Reading these files together helps separate the product surface from the build and contributor layout.

Sources: README.md, packages/@biomejs/biome/README.md, package.json, Cargo.toml

Relevant Source Files

  • README.md - A short repository entry that redirects to the package README, showing that public introductory documentation is centered on the distributed package.
  • packages/@biomejs/biome/README.md - The main public README for the npm package, including the “Toolchain of the web” branding, localization links, badges, and the high-level formatter and linter claims.
  • package.json - The JavaScript monorepo manifest, including workspace-level scripts, package-manager and Node requirements, licensing, and release-version tooling.
  • Cargo.toml - The Rust workspace manifest, including crate membership, package metadata, license, repository information, and the internal dependency graph for parsers, formatters, analyzers, diagnostics, configuration, and the CLI.
  • crates/biome_cli/README.md - The CLI crate README, identifying the main binary distribution and noting that it exposes both the command-line interface and the language server interface used by the Visual Studio Code extension.

Product Shape

The package README introduces Biome with a deliberately broad promise: it is a toolchain for web projects that helps maintain the health of those projects. It calls out a fast formatter for JavaScript, TypeScript, JSX, JSON, CSS, and GraphQL, and it also identifies a performant linter across the same web-oriented language family. The README’s badges and links connect the package to continuous integration status, community chat, npm publication, and editor extension distribution. Those visible signals are not implementation details, but they clarify that the project is meant to be consumed from package managers, editors, and automation systems.

Sources: packages/@biomejs/biome/README.md

The official documentation spine uses the same toolchain model. Its configuration guide explains that a Biome configuration is organized around the tools the project provides, especially the formatter, linter, and assist, with shared tool options and language-specific overrides. That terminology is consistent with the repository layout: the Rust workspace includes shared infrastructure crates and language-specific parser, formatter, analyzer, syntax, and semantic crates. The product is therefore easiest to understand as a set of public tools backed by reusable compiler-style infrastructure rather than as independent commands that happen to ship together.

Sources: Cargo.toml, packages/@biomejs/biome/README.md

The repository also preserves Biome’s identity as a multilingual package. The package README includes links to translated README files for many languages, and the badges reference npm and editor marketplaces. For users, that means the canonical public package is designed to be discoverable in the places web developers already install tools. For contributors, it means changes to the main README affect package presentation, not just GitHub browsing. When editing overview or onboarding material, prefer keeping the package README aligned with the official documentation’s first-run narrative and with the capabilities supported by the crates in the workspace.

Sources: packages/@biomejs/biome/README.md, Cargo.toml

Repository and Workspace Layout

The JavaScript manifest identifies the repository as a private monorepo package named for the Biome monorepo, while the Rust manifest defines the implementation workspace. This split reflects the way Biome is developed and distributed. JavaScript packaging provides scripts, release support, workspace dependency management, and the public npm package. Rust crates provide most of the core implementation for parsing, formatting, linting, diagnostics, configuration, file-system interaction, and command execution. A new contributor should expect to move between both ecosystems, but the user-facing binary is still experienced as a single Biome executable.

Sources: package.json, Cargo.toml

The root JavaScript scripts show the repository’s own maintenance workflow. The check and continuous-integration scripts run through the internal CLI development binary, while formatting for repository metadata is handled by a separate formatting command. The version script uses changeset tooling, refreshes the package lockfile, and handles an automated changes stash when present. These scripts are not the same as the public commands documented for end users, but they show how the project dogfoods its CLI and coordinates release preparation inside a workspace that includes both Rust and TypeScript assets.

Sources: package.json

The Rust workspace manifest is the most compact architectural index in the requested evidence. It declares a workspace over crate directories and tool tasks, sets shared package metadata such as edition, homepage, repository, license, keywords, and categories, and then lists many internal crates as workspace dependencies. The names reveal the main layers: analyzer infrastructure, configuration, diagnostics, console rendering, formatter engine, filesystem abstraction, language-specific parsers and formatters, semantic models, syntax crates, and the CLI. This page does not document every crate, but the manifest makes clear that Biome’s public tools are assembled from specialized reusable components.

Sources: Cargo.toml

Public Toolchain Surfaces

For end users, the most visible surface is the npm package. The package README’s language support list makes the formatter and linter feel like first-class tools, while the official docs add configuration, migration, editor, diagnostics, and reference sections around them. The core workflow is straightforward: install Biome, create or adopt a configuration file, run checks or formatting in a terminal, and connect the same behavior to an editor. The overview should be read as the top-level map for that workflow; the command reference and configuration pages then provide the exact options, command families, and configuration fields.

Sources: packages/@biomejs/biome/README.md, package.json

Configuration is central because Biome is intentionally multi-tool. The official configuration guide explains that project settings can be supplied through command-line options or a configuration file, commonly named for Biome and placed near the project package manifest. It also explains that tool sections can be enabled or disabled and that language-specific settings can override shared tool settings. The requested repository files do not contain the schema itself, but they do show why this organization exists: one distribution package and one CLI front end coordinate multiple tools implemented across a broad Rust workspace.

Sources: packages/@biomejs/biome/README.md, Cargo.toml

The CLI crate README defines the binary role in more direct implementation terms. It says the crate is the main binary distribution and exposes the command-line interface. It also notes that the language server interface comes from the language-server crate and is used by the Biome Visual Studio Code extension. This means the executable is not only a batch command runner; it is also the entry point that editor integrations can rely on for long-lived language tooling. That shared entry point is why editor behavior, terminal commands, diagnostics, and configuration resolution must remain consistent across the project.

Sources: crates/biome_cli/README.md

Distribution, Editors, and Runtime Signals

The package README’s badges make the distribution story concrete. Biome is published to npm, advertised with continuous integration status, and linked to extension marketplaces. The CLI README complements that by describing runtime logs for daemon mode. When the server runs as a daemon, it writes logs under a Biome logs directory inside the platform-specific cache location, with a command available to print the precise cache directory and hourly log rotation. Those details belong in the editor and daemon guide, but they are overview-worthy because they show that Biome supports both short-lived command execution and persistent editor services.

Sources: packages/@biomejs/biome/README.md, crates/biome_cli/README.md

This distinction also helps explain troubleshooting paths. If a terminal command fails, users typically inspect command output, configuration, file matching, or diagnostics. If an editor integration behaves differently, the problem may involve the language server process, daemon mode, cache location, logs, or extension packaging. The overview does not need to solve all of those cases, but it should direct readers to the right subsystem. The same binary distribution is involved, yet different runtime modes produce different evidence. The CLI README’s cache and log notes are the first source-backed hint for that separation.

Sources: crates/biome_cli/README.md

How the Official Documentation Maps to the Repository

The official documentation sections can be mapped onto repository concerns without assuming that each section corresponds to a single directory. Guides such as getting started, configuration, and upgrade describe tasks performed with the package and CLI. Formatter and linter pages describe public tools backed by language-specific crates and shared infrastructure. Assist and analyzer topics sit closer to rule actions, diagnostics, suppressions, and code-mod style behavior. Reference pages collect stable option and command surfaces. Editor pages map to the binary and language-server runtime. Internals pages map to the workspace manifest’s many crates and contributor workflows.

Sources: packages/@biomejs/biome/README.md, Cargo.toml, crates/biome_cli/README.md

The upgrade and migration story also fits this map. Official upgrade guidance tells users to install a specific package version and run a migrate command that updates configuration while warning about manual steps when necessary. The requested overview sources only show the package, workspace, and CLI foundations, so detailed migration implementation belongs on the migration page. Still, the overview can explain why migration is part of the same product: a toolchain that owns formatting, linting, assistance, configuration, and editor behavior must provide safe paths for projects to move between versions without treating each feature as a separate product.

Sources: package.json, packages/@biomejs/biome/README.md

Next Steps

Start with the getting-started page if you want install commands and first project usage. Move to the configuration page when you need to decide which tools are enabled, where shared formatting options belong, or how language overrides work. Use the CLI reference for command families, the formatter and linter pages for tool behavior, and the editor page when the language server or daemon is involved. Contributors should then read the internals page to connect the Rust workspace manifest to parsers, formatters, analyzers, diagnostics, and service architecture. This sequence follows the same high-level structure exposed by the package README, workspace manifests, and CLI crate notes.

Sources: packages/@biomejs/biome/README.md, package.json, Cargo.toml, crates/biome_cli/README.md

Ask a question...