home / skills / thebushidocollective / han / biome-linting

This skill helps you enforce Biome linting for JavaScript and TypeScript projects, improving correctness, security, and performance through automated checks.

npx playbooks add skill thebushidocollective/han --skill biome-linting

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
12.6 KB
---
name: biome-linting
user-invocable: false
description: Use when applying Biome's linting capabilities, rule categories, and code quality enforcement to JavaScript/TypeScript projects.
allowed-tools: [Read, Write, Edit, Bash, Glob, Grep]
---

# Biome Linting

Expert knowledge of Biome's linting capabilities, rule categories, and code quality enforcement for JavaScript and TypeScript projects.

## Overview

Biome's linter provides fast, comprehensive code quality checks with a focus on correctness, performance, security, and best practices. It's designed to catch common bugs and enforce consistent code patterns.

## Core Commands

### Basic Linting

```bash
# Check files without fixing
biome check .

# Check and auto-fix
biome check --write .

# Check specific files
biome check src/**/*.ts

# CI mode (strict, fails on warnings)
biome ci .
```

### Command Options

```bash
# Verbose output
biome check --verbose .

# JSON output
biome check --json .

# Only lint (skip formatting)
biome lint .

# Apply safe fixes only
biome check --write --unsafe=false .
```

## Rule Categories

### Accessibility (a11y)

Rules for web accessibility and WCAG compliance:

```json
{
  "linter": {
    "rules": {
      "a11y": {
        "recommended": true,
        "noAccessKey": "error",
        "noAriaHiddenOnFocusable": "error",
        "noAutofocus": "warn",
        "noBlankTarget": "error",
        "noPositiveTabindex": "error",
        "useAltText": "error",
        "useAnchorContent": "error",
        "useButtonType": "error",
        "useValidAriaProps": "error"
      }
    }
  }
}
```

Common violations:

- Missing alt text on images
- Autofocus on form elements
- Positive tabindex values
- Links without content
- Invalid ARIA properties

### Complexity

Rules to reduce code complexity:

```json
{
  "linter": {
    "rules": {
      "complexity": {
        "recommended": true,
        "noBannedTypes": "error",
        "noExcessiveCognitiveComplexity": "warn",
        "noExtraBooleanCast": "error",
        "noMultipleSpacesInRegularExpressionLiterals": "error",
        "noUselessCatch": "error",
        "noUselessConstructor": "error",
        "noUselessEmptyExport": "error",
        "noUselessFragments": "error",
        "noUselessLabel": "error",
        "noUselessRename": "error",
        "noUselessSwitchCase": "error",
        "noWith": "error"
      }
    }
  }
}
```

### Correctness

Rules for code correctness and bug prevention:

```json
{
  "linter": {
    "rules": {
      "correctness": {
        "recommended": true,
        "noChildrenProp": "error",
        "noConstAssign": "error",
        "noConstantCondition": "error",
        "noConstructorReturn": "error",
        "noEmptyPattern": "error",
        "noGlobalObjectCalls": "error",
        "noInnerDeclarations": "error",
        "noInvalidConstructorSuper": "error",
        "noNewSymbol": "error",
        "noNonoctalDecimalEscape": "error",
        "noPrecisionLoss": "error",
        "noSelfAssign": "error",
        "noSetterReturn": "error",
        "noSwitchDeclarations": "error",
        "noUndeclaredVariables": "error",
        "noUnreachable": "error",
        "noUnreachableSuper": "error",
        "noUnsafeFinally": "error",
        "noUnsafeOptionalChaining": "error",
        "noUnusedLabels": "error",
        "noUnusedVariables": "error",
        "useIsNan": "error",
        "useValidForDirection": "error",
        "useYield": "error"
      }
    }
  }
}
```

Critical rules:

- `noUndeclaredVariables`: Catch undeclared variables
- `noUnusedVariables`: Remove unused code
- `noConstAssign`: Prevent const reassignment
- `noUnreachable`: Detect unreachable code
- `useIsNan`: Use isNaN() for NaN checks

### Performance

Rules for performance optimization:

```json
{
  "linter": {
    "rules": {
      "performance": {
        "recommended": true,
        "noAccumulatingSpread": "warn",
        "noDelete": "error"
      }
    }
  }
}
```

### Security

Rules for security best practices:

```json
{
  "linter": {
    "rules": {
      "security": {
        "recommended": true,
        "noDangerouslySetInnerHtml": "error",
        "noDangerouslySetInnerHtmlWithChildren": "error",
        "noGlobalEval": "error"
      }
    }
  }
}
```

Critical security rules:

- Prevent XSS via innerHTML
- Block eval() usage
- Detect security vulnerabilities

### Style

Code style and consistency rules:

```json
{
  "linter": {
    "rules": {
      "style": {
        "recommended": true,
        "noArguments": "error",
        "noCommaOperator": "error",
        "noImplicitBoolean": "warn",
        "noNegationElse": "warn",
        "noNonNullAssertion": "warn",
        "noParameterAssign": "error",
        "noRestrictedGlobals": "error",
        "noShoutyConstants": "warn",
        "noUnusedTemplateLiteral": "error",
        "noVar": "error",
        "useBlockStatements": "warn",
        "useCollapsedElseIf": "warn",
        "useConst": "error",
        "useDefaultParameterLast": "error",
        "useEnumInitializers": "warn",
        "useExponentiationOperator": "error",
        "useFragmentSyntax": "error",
        "useNumericLiterals": "error",
        "useSelfClosingElements": "error",
        "useShorthandArrayType": "error",
        "useSingleVarDeclarator": "error",
        "useTemplate": "warn",
        "useWhile": "error"
      }
    }
  }
}
```

Key style rules:

- `noVar`: Use let/const instead of var
- `useConst`: Prefer const for immutable bindings
- `noNonNullAssertion`: Avoid ! assertions in TypeScript
- `useTemplate`: Prefer template literals

### Suspicious

Rules for suspicious code patterns:

```json
{
  "linter": {
    "rules": {
      "suspicious": {
        "recommended": true,
        "noArrayIndexKey": "warn",
        "noAssignInExpressions": "error",
        "noAsyncPromiseExecutor": "error",
        "noCatchAssign": "error",
        "noClassAssign": "error",
        "noCommentText": "error",
        "noCompareNegZero": "error",
        "noConsoleLog": "warn",
        "noControlCharactersInRegex": "error",
        "noDebugger": "error",
        "noDoubleEquals": "error",
        "noDuplicateCase": "error",
        "noDuplicateClassMembers": "error",
        "noDuplicateObjectKeys": "error",
        "noDuplicateParameters": "error",
        "noEmptyBlockStatements": "warn",
        "noExplicitAny": "warn",
        "noExtraNonNullAssertion": "error",
        "noFallthroughSwitchClause": "error",
        "noFunctionAssign": "error",
        "noGlobalAssign": "error",
        "noImportAssign": "error",
        "noLabelVar": "error",
        "noMisleadingCharacterClass": "error",
        "noPrototypeBuiltins": "error",
        "noRedeclare": "error",
        "noSelfCompare": "error",
        "noShadowRestrictedNames": "error",
        "noUnsafeNegation": "error",
        "useDefaultSwitchClauseLast": "error",
        "useGetterReturn": "error",
        "useValidTypeof": "error"
      }
    }
  }
}
```

Critical suspicious patterns:

- `noExplicitAny`: Avoid any in TypeScript
- `noConsoleLog`: Remove console.log in production
- `noDebugger`: Remove debugger statements
- `noDoubleEquals`: Use === instead of ==
- `noDuplicateObjectKeys`: Catch duplicate keys

## Rule Configuration Patterns

### Strict Configuration

Maximum strictness for high-quality codebases:

```json
{
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "a11y": { "recommended": true },
      "complexity": { "recommended": true },
      "correctness": { "recommended": true },
      "performance": { "recommended": true },
      "security": { "recommended": true },
      "style": { "recommended": true },
      "suspicious": {
        "recommended": true,
        "noExplicitAny": "error",
        "noConsoleLog": "error"
      }
    }
  }
}
```

### Gradual Adoption

Start lenient and progressively tighten:

```json
{
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "suspicious": {
        "noExplicitAny": "warn",
        "noConsoleLog": "warn"
      },
      "style": {
        "noVar": "error",
        "useConst": "warn"
      }
    }
  }
}
```

### Framework-Specific

React configuration example:

```json
{
  "linter": {
    "rules": {
      "recommended": true,
      "a11y": { "recommended": true },
      "correctness": {
        "recommended": true,
        "noChildrenProp": "error"
      },
      "security": {
        "noDangerouslySetInnerHtml": "error"
      },
      "suspicious": {
        "noArrayIndexKey": "error"
      }
    }
  }
}
```

## Ignoring Violations

### Inline Comments

Suppress specific violations:

```javascript
// biome-ignore lint/suspicious/noExplicitAny: Legacy code
function legacyFunction(data: any) {
  return data;
}

// biome-ignore lint/suspicious/noConsoleLog: Debug logging
console.log('Debug info');

// Multiple rules
// biome-ignore lint/suspicious/noExplicitAny lint/style/useConst: Migration
var config: any = {};
```

### File-Level Ignores

Ignore entire file:

```javascript
/* biome-ignore-file */

// Legacy file, skip all linting
```

### Configuration Ignores

Ignore patterns in biome.json:

```json
{
  "files": {
    "ignore": [
      "**/generated/**",
      "**/*.config.js",
      "**/vendor/**"
    ]
  }
}
```

## Best Practices

1. **Enable Recommended Rules** - Start with `"recommended": true`
2. **Progressive Enhancement** - Add stricter rules gradually
3. **Document Exceptions** - Explain why rules are disabled
4. **Use Inline Ignores Sparingly** - Prefer fixing over ignoring
5. **Security First** - Never disable security rules
6. **CI Enforcement** - Use `biome ci` in pipelines
7. **Pre-commit Hooks** - Catch issues before commit
8. **Team Agreement** - Discuss rule changes with team
9. **Regular Review** - Periodically review disabled rules
10. **Fix Warnings** - Don't let warnings accumulate

## Common Pitfalls

1. **Ignoring Errors** - Using biome-ignore instead of fixing
2. **Disabling Security** - Turning off security rules
3. **No CI Check** - Not enforcing in continuous integration
4. **Too Lenient** - Setting everything to "warn"
5. **No Documentation** - Not explaining disabled rules
6. **Inconsistent Config** - Different rules per package
7. **Ignoring Warnings** - Treating warnings as optional
8. **Wrong Rule Names** - Typos in rule configuration
9. **Overly Strict** - Blocking team productivity
10. **No Migration Plan** - Enabling all rules at once

## Advanced Topics

### Custom Rule Sets

Create shared rule sets for organization:

```json
{
  "extends": ["@company/biome-config"],
  "linter": {
    "rules": {
      "suspicious": {
        "noConsoleLog": "error"
      }
    }
  }
}
```

### Per-Directory Rules

Use overrides for different code areas:

```json
{
  "overrides": [
    {
      "include": ["src/**/*.ts"],
      "linter": {
        "rules": {
          "suspicious": {
            "noExplicitAny": "error"
          }
        }
      }
    },
    {
      "include": ["scripts/**/*.js"],
      "linter": {
        "rules": {
          "suspicious": {
            "noConsoleLog": "off"
          }
        }
      }
    }
  ]
}
```

### Migration Strategy

Migrating from ESLint:

1. **Install Biome**: `npm install -D @biomejs/biome`
2. **Initialize**: `npx biome init`
3. **Run Check**: `npx biome check .` to see violations
4. **Fix Automatically**: `npx biome check --write .`
5. **Address Remaining**: Fix issues that can't auto-fix
6. **Tune Rules**: Adjust rules based on team needs
7. **Update CI**: Replace ESLint with Biome
8. **Remove ESLint**: After validation period

## Integration Patterns

### Package.json Scripts

```json
{
  "scripts": {
    "lint": "biome check .",
    "lint:fix": "biome check --write .",
    "lint:ci": "biome ci ."
  }
}
```

### Pre-commit Hook

Using husky:

```json
{
  "husky": {
    "hooks": {
      "pre-commit": "biome check --write --changed"
    }
  }
}
```

### GitHub Actions

```yaml
- name: Run Biome
  run: npx biome ci .
```

## Troubleshooting

### False Positives

If rule triggers incorrectly:

1. Verify rule is appropriate for your code
2. Check if bug in Biome (report upstream)
3. Use biome-ignore with explanation
4. Consider disabling rule if widespread

### Performance Issues

If linting is slow:

1. Update to latest Biome version
2. Use VCS integration
3. Ignore large generated directories
4. Check for file pattern issues

### Rules Not Applied

Verify:

1. Linter is enabled in config
2. Rule category is enabled
3. Rule name is spelled correctly
4. No overrides disabling it
5. Files are not ignored

## When to Use This Skill

- Setting up linting for new projects
- Migrating from ESLint to Biome
- Configuring rule sets for teams
- Troubleshooting linting errors
- Optimizing code quality checks
- Establishing code standards
- Training team on Biome linting
- Integrating linting into CI/CD

Overview

This skill provides practical guidance for applying Biome's linting capabilities to JavaScript and TypeScript projects. It focuses on rule categories, configuration patterns, and workflows to enforce correctness, performance, security, and consistent style. Use it to design linting policies, integrate Biome into CI, and migrate from other linters safely.

How this skill works

The skill inspects Biome's rule categories (accessibility, complexity, correctness, performance, security, style, suspicious) and explains recommended settings, strict vs gradual adoption patterns, and per-directory overrides. It walks through core commands for checking, auto-fixing, CI enforcement, and output options (verbose/JSON). It also covers ignoring mechanisms (inline, file-level, config ignores) and common troubleshooting steps.

When to use it

  • Setting up linting for a new JavaScript/TypeScript project
  • Migrating from ESLint to Biome with minimal disruption
  • Defining organization-wide or per-package rule sets
  • Enforcing security and correctness checks in CI pipelines
  • Creating pre-commit hooks and developer workflows

Best practices

  • Enable recommended rules as a baseline and incrementally tighten policies
  • Prefer fixing violations over adding biome-ignore comments; document exceptions clearly
  • Enforce security-critical rules (noEval, noDangerouslySetInnerHtml) without disabling
  • Use per-directory overrides for generated code, scripts, or legacy folders
  • Run biome ci in CI to fail builds on regressions and use pre-commit hooks to catch issues early

Example use cases

  • Create a strict org-level config that sets noExplicitAny and noConsoleLog to error for library packages
  • Adopt a gradual strategy: set suspicious/noExplicitAny to warn, then promote to error after a migration window
  • Migrate a mono-repo: add biome.json overrides for older packages and enable recommended rules for src/**
  • Integrate Biome into GitHub Actions with npx biome ci . to enforce quality gates
  • Use biome check --write . in pre-commit to auto-fix safe style issues before commit

FAQ

How do I ignore rules for legacy code safely?

Use inline ignores with clear justification comments or add file-level ignores for entire legacy files. Prefer limiting ignores to specific rules and document the reason and migration plan.

What is the recommended migration path from ESLint?

Install Biome, run npx biome init, run npx biome check . to surface violations, auto-fix with --write, fix remaining issues, tune rules gradually, and replace ESLint in CI once stable.