Guide for implementing ESLint-to-Biome rule option migrators inside `biome migrate eslint`. Use whenever you add or update a Biome lint rule that has an ESLint source rule with configurable options, need to deserialize plugin-specific ESLint options, or need custom migration logic beyond the auto-generated severity mapping.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Guide for implementing ESLint-to-Biome rule option migrators inside `biome migrate eslint`. Use whenever you add or update a Biome lint rule that has an ESLint source rule with configurable options, need to deserialize plugin-specific ESLint options, or need custom migration logic beyond the auto-generated severity mapping.
compatibility
Designed for coding agents working on the Biome codebase (github.com/biomejs/biome).
Purpose
Use this skill when a Biome lint rule already exists and biome migrate eslint should preserve more than just the rule severity.
This skill is specifically for cases where an ESLint rule has options that need to be:
deserialized from ESLint config
translated into Biome rule options
wired into the migrate pipeline
tested through migrator spec fixtures without depending on CLI tests
Do not use this skill for severity-only migrations. Those are usually covered by the generated rule mapping in eslint_any_rule_to_biome.rs.
Before You Edit
Confirm these points first:
The target Biome rule already exists and already has its own options type in crates/biome_rule_options/src/.
The Biome rule metadata already declares the ESLint source rule, so severity-only migration exists or can be generated.
The ESLint rule really has user-facing options worth preserving.
You have checked the ESLint rule docs or source so you know the exact option shape, defaults, and any plugin-specific quirks.
If any of those are missing, fix that first before adding a migrator.
Generated severity mapping for all known ESLint-backed rules
xtask/codegen/src/generate_migrate_eslint.rs
Codegen for the generated rule mapping
Use the plugin-specific file that matches the source ESLint rule. Keep option structs close to similar migrators so future edits stay discoverable.
Recommended Workflow
Step 1: Inspect an Existing Migrator First
Before writing anything new, find a nearby rule that already migrates options. Reuse its shape if the target rule is in the same plugin or has the same Biome configuration type (RuleConfiguration vs RuleFixConfiguration).
This saves time and helps match the patterns already used in migrate_eslint_rule().
Step 2: Model the ESLint Options Exactly
Add structs in the correct plugin file. Match ESLint's option payload shape, not Biome's.
Focus on semantic mapping, not field-for-field copying:
rename concepts when ESLint and Biome use different names
drop unsupported knobs deliberately
preserve defaults only when they match Biome's behavior
add small helper functions when the conversion needs filtering or normalization
If an ESLint option should only be emitted when at least one nested field is set, use a helper that returns Option<_> rather than constructing empty Biome option objects.
Step 4: Add a Typed Rule Variant
In eslint_eslint.rs, add a Rule enum variant using RuleConf<T>:
Severity-only ESLint config still migrates correctly.
ESLint config with options produces the expected Biome options.
Unsupported ESLint knobs do not break deserialization.
Empty or partially specified nested options do not emit incorrect Biome config.
If Biome's defaults differ from ESLint's, severity-only configs should not emit Biome options that change behavior.
Use the migrator spec fixtures in crates/biome_cli/tests/specs/migrate_eslint/ for custom migrators.
Add one fixture file per case.
Keep the fixture focused on eslint input and pre-migration biome config input.
Let the generated test runner in eslint_to_biome.rs discover the file and write the adjacent .snap.new.
Add fixtures for every relevant option shape, including severity-only configs when defaults differ between ESLint and Biome.
After inspecting snapshot differences, use cargo insta accept to accept valid new snapshots, or cargo insta reject to reject invalid ones and keep iterating.
Useful commands:
cargo check -p biome_cli
cargo test -p biome_cli migrate_eslint
When the rule itself has analyzer behavior tied to the options, run targeted analyzer tests too:
cargo test -p biome_js_analyze my_rule_name
Review Checklist
Before finishing, confirm:
the typed Rule variant exists
Rule::name() returns the exact ESLint rule name
Rules::deserialize has an explicit arm before the fallback
the plugin-specific ESLint option structs match the real ESLint schema
the From impl maps semantics correctly, not just names mechanically
migrate_eslint_any_rule() is still called first
the chosen Biome rule group and configuration type are correct
migrator spec fixtures cover both severity-only and option-bearing configs when relevant
