Issue Title

Plugin configuration & extensibility gaps prevent LSP real-time feedback for complex custom rules

Summary

We are evaluating Biome 2.5.3 as a replacement for ESLint in a large multi-package frontend repository (React + Vue2, TypeScript, multiple git submodules). While Biome's built-in rules and performance are excellent, we found that the current plugin system forces us to maintain custom rules as a separate CLI tool instead of a native Biome plugin. As a result, those rules cannot be triggered by the Biome LSP in real time inside the IDE.

Our current setup

In our previous ESLint setup, custom rules (e.g. @youzan/scrm/no-package-src-or-lib-imports, @youzan/koko/no-http-cdn, @youzan/guide/date-format, JSDoc presence checks) were loaded as ESLint plugins. The ESLint language server invoked them on every file save / edit, so developers got instant feedback in VS Code / Trae.

With Biome, we had to move those rules into a standalone Node.js CLI (@youzan/biome-plugin, entry dist/run.js) because the rules:

• need configurable paths / regexes (e.g. banned import patterns differ per project);
• need to inspect JSDoc comments (custom/jsdoc-required);
• need to recognize date-formatting call patterns and arguments (custom/date-format);
• need per-rule severity and file-include options stored in JSON.

This CLI is invoked from lint-staged and CI, but never from the Biome LSP, so developers no longer see diagnostics while editing.

Specific limitations we hit

1. GritQL plugins cannot accept configuration options
   biome.json can reference a .grit plugin, but there is no way to pass options into it (severity, denied import regexes, allowed identifier names, file globs, etc.). This forces every project to fork the .grit file or hard-code values.

2. No JSDoc / leading-trivia API in GritQL
   Rules that check whether an exported function has a preceding /** */ block cannot be expressed. We verified empirically that preceded_by / after do not match leading trivia comments (also reported in GritQL plugins: expose leading-trivia / JSDoc-comment matching predicate #10474).

3. No JavaScript/TypeScript plugin API
   For rules that are easier to write and maintain in TypeScript (cross-file analysis, complex argument validation, reuse of existing ESLint rule logic), a JS/TS plugin runtime would be the natural migration path, but Biome does not expose one yet.

4. Standalone CLI is invisible to the LSP
   Even if we keep the custom CLI, Biome LSP only runs rules defined in biome.json. There is no hook to run an external linter and surface its diagnostics through the same LSP channel.

Expected behavior

At minimum, one of the following would unblock us:

• Configurable GritQL plugins: allow biome.json to pass a JSON options object to a plugin, and expose JSDoc / leading-trivia predicates.
• JS/TS plugin API: let users write plugins in JavaScript/TypeScript, register them in biome.json, and have Biome LSP execute them alongside native rules.

With either option, our custom rules would run inside Biome's lint pipeline and therefore be available in the IDE via the Biome language server.

Why this matters

For our teams, "lint feedback only after commit/CI" is a significant regression compared to ESLint. It increases the feedback loop from seconds to minutes and shifts the cost of fixing issues from the author to reviewers or CI. This is the main blocker preventing us from fully migrating from ESLint to Biome.

Environment

• Biome version: 2.5.3
• Repository type: large monorepo with multiple packages / git submodules
• Frameworks: React 17, Vue 2, TypeScript 4.5
• IDEs: VS Code, Trae