Proposal: Native .astro File Support in Oxlint (Parser + Rule Integration)

[SalahAdDin]

Hi Oxlint team 👋

I’d like to propose adding first-class support for Astro (.astro) files, starting with frontmatter parsing and progressively expanding into template awareness.

Given Oxlint’s performance-first architecture, this could position it as the default linter for modern performance-oriented frameworks.

---

Why Astro Support Is Strategically Aligned

Astro’s core value proposition is performance (SSG, partial hydration, server-first rendering).

Oxlint shares that philosophy — fast, Rust-based linting with minimal overhead.

Currently, Astro projects depend on ESLint with custom parsers, which introduces:

• Slower lint cycles
• Complex parser layering
• Higher configuration overhead
• Toolchain fragmentation

There is no high-performance alternative for .astro linting today.

Supporting Astro would create strong alignment between two performance-driven ecosystems.

---

What Astro Files Require (Technically)

An .astro file contains:

1. Frontmatter block

• TypeScript/JavaScript
• Imports
• Server-side logic
• Often JSX (depending on integrations)

2. Template section

• HTML-like syntax
• Embedded expressions
• Framework islands (React/Vue/Svelte)
• Astro directives (client:*, set:html, etc.)

This makes .astro a hybrid format requiring either:

• A composite AST model
• Or segmented parsing with rule application per region

---

Proposed Phased Implementation

Phase 1 – Frontmatter Support (High ROI, Lower Complexity)

• Parse .astro
• Extract frontmatter
• Apply existing JS/TS rules to that region
• Ignore template initially

This delivers immediate value with limited architectural expansion.

Most logic bugs in Astro apps live in frontmatter.

---

Phase 2 – Template Parsing Integration

Possible approaches:

• Leverage @astrojs/compiler for AST generation
• Integrate via tree-sitter grammar
• Support pluggable parsers for non-standard formats

This enables:

• Unused imports detection across template usage
• Expression validation
• JSX rule reuse inside islands

---

Phase 3 – Astro-Specific Static Analysis (Long-Term Opportunity)

Oxlint could provide rules unique to Astro, such as:

• Invalid client:* directive usage
• Server/client boundary violations
• Dead imports used only in template
• Performance anti-patterns (e.g., excessive client hydration)

This would differentiate Oxlint from generic JS linters.

---

Architectural Questions

To evaluate feasibility:

• Is Oxlint planning a pluggable parser architecture?
• Can rules operate on partial file segments?
• Would multi-pass parsing be compatible with Oxlint’s performance guarantees?
• Is hybrid AST composition within scope of the project vision?

---

Why This Is a Strategic Opportunity

• Astro adoption is growing rapidly in production SSG/SSR use cases.
• There is currently no Rust-based or high-performance linter supporting .astro.
• Early adoption could make Oxlint the default choice for performance-focused web teams.
• It aligns strongly with Oxlint’s positioning: speed, modern tooling, minimal overhead.

---

If this aligns with the project roadmap, I’d be interested in exploring a proof-of-concept for Phase 1 (frontmatter parsing) to validate the integration model.

Looking forward to your thoughts.