performance-lint-rules

Reviews Rust linter rule implementations in Oxc for performance optimization opportunities.

22.6k|1.3k|Updated Feb 9, 2023
One-click install
npx skills add https://github.com/oxc-project/oxc --skill performance-lint-rules
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: performance-lint-rules
Source: https://github.com/oxc-project/oxc/tree/main/.agents/skills/performance-lint-rules
Command: npx skills add https://github.com/oxc-project/oxc --skill performance-lint-rules

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Linter rules that run on every AST node or perform unnecessary allocations, regex evaluations, and semantic lookups slow down the entire linting pipeline. This Skill provides concrete performance review guidance for auditing and optimizing Rust rule implementations in the Oxc linter.

Core Features & Use Cases

  • Node Kind Narrowing: Guides placing AstKind checks at rule entry points so lintgen derives narrower NODE_TYPES and avoids dispatching rules on unrelated nodes.
  • Cheap-First Check Ordering: Recommends ordering checks from cheapest to most expensive, delaying diagnostics, allocations, and semantic lookups until a real candidate is found.
  • Allocation and Regex Avoidance: Promotes byte-level scans, copy-on-write utilities, and targeted scoping lookups over heap allocations and regular expressions.
  • Use Case: When reviewing a pull request that adds a new rule under crates/oxc_linter/src/rules/, apply this guidance to catch rules that iterate all AST nodes instead of using run_once or unresolved-reference lookups.

Quick Start

Review the Rust rule code in crates/oxc_linter/src/rules/ for performance issues using the performance lint rules guidance.

Frequently Asked Questions about performance-lint-rules

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I optimize an Oxc linter rule for performance?

Start the rule's run method with an AstKind match that returns early for unrelated nodes, order checks from cheapest to most expensive, and delay diagnostics and allocations until a real candidate is found. Regenerate the runner with cargo lintgen afterward.

When should a lint rule use run_once instead of run?

Use run_once when the rule performs a whole-file pass over semantic indexes and does not need to run on every AST node. Implementing both run and run_once prevents useful node-type narrowing by lintgen.

How do I check global or unresolved identifiers efficiently in a lint rule?

Start from ctx.scoping().root_unresolved_references().get(name) for the small set of relevant names instead of visiting every IdentifierReference. Still verify each reference has no symbol, is not type-only, and matches the expected AstKind.

Should lint rules use regular expressions for string matching?

Avoid regular expressions when byte or string checks suffice, such as contains, starts_with, ends_with, or matching a small fixed set. For hot scanning paths, use a cheap memchr or byte search to reject most inputs before parsing candidates.

What should I do after changing which node kinds a rule handles?

Regenerate the rule runner with cargo lintgen so lintgen derives narrower NODE_TYPES, and consider adding or updating assert_rule_runs_on_node_types coverage in crates/oxc_linter/src/rule.rs.