[FEATURE]: Support custom tree-sitter parsers via config for custom languages

[djmittens]

Problem

OpenCode's syntax highlighting is driven by tree-sitter parsers hardcoded in parsers-config.ts. There is no way to add a custom language parser via opencode.json config. This means anyone working on a new or niche language gets no syntax highlighting, even if they already have a fully working tree-sitter grammar and WASM binary.

Our Situation

We're building Valkyria, a Lisp dialect with .valk files. We already have:

• A custom LSP server — configured via opencode.json under lsp, works great with diagnostics, hover, completion, go-to-definition, semantic tokens, etc.
• A tree-sitter grammar — full grammar.js with highlights, locals, and indents queries
• A compiled WASM binary — tree-sitter-valk.wasm (13KB), built and ready

The LSP integration is seamless thanks to the existing config. But there's no equivalent config path for syntax highlighting — we can't point OpenCode at our WASM + queries.

Proposed Solution

Add a syntax (or parsers) section to opencode.json that allows users to register custom tree-sitter parsers:

{
  "$schema": "https://opencode.ai/config.json",
  "syntax": {
    "valk": {
      "wasm": "./editors/tree-sitter-valk.wasm",
      "extensions": [".valk"],
      "highlights": "./editors/queries/valk/highlights.scm",
      "locals": "./editors/queries/valk/locals.scm"
    }
  }
}

This mirrors the existing lsp config pattern — same shape, same idea: point at a binary + file extensions.

The wasm and highlights fields could accept either local paths (relative to project root) or URLs (for hosted grammars), consistent with how parsers-config.ts already works internally.

Why This Matters

• Every new language currently requires a PR to parsers-config.ts and a new OpenCode release
• Custom/internal languages (DSLs, research languages, new languages in development) will never get into parsers-config.ts
• The LSP config already proves this pattern works — lsp.valk.command + lsp.valk.extensions is all it takes
• This would also help with the alias problem (White text in fenced code blocks: missing parser aliases (sh, yml, py, jsonc) cause fallback to hardcoded #ffffff #17323) — users could map .valk to the clojure parser as a workaround without needing upstream changes

Alternatives Considered

• PR to add valk to parsers-config.ts: Works for us but doesn't help anyone else with a custom language. Every language needs a separate PR + release cycle.
• Aliasing extensions to existing parsers: Partial solution (e.g., .valk → clojure), but loses language-specific highlights. Would still be useful as a simpler option alongside full custom parser support.

[tomaskallup]

Would love to see this, I wanted to add elixir, which forced me to edit the source, build and use the locally built version. While doing so, I noticed there is also a comment about broken injections (which would be great to have for heex etc.), I'm not sure if that is somewhere in a road map or if there is an open issue (couldn't find one), but that would probably be nice to have before allowing configurable parsers.