Allow the user to add/override parsers for a given file extension #29

Activity

1. NextDesign1

   changed the title [-]Allow the user to override parsers for a given file extension[/-] [+]Allow the user to add/override parsers for a given file extension[/+] on Aug 19, 2026
2. MrDoe

   added

   enhancementNew feature or requestNew feature or request

   on Aug 19, 2026
3. MrDoe

   self-assigned this

   on Aug 19, 2026
4. MrDoe commented on Aug 29, 2026

   

   MrDoe

   on Aug 29, 2026

   Owner

   More actions

   This can be useful. But right now I'm on vacation, so I'm planning to implement this in September.
5. MrDoe

   added a commit that references this issue on Oct 20, 2026

   fix(chunking): make chunking.parsers work on every surface (issue #29)

   ...

   53508f1
6. MrDoe commented on Oct 20, 2026

   

   MrDoe

   on Oct 20, 2026

   Owner

   More actions

   Thanks for the suggestion — this is now implemented.

   What landed

   The extension → parser mapping is configurable via a new chunking.parsers config section:

   {
     "chunking": {
       "parsers": {
         ".c": "cpp",
         ".cu": "cpp"
       }
     }
   }

   Keys are normalized (lowercased, leading dot added), so "CXX" and ".cxx" are the same entry. Values must be a registered parser language (typescript, cpp, python, … plus text for the fallback parser) — unknown names produce a config warning listing the valid ones. Both new extensions and existing mappings can be remapped, exactly as in your example.

   The mapping is resolved per call and never mutates the process-wide chunker registry, so it stays workspace-scoped and coexists safely with pluggable chunkers[].

   Where to set it

   • opencode-rag.json
   • the TUI settings editor (Chunking → Parser overrides — extension → language)
   • opencode-rag init (now emits an empty chunking section, so the key is discoverable)
   • the dashboard API (PUT /api/config with a chunking section)

   What it affects

   The override is honored consistently on every extension-sensitive surface:

   1. Indexing/chunking — getChunker() picks the target parser, and chunking.nodeTypes is looked up under the target language (so nodeTypes.cpp applies to a remapped .c file).
   2. get_file_skeleton (plugin tool and MCP) — resolves to the target parser's grammar recipe.
   3. Read-tool code fences — the language label comes from the override.
   4. Embedding metadata header — the [type] label follows the override, so a remapped .c file is embedded as [cpp], matching the chunk's metadata.language.

   Extensions named in chunking.parsers are implicitly added to the scan set — you don't need to repeat them in indexing.includeExtensions.

   Note

   Changing a mapping changes chunk boundaries for already-indexed files without touching their content hashes, so re-run opencode-rag index --force after editing.

   Fixed in #29 — the feature itself landed in e35e8df; this change closes the remaining gaps where the mapping was silently ignored (TUI live edits, the embedding metadata label, the eval indexer, init, and the dashboard API) plus a bug where a no-op override (.tsx → typescript) degraded the skeleton recipe.
7. MrDoe

   closed this as completedon Oct 20, 2026
8. MrDoe commented on Oct 20, 2026

   

   MrDoe

   on Oct 20, 2026

   Owner

   More actions

   Shipped in v2.5.0

   Thanks again for the suggestion — this is now implemented and released.

   The config

   The extension → parser mapping is configurable through a new chunking.parsers section in opencode-rag.json:

   {
     "chunking": {
       "parsers": {
         ".c": "cpp",
         ".cu": "cpp"
       }
     }
   }

   That covers both cases from your example: a new extension (.cu → C++) and an existing mapping being overridden (.c → C++).

   • Keys are file extensions, normalized (lowercased, leading dot added) — "CXX" and ".cxx" are the same entry.
   • Values are registered parser languages (typescript, cpp, python, … plus text for the fallback parser). Unknown names produce a config warning listing the valid ones.
   • The mapping is resolved per call and never mutates the process-wide chunker registry, so it stays workspace-scoped and coexists safely with pluggable chunkers[].

   Where to set it

   • opencode-rag.json
   • the TUI settings editor (Chunking → Parser overrides — extension → language)
   • opencode-rag init — now emits an empty chunking section, so the key is discoverable in a generated config
   • the dashboard API (PUT /api/config with a chunking section)

   What it affects

   The override is honoured consistently on every extension-sensitive surface:

   Surface	Effect
   Indexing / chunking	getChunker() picks the target parser, and chunking.nodeTypes is looked up under the target language — so nodeTypes.cpp applies to a remapped .c file
   get_file_skeleton (plugin tool + MCP)	resolves to the target parser's grammar recipe
   Read-tool code fences	the language label comes from the override
   Embedding metadata header	the [type] label follows the override, so a remapped .c file is embedded as [cpp] — matching its own chunk metadata
   Scan set	extensions named in the map are implicitly added, so you don't need to repeat them in indexing.includeExtensions

   One caveat

   Changing a mapping changes chunk boundaries for already-indexed files without touching their content hashes — so re-run opencode-rag index --force after editing.

   ---

   Released in v2.5.0 (on npm as opencode-rag-plugin@2.5.0).

   The implementation landed in e35e8df; this release also closes the places where the mapping was still being ignored — the TUI's live edits, the embedding metadata label, the eval indexer, opencode-rag init, and the dashboard API — plus a bug where a no-op override (.tsx → typescript) degraded the skeleton recipe.