Language support for MatchaDB .matcha import files — a JSON5-based format whose keys map onto your JPA @Entity classes.

See MatchaDB for the library itself.

Features

Syntax highlighting for the JSON5 grammar plus MatchaDB semantics — reserved @-keys, #Entity:field references, entity keys distinguished from field keys.
Editor behaviors — auto-closing and surrounding pairs, brace matching, comment toggling, bracket-aware indentation.
Formatting that preserves comments and removes trailing commas.
Diagnostics for syntax errors and MatchaDB rules: keys used in the wrong place, unknown @-keys, duplicate or dangling @import_key / @fk_…, and more.
Schema-aware diagnostics, checked against your Java entities: unknown entity or field names, values whose type doesn't match the Java field, relationship values of the wrong shape, and fields the nesting already sets.
Completion of entity names, the contextual entity's field names, and concrete @fk_<field> / #<Entity>:<field> keys — never suggesting something already set.
Inlay hints labelling each row with the @Entity it maps to.
Go to definition from a key to its Java field or @Entity class.
Java @matchadb: links — an "@matchadb:<path>" argument in a Java file is highlighted (the marker like a reserved MatchaDB key, the path like a field), Ctrl/Cmd-clickable to open the import file, completes the path from the workspace's .matcha files, and is flagged when the path resolves to nothing.
Java import keys — an ImportReport key passed to get(…) / getId(…) navigates to its @import_key, completes from the loaded files, and is flagged when none of them declares it. The report is followed back to its loadAndReturn, whether called directly or held in a variable or field.

Requirements

None to edit .matcha files. The schema-aware features additionally need your JPA @Entity classes in the workspace — they are read straight from the .java sources, so no build step is required, and they stay silent when nothing is found.

@MatchaDbConfiguration (or matchadb.* properties) is picked up for the generation prefix, entity packages and base import path.

Multi-module projects are handled per module: a directory containing a pom.xml or build.gradle[.kts] is a module, and each one resolves its own configuration — so a .matcha file is validated against its own module's entities, and @matchadb: paths resolve under its own module root. A module without configuration inherits its parent module's. The Output panel → MatchaDB Language Server lists what every module resolved to, which is the quickest way to spot a misconfigured one.

Known limitations

The Java sources are scanned syntactically, so a type hidden behind a constant or an unresolved cross-file generic is not resolved; the affected features stay silent rather than guess.

Import keys are resolved by following the report within its own file, so a report bound in another file — a base class, say — is not resolved; those calls are left alone rather than flagged.

Import keys are not syntax-highlighted in Java. A TextMate grammar cannot tell which receiver is an ImportReport, so colouring them would also colour every unrelated get(…) / getId(…) call. Navigation, completion and diagnostics do resolve the report properly, and stay silent on unrelated calls.

Architecture

├─ package.json                     # manifest + build scripts
├─ icons/                           # .matcha file icon (light + dark) + marketplace icon
├─ language-configuration.json      # editor behaviors
├─ syntaxes/matcha.tmLanguage.json  # TextMate grammar (highlighting)
├─ client/src/extension.ts          # LSP client (extension entry point)
└─ server/src/
   ├─ server.ts                     # LSP server: connection + capabilities
   ├─ parser/                       # lexer, AST, recursive-descent parser
   ├─ features/                     # diagnostics, completion, formatting, hints, definition
   ├─ schema/                       # Java scanning -> the @Entity model
   └─ test/                         # unit tests (node:test)

The language server is a local Node process — no network involved.

Develop

npm install
npm run compile     # or: npm run watch
npm test            # unit tests
npm run package     # build a .vsix

Press F5 to launch an Extension Development Host. It reopens whatever folder it had last, so open a MatchaDB project there once; or use the "Run Extension (demo project)" launch config for the self-contained samples/demo-project/.

The Output panel → MatchaDB Language Server logs the resolved schema on startup.