feat: add Prettier-only formatting support

[J3m5]

• ✨ Introduce a delegation bridge for Prettier-only formatting.

• 🧪 Add tests for formatting specific to Prettier-only file types.

• 🐛 Fix issues with nested Tokio runtime in LSP.

• 🐛 Ensure formatter activates for JSON, CSS, and Markdown file types.

• 🐛 Scope formatter selector to supported file types.

• 📝 Require Prettier-only formatting in tests.

[Copilot]

Pull request overview

This PR adds support for formatting Prettier-only file types (JSON, CSS, Markdown) through an external formatter bridge, enabling the OXC formatter to delegate formatting to Prettier for file types it doesn't natively support.

Key Changes:

• Introduced an ExternalFormatterBridge trait and implementation for delegating formatting to Prettier
• Added activation events for CSS, JSON, JSONC, and Markdown languages in VS Code extension
• Implemented detection logic to identify Prettier-only files and route them to the external formatter
• Created comprehensive test fixtures for various Prettier-supported file types

Reviewed changes

Copilot reviewed 39 out of 40 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
crates/oxc_language_server/src/formatter/external_formatter_bridge.rs	Defines the bridge trait for external formatters with a no-op implementation
crates/oxc_format_support/src/lib.rs	Implements file type detection and config loading for Prettier-only files
crates/oxc_language_server/src/formatter/server_formatter.rs	Integrates external formatter bridge into the formatter pipeline
apps/oxfmt/src/lsp/mod.rs	Implements NAPI bridge for external formatter with Tokio runtime handling
editors/vscode/package.json	Adds activation events for newly supported languages
editors/vscode/client/tools/formatter.ts	Extends supported file extensions list
editors/vscode/tests/e2e_server_formatter.spec.ts	Adds E2E tests for Prettier-only file formatting
crates/oxc_format_support/Cargo.toml	New crate for format support utilities
Multiple fixture files	Test data for various Prettier-supported file types

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The external_options field is marked as potentially dead code when the lsp-prettier feature is disabled, but it's unconditionally included in the struct. Consider making this field conditional with #[cfg(feature = \"lsp-prettier\")] to avoid including unused data in the struct.

Suggested change

	#[cfg_attr(not(feature = "lsp-prettier"), allow(dead_code))]
	#[cfg(feature = "lsp-prettier")]

[Dunqing]

Is this an AI-generated PR? Please follow https://oxc.rs/docs/contribute/introduction.html#ai-usage-policy

[J3m5]

Is this an AI-generated PR? Please follow oxc.rs/docs/contribute/introduction.html#ai-usage-policy

I've already read the usage policy.

It is partially AI-generated, yes.
I reviewed the (minimal) plan and the implementation, it added tests and I tested the built extension manually, and it is working as expected.

But this PR wasn’t meant to be opened against this repository (at least for now) but on my own fork, I didn’t double-check the target repo carefully when I clicked the open PR button in VSCode, sorry for the noise.

Still, I’d appreciate your opinion on the implementation. Is it going in the right direction?

The reason I'm doing this is because the VSCode extension is missing this feature from the CLI, this is part of an effort to open the discussion and to bring it up to par in order to be able to fully replace Prettier with oxfmt.

PS: This message was written by a human

[Sysix]

Still, I’d appreciate your opinion on the implementation. Is it going in the right direction?

I can help you maybe with the direction :) At first ServerFormatterBuilder is the right place to connect the external formatter. But NAPI is missing an important implementation. The LSP has the concept of workspace folders, you can rethink them like cwd for the CLI tools.
The JS Implementation should separate each workspace folder and its config. In a perfect world, there is something like this pseudocode:

export function createWorkspace(directory: string): WorkspaceActions;
export function deleteWorkspace(directory:string): void;

export interface WorkspaceActions {
  formatFile(...): ....
}

In #17462 we are moving all relevant lsp code to the oxfmt binary, you should not need to have an extra "bridge" crate for this :)

Look into https://oxc.rs/docs/contribute/language_server.html#difference-between-language-server-and-cli, to learn more about the difference between LSP and CLI :)