Biome Formatting Configuration for TypeScript Monorepos

The decision: formatter strictness in a TypeScript monorepo

A TypeScript monorepo often contains applications and libraries that were initialized at different times. One package uses double quotes, another uses single quotes; one team runs Prettier on save, another relies on editor defaults. Continuous integration either lacks a formatting gate or enforces rules inconsistently across folders.

Useful takeaway: start with Biome's recommended preset as the repository baseline, apply strict or custom overrides only where a package genuinely needs them, and validate on a single package before enabling the configuration repository-wide.

Constraints to set first

• Repository shape: a monorepo is a single Git repository containing multiple packages or applications, often managed by a workspace tool such as npm workspaces, pnpm, or Yarn.
• Language: TypeScript source files, usually under apps/ and packages/.
• Existing tooling: decide whether Biome replaces Prettier and ESLint or runs alongside them.
• CI performance: incremental parsing means Biome re-parses only changed files, but the first full run on a large repository takes longer.

Supported configuration presets

Preset	Enforces	Typical use	Main risk
recommended	Core formatting and lint rules maintained by Biome	Teams adopting Biome without auditing every rule	May flag legacy code that predates the configuration
strict	recommended plus additional opinionated rules	Greenfield TypeScript projects wanting maximum consistency	Higher false-positive rate on existing codebases
custom overrides	A baseline preset with rule-level changes and per-directory exceptions	Monorepos where apps and packages need different rules	More configuration to maintain and review
Formatter only	Code formatting without lint rules	Migrating from Prettier while keeping an existing linter	No lint safety net for suspicious code

Trade-offs

recommended balances consistency and adoption speed. It is the safest starting point for a brownfield monorepo because it avoids the noise of opinionated rules that have no consensus in your team.

strict improves uniformity but generates more diagnostics on existing code. Expect to spend time fixing or suppressing violations before CI passes.

Custom overrides let you treat apps/ and packages/ differently. For example, you might enforce stricter import ordering in libraries than in applications. The cost is a larger biome.json that reviewers must understand.

Formatter-only mode preserves formatting while leaving linting to another tool. This is useful during migration, but it means Biome will not catch unused variables or suspicious any usage.

Example configuration for a monorepo

Run the following commands in the repository root. You need read permission for biome.json and write permission for the files Biome formats.

{
  "$schema": "https://biomejs.dev/schemas/VERSION/schema.json",
  "formatter": {
    "indentStyle": "tab",
    "lineWidth": 100
  },
  "linter": {
    "rules": {
      "recommended": true
    }
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "double",
      "semicolons": "always"
    }
  },
  "ignorePatterns": [
    "node_modules/",
    "dist/",
    "apps/*/dist/",
    "packages/*/dist/"
  ],
  "files": {
    "ignore": ["**/*.generated.ts"]
  }
}

Replace VERSION in the schema URL with the value matching your installed Biome version. The ignorePatterns array tells Biome which paths to skip; this field changed in Biome v1.0+, so verify the spelling against your version's documentation before committing.

To apply different rules to a specific package, add an override block after the top-level settings. Biome evaluates overrides by path, so a rule disabled for packages/legacy/ does not affect apps/web/.

Validate the configuration

1. Check the installed version:

biome --version

Expected: a version string such as v1.x.x. If the command is not found, install Biome or add it to your package manager's workspace dependencies.

1. Pick a low-risk test file, for example packages/example/src/index.ts.
2. Run Biome in write mode:

biome check packages/example/src/index.ts --write

Expected: Biome rewrites the file to match the configuration and exits with a status code indicating whether issues were found. The command overwrites local edits in that file, so commit or stash uncommitted work first.

1. Inspect the result:

git diff --stat packages/example/src/index.ts

If the diff shows only formatting changes you accept, run the check across one package:

biome check packages/example --write

Then add biome check to your CI pipeline so pull requests fail when formatting or lint rules are violated.

Limitations and version checks

• Biome v1.0+ changed the schema for ignorePatterns. Older configuration files may produce schema errors. Run biome check after upgrading and consult the changelog for your version.
• Prebuilt Biome binaries may not support older Node.js versions or uncommon CPU architectures. Verify the binary runs in your CI container before relying on it.
• Rule disabling through package.json applies only when using the --config CLI flag; confirm this behavior in your installed version because CLI behavior can change between releases.
• Biome's formatter handles style, not architecture. It will not enforce module boundaries or dependency rules; use the linter or a separate architecture tool for those concerns.

Rollback

Editing biome.json and running --write changes repository state. To revert:

git checkout -- biome.json
git checkout -- packages/example/src/index.ts

Replace the second path with any file Biome modified during testing. If you already committed the configuration, create a revert commit rather than force-pushing.