dsh-plugin-codegraph-tree-sitter 0.1.4 → 0.1.5

package/lib/languages.d.ts

@@ -102,6 +102,53 @@ export declare const FIRST_CHILD_NAME_FIELD = "@first-child";
  * of its own.
  */
 export declare const PHP_ELEMENT_NAME_FIELD = "@php-element";
+/**
+ * Sentinel {@link DefinitionRule.nameField} value for a rule whose name is Kotlin-specific: the bundled
+ * `tree-sitter-kotlin` grammar this package loads binds *no* grammar fields at all (verified against a
+ * real parse — `Language.fieldCount`/`fieldNameForId` enumerate zero for it), unlike every other grammar
+ * this package extracts from, so a plain `childForFieldName` lookup can never work here regardless of
+ * which field name is named. A `class_declaration`'s/`function_declaration`'s/`enum_entry`'s declared
+ * name is instead the first direct named child typed `type_identifier` (a class/interface/enum name) or
+ * `simple_identifier` (a function/enum-entry name) — found by type rather than by position, since an
+ * optional leading `modifiers` node (wrapping `private`/`internal`/…) would otherwise sit at index 0
+ * ahead of it. See `kotlinDeclaredName` in `extract.ts`, which this sentinel dispatches to.
+ */
+export declare const KOTLIN_NAME_FIELD = "@kotlin-name";
+/**
+ * Sentinel {@link DefinitionRule.nameField} value for a rule whose name is Swift-specific: a
+ * `property_declaration`'s own `name` field points to a `pattern` node (`var x: Int`'s `x` sits behind
+ * this wrapper, not bound to a field of `property_declaration` directly), and the actual declared
+ * identifier is one level deeper still, bound to that `pattern` node's own `bound_identifier` field.
+ * See `swiftPropertyName` in `extract.ts`, which this sentinel dispatches to instead of a flat
+ * `childForFieldName` lookup. Verified against a real parse, not guessed.
+ */
+export declare const SWIFT_PROPERTY_NAME_FIELD = "@swift-property";
+/**
+ * Sentinel {@link DefinitionRule.nameField} value for a rule whose name is Swift-specific in a
+ * different way: a `function_declaration`/`protocol_function_declaration` with an explicit return type
+ * (`func add() -> Int`) binds *two* nodes to its own `name` field in this grammar build — the declared
+ * identifier itself, and (a verified, unguessed quirk of this specific compiled grammar) its
+ * `return_type` node as well — so `childrenForFieldName('name')` returns both, failing
+ * `soleNamedField`'s "exactly one bound child" uniqueness check the same way Go's genuinely ambiguous
+ * `const a, b = 1, 2` does, and silently dropping every such function from this package's graph. Unlike
+ * that Go case, this is not a real multi-name ambiguity — the identifier always comes first in document
+ * order — so `swiftFunctionName` in `extract.ts` uses `childForFieldName('name')` (first match) instead
+ * of `soleNamedField`'s all-matches check.
+ */
+export declare const SWIFT_FUNCTION_NAME_FIELD = "@swift-function";
+/**
+ * Sentinel {@link DefinitionRule.nameField} value for a rule whose name is Dart-specific: a `declaration`
+ * node is how Dart spells both a class/struct field (`int x;`, wrapping an `initialized_identifier_list`
+ * of one or more `initialized_identifier` children, itself the same multi-name ambiguity Go's
+ * `const_spec`/`var_spec` already reject outright) and a constructor (wrapping a `constructor_signature`
+ * instead, handled by its own separate rule matching that inner node type directly, not this one) — with
+ * no field of its own binding either shape, so `dartFieldName` in `extract.ts` returns `undefined` for
+ * anything but the single-identifier field-list shape, the same "don't guess" precedent this file already
+ * follows elsewhere; a `declaration` wrapping a constructor simply fails to match this rule and is left
+ * for the dedicated `constructor_signature` rule to capture during the walk's ordinary recursion into it.
+ * Verified against a real parse, not guessed.
+ */
+export declare const DART_FIELD_NAME_FIELD = "@dart-field";
 /** One tree-sitter node type recording a relative-import binding, per language family. */
 export interface ImportRule {
     /** The tree-sitter node type anchoring one import statement, e.g. `import_statement`. */

package/lib/languages.js

@@ -43,6 +43,53 @@ export const FIRST_CHILD_NAME_FIELD = '@first-child';
  * of its own.
  */
 export const PHP_ELEMENT_NAME_FIELD = '@php-element';
+/**
+ * Sentinel {@link DefinitionRule.nameField} value for a rule whose name is Kotlin-specific: the bundled
+ * `tree-sitter-kotlin` grammar this package loads binds *no* grammar fields at all (verified against a
+ * real parse — `Language.fieldCount`/`fieldNameForId` enumerate zero for it), unlike every other grammar
+ * this package extracts from, so a plain `childForFieldName` lookup can never work here regardless of
+ * which field name is named. A `class_declaration`'s/`function_declaration`'s/`enum_entry`'s declared
+ * name is instead the first direct named child typed `type_identifier` (a class/interface/enum name) or
+ * `simple_identifier` (a function/enum-entry name) — found by type rather than by position, since an
+ * optional leading `modifiers` node (wrapping `private`/`internal`/…) would otherwise sit at index 0
+ * ahead of it. See `kotlinDeclaredName` in `extract.ts`, which this sentinel dispatches to.
+ */
+export const KOTLIN_NAME_FIELD = '@kotlin-name';
+/**
+ * Sentinel {@link DefinitionRule.nameField} value for a rule whose name is Swift-specific: a
+ * `property_declaration`'s own `name` field points to a `pattern` node (`var x: Int`'s `x` sits behind
+ * this wrapper, not bound to a field of `property_declaration` directly), and the actual declared
+ * identifier is one level deeper still, bound to that `pattern` node's own `bound_identifier` field.
+ * See `swiftPropertyName` in `extract.ts`, which this sentinel dispatches to instead of a flat
+ * `childForFieldName` lookup. Verified against a real parse, not guessed.
+ */
+export const SWIFT_PROPERTY_NAME_FIELD = '@swift-property';
+/**
+ * Sentinel {@link DefinitionRule.nameField} value for a rule whose name is Swift-specific in a
+ * different way: a `function_declaration`/`protocol_function_declaration` with an explicit return type
+ * (`func add() -> Int`) binds *two* nodes to its own `name` field in this grammar build — the declared
+ * identifier itself, and (a verified, unguessed quirk of this specific compiled grammar) its
+ * `return_type` node as well — so `childrenForFieldName('name')` returns both, failing
+ * `soleNamedField`'s "exactly one bound child" uniqueness check the same way Go's genuinely ambiguous
+ * `const a, b = 1, 2` does, and silently dropping every such function from this package's graph. Unlike
+ * that Go case, this is not a real multi-name ambiguity — the identifier always comes first in document
+ * order — so `swiftFunctionName` in `extract.ts` uses `childForFieldName('name')` (first match) instead
+ * of `soleNamedField`'s all-matches check.
+ */
+export const SWIFT_FUNCTION_NAME_FIELD = '@swift-function';
+/**
+ * Sentinel {@link DefinitionRule.nameField} value for a rule whose name is Dart-specific: a `declaration`
+ * node is how Dart spells both a class/struct field (`int x;`, wrapping an `initialized_identifier_list`
+ * of one or more `initialized_identifier` children, itself the same multi-name ambiguity Go's
+ * `const_spec`/`var_spec` already reject outright) and a constructor (wrapping a `constructor_signature`
+ * instead, handled by its own separate rule matching that inner node type directly, not this one) — with
+ * no field of its own binding either shape, so `dartFieldName` in `extract.ts` returns `undefined` for
+ * anything but the single-identifier field-list shape, the same "don't guess" precedent this file already
+ * follows elsewhere; a `declaration` wrapping a constructor simply fails to match this rule and is left
+ * for the dedicated `constructor_signature` rule to capture during the walk's ordinary recursion into it.
+ * Verified against a real parse, not guessed.
+ */
+export const DART_FIELD_NAME_FIELD = '@dart-field';
 /** Definitions common to every ECMAScript-family grammar (JavaScript, JSX, TypeScript, TSX). */
 const ECMASCRIPT_DEFINITIONS = [
     { nodeType: 'function_declaration', kind: 'function', nameField: 'name' },
@@ -424,6 +471,335 @@ export const LANGUAGE_TABLE = [
         // real parse, not guessed.
         bareFunctionScopeTypes: ['closure_expression'],
     },
+    {
+        language: 'ruby',
+        extensions: ['.rb'],
+        wasmFile: 'tree-sitter-ruby.wasm',
+        definitions: [
+            // Every `def` — top-level, module-level, or inside a class body — defines a method (a top-level
+            // `def` becomes a private instance method of `Object`), so this package uses kind `method`
+            // uniformly rather than split a `function`/`method` distinction the language itself does not
+            // draw; `singleton_method` (`def self.foo`/`def Klass.foo`) is a class/singleton method, same
+            // kind. Verified against a real parse, not guessed.
+            { nodeType: 'method', kind: 'method', nameField: 'name' },
+            { nodeType: 'singleton_method', kind: 'method', nameField: 'name' },
+            { nodeType: 'class', kind: 'class', nameField: 'name' },
+            // No dedicated `namespace` handling exists elsewhere but Rust's `mod_item`; a Ruby `module` is the
+            // closest existing fit — both are a purely lexical/organizational container with no instance
+            // semantics of their own, matching that same precedent.
+            { nodeType: 'module', kind: 'namespace', nameField: 'name' },
+            // `my_lambda = ->(x) { x + 1 }` — the only anonymous-function *literal* shape this grammar has;
+            // `proc { ... }`/`Proc.new { ... }` parse as an ordinary `call` with a block argument, structurally
+            // indistinguishable from any other block-taking method call, so they are not treated as a
+            // function-valued binding — the same "don't guess" precedent this file already follows elsewhere.
+            // Tried first, before the unrestricted `variable` rule below falls through to everything else —
+            // the same precedent ECMASCRIPT_DEFINITIONS's `variable_declarator` rule follows.
+            { nodeType: 'assignment', kind: 'function', nameField: 'left', nameNodeTypes: ['identifier'], value: { field: 'right', types: ['lambda'] } },
+            // `CONST = 1` — a bare uppercase-leading `constant` node is Ruby's own real distinction (the
+            // grammar itself lexes an uppercase-leading bare word as a distinct `constant` token, not merely an
+            // `identifier`), so no `scopeRestricted` is needed: a dynamic constant assignment inside a method
+            // body is a Ruby `SyntaxError`, the parser never produces this shape nested in one. Verified
+            // against a real parse, not guessed.
+            { nodeType: 'assignment', kind: 'constant', nameField: 'left', nameNodeTypes: ['constant'] },
+            // A bare lowercase local variable assignment — `nameNodeTypes` rejects Ruby's other `assignment`
+            // left-hand shapes (`left_assignment_list` for `a, b = 1, 2`, a `call` for `self.x = 1`, an
+            // `element_reference` for `arr[0] = 1`), none of which name a single declared identifier, verified
+            // against a real parse, not guessed. An instance variable (`@name = ...`) is deliberately not
+            // captured at all — unlike every other language this package extracts a `field` kind from, Ruby has
+            // no declarative field syntax; an instance variable is conventionally *assigned* inside `initialize`
+            // (method-body scope), and this file's scope model has no way to mark that assignment a class-level
+            // symbol without also flooding `resolve.ts`'s name index with every ordinary method-local variable —
+            // the same "don't guess" precedent this file already follows for a shape it cannot cleanly resolve.
+            { nodeType: 'assignment', kind: 'variable', nameField: 'left', nameNodeTypes: ['identifier'], scopeRestricted: true },
+        ],
+        // A bare, receiver-less, paren-less, arg-less method call (`other_call`) parses as a plain
+        // `identifier` — syntactically identical to a local-variable read — so it is not (and cannot safely
+        // be) captured as a call site; only a `call` node (a receiver, an argument list, or a block present)
+        // is. Verified against a real parse, not guessed.
+        callTypes: ['call'],
+        callFunctionField: 'method',
+        // Ruby's grammar has no dedicated import-statement node type at all — `require '...'` and
+        // `require_relative '...'` are ordinary method calls (see `rubyRequireImport` in extract.ts, wired
+        // through a dedicated dispatch branch the same way `commonJsRequireImport` is for CommonJS, rather
+        // than through this table, which has no node type to name here).
+        importTypes: [],
+        // A `{ ... }`/`do ... end` block attached to a call, and a `->() { ... }` lambda's own block body
+        // (itself a `block` node), can all contain a statement — a `var`/`local` inside one is still
+        // block-local, not a workspace symbol, the same reasoning `ECMASCRIPT_BARE_FUNCTION_SCOPE_TYPES`
+        // applies to a callback. Verified against a real parse, not guessed.
+        bareFunctionScopeTypes: ['block', 'do_block', 'lambda'],
+    },
+    {
+        language: 'zig',
+        extensions: ['.zig'],
+        wasmFile: 'tree-sitter-zig.wasm',
+        definitions: [
+            // A method is a `function_declaration` directly inside a struct/enum/union's own body — the same
+            // node type a free function uses (Zig draws no separate node type the way most languages with a
+            // dedicated method/function split do), so each container kind gets its own `parentType`-guarded
+            // rule, tried before the unrestricted `function` rule below falls through to everything else — the
+            // same precedent C++'s method rule follows for its own shared `function_definition` node type.
+            // Verified against a real parse, not guessed.
+            { nodeType: 'function_declaration', kind: 'method', nameField: 'name', parentType: 'struct_declaration' },
+            { nodeType: 'function_declaration', kind: 'method', nameField: 'name', parentType: 'enum_declaration' },
+            { nodeType: 'function_declaration', kind: 'method', nameField: 'name', parentType: 'union_declaration' },
+            { nodeType: 'function_declaration', kind: 'function', nameField: 'name' },
+            // An enum member and a struct/union member share the very same `container_field` node type —
+            // unlike every other language's dedicated bare-enum-member shape, Zig draws no grammar-level
+            // distinction at all, so this is the one `parentType` this file needs to split them back apart;
+            // tried first, before the unrestricted `field` rule below falls through to a struct/union member.
+            // Verified against a real parse, not guessed.
+            { nodeType: 'container_field', kind: 'enum_member', nameField: 'name', parentType: 'enum_declaration' },
+            { nodeType: 'container_field', kind: 'field', nameField: 'name' },
+            // Zig has no dedicated struct/enum/union *statement* the way C/C++/Rust/Java do — a named
+            // container type is always a plain `const`/`var` declaration whose value happens to be a
+            // `struct_declaration`/`enum_declaration`/`union_declaration` literal (`const Point = struct {
+            // ... };`), and this same node type is also how Zig spells an ordinary top-level constant, a
+            // mutable global, *and* a std-library import (`const std = @import("std");`) — verified against a
+            // real parse. `variable_declaration` binds neither its name nor its value to a field at all (both
+            // are purely positional children, unlike every other grammar this package extracts a name from),
+            // so this uses `FIRST_CHILD_NAME_FIELD` for the name; the reported `kind` (`struct`/`enum`/
+            // `constant`/`variable`) is not fixed by this one static rule at all — `DefinitionRule.kind` has no
+            // way to vary by a value's shape the way this needs, so `extractFile` computes it per node via
+            // `zigDeclarationKind` instead (see there), and an `@import(...)` value is additionally recorded as
+            // an import binding via `zigImportBinding`, the same "also captured as an ordinary variable"
+            // precedent CommonJS's `require()` already sets. `scopeRestricted` applies uniformly to every kind
+            // this rule can produce, including a locally-declared struct/enum/union — unlike a Rust `fn` nested
+            // in another `fn` (still captured at any depth, since Rust's grammar gives a nested function its
+            // own distinct, unambiguous node type), Zig's local type declaration shares its node type with an
+            // ordinary local variable with no structural way to split the two without inspecting the value
+            // first, and this file's `scopeRestricted` gate runs before that inspection — a local type
+            // declaration inside a function is rare enough in idiomatic Zig that this file accepts missing it,
+            // the same "prefer a clean uniform rule over a fiddly special case" precedent already guiding this
+            // package's simpler choices elsewhere.
+            { nodeType: 'variable_declaration', kind: 'variable', nameField: FIRST_CHILD_NAME_FIELD, scopeRestricted: true },
+        ],
+        callTypes: ['call_expression'],
+        callFunctionField: 'function',
+        // No dedicated import-statement node type exists — `@import(...)` is an ordinary builtin-function
+        // call bound through the same `variable_declaration` shape the type/constant/variable rule above
+        // already matches (see `zigImportBinding` in extract.ts), not a distinct node type this table could
+        // name here.
+        importTypes: [],
+        // `test "name" { ... }` and `comptime { ... }` are Zig's own top-level block constructs — neither is
+        // itself captured as a definition (matching this file's existing "block, not a symbol" treatment of
+        // an anonymous callback), but a `const`/`var` directly inside either is still block-local, not a
+        // workspace symbol, so both push `'other'` scope for their body the same way a callback's function
+        // value does elsewhere in this file. Verified against a real parse, not guessed.
+        bareFunctionScopeTypes: ['test_declaration', 'comptime_declaration'],
+    },
+    {
+        language: 'kotlin',
+        extensions: ['.kt', '.kts'],
+        wasmFile: 'tree-sitter-kotlin.wasm',
+        definitions: [
+            // Kotlin's grammar gives `class`/`interface`/`enum class` the very same `class_declaration` node
+            // type, distinguished only by a bare `interface`/`enum` keyword among its own children (`interface
+            // Shape {}` carries a bare `interface` token, `enum class Color {}` carries both a bare `enum` and
+            // a bare `class` token, a plain `class Foo {}` carries only `class`) — no rule here can vary `kind`
+            // by a keyword the way this needs, so `extractFile` computes it via `kotlinClassKind` instead (see
+            // there), the same "kind computed per node, not fixed per rule" precedent Zig's `variable_declaration`
+            // entry already establishes above. Verified against a real parse, not guessed.
+            { nodeType: 'class_declaration', kind: 'class', nameField: KOTLIN_NAME_FIELD },
+            // A method is a `function_declaration` directly inside a `class_body` — the same node type a
+            // top-level function uses (including one inside a `companion_object`'s own nested `class_body`,
+            // still reported as a method of the enclosing type) — tried first, before the unrestricted
+            // `function` rule below falls through to everything else. Verified against a real parse.
+            { nodeType: 'function_declaration', kind: 'method', nameField: KOTLIN_NAME_FIELD, parentType: 'class_body' },
+            { nodeType: 'function_declaration', kind: 'function', nameField: KOTLIN_NAME_FIELD },
+            // An enum constant — verified against a real parse, not guessed; can only ever appear directly
+            // inside an `enum_class_body`, so — like Go's/Rust's/Zig's own field rules — no
+            // `scopeRestricted`/`parentType` guard is needed: the node type itself is unambiguous.
+            { nodeType: 'enum_entry', kind: 'enum_member', nameField: KOTLIN_NAME_FIELD },
+            // Deliberately no `field`/`property`/`variable`/`constant` kind at all: a `property_declaration`
+            // (`val`/`var`, at class-member, top-level, or local scope) binds its declared name two levels
+            // down, inside its own nested `variable_declaration` child, itself positioned after an optional
+            // leading `modifiers` node the same way a captured declaration is — extracting it cleanly would
+            // need its own multi-level, fully positional (there being no fields at all) navigation on top of
+            // everything `KOTLIN_NAME_FIELD` already handles, and this file's "don't guess/don't overreach"
+            // precedent (already applied to Lua's/Ruby's own locally-bound values) draws the line here instead.
+        ],
+        // `call_expression`'s callee is never bound to a field either — see `kotlinCallee` in extract.ts,
+        // consulted directly by a dedicated dispatch branch in `extractFile` rather than through
+        // `callFunctionField`, which (like every other field name) can never resolve anything for this
+        // grammar. `function` is kept only as a placeholder so this table entry still type-checks as a
+        // normal `LanguageSpec`; it is never actually read for Kotlin.
+        callTypes: ['call_expression'],
+        callFunctionField: 'function',
+        importTypes: ['import_header'],
+        // No anonymous-function-literal shape needs special-casing: a lambda's body is a `{ ... }` block
+        // that can contain a statement, exactly like every captured `function_declaration`'s own body, but
+        // this file already declines to capture any local `val`/`var` at all for Kotlin (see above), so
+        // there is currently no scope-restricted rule this could matter to.
+        bareFunctionScopeTypes: [],
+    },
+    {
+        language: 'swift',
+        extensions: ['.swift'],
+        wasmFile: 'tree-sitter-swift.wasm',
+        definitions: [
+            // `struct`/`class`/`enum` all share this one node type, distinguished by a `declaration_kind`
+            // field whose value node's own type is directly `struct`/`class`/`enum` (an unusual but verified
+            // shape — no other grammar this package extracts from promotes a bare keyword to its own field
+            // value this way) — no rule can vary `kind` by that field's value, so `extractFile` computes it
+            // via `swiftDeclarationKind` instead, the same "kind computed per node" precedent Zig's
+            // `variable_declaration`/Kotlin's `class_declaration` entries already establish above. A
+            // `protocol` is Swift's own separate `protocol_declaration` node type instead — verified against a
+            // real parse, not guessed.
+            { nodeType: 'class_declaration', kind: 'class', nameField: 'name' },
+            { nodeType: 'protocol_declaration', kind: 'interface', nameField: 'name' },
+            // A method is a `function_declaration` directly inside a `class_body` — the same node type a
+            // top-level function uses — tried first, before the unrestricted `function` rule below falls
+            // through to everything else. A protocol's own method *signature* (`func area() -> Double`, no
+            // body) is a distinct node type, `protocol_function_declaration`, always directly inside a
+            // `protocol_body` — unambiguous, so no `parentType` guard is needed for it. Both use
+            // `SWIFT_FUNCTION_NAME_FIELD`, not a plain `'name'` field, because either one with an explicit
+            // return type binds two nodes to that field (see `SWIFT_FUNCTION_NAME_FIELD`'s own doc comment) —
+            // verified against a real parse, not guessed.
+            { nodeType: 'function_declaration', kind: 'method', nameField: SWIFT_FUNCTION_NAME_FIELD, parentType: 'class_body' },
+            { nodeType: 'function_declaration', kind: 'function', nameField: SWIFT_FUNCTION_NAME_FIELD },
+            { nodeType: 'protocol_function_declaration', kind: 'method', nameField: SWIFT_FUNCTION_NAME_FIELD },
+            // An enum case — verified against a real parse, not guessed; can only ever appear directly inside
+            // an `enum_class_body`, so — like every other language's own unambiguous member node type — no
+            // `scopeRestricted`/`parentType` guard is needed.
+            { nodeType: 'enum_entry', kind: 'enum_member', nameField: 'name' },
+            // A struct/class stored property (`var x: Int`/`let x: Int` directly inside a `class_body`) —
+            // `property_declaration` is also how Swift spells a top-level or function-local `var`/`let`
+            // binding (the very same node type, see the fallback rule below), so this is tried first, guarded
+            // to only the class-member shape; a property can never legitimately sit anywhere a
+            // `scopeRestricted` gate would exclude it (a class/struct body is never treated as `'other'`
+            // scope), so this rule itself needs no such gate either.
+            { nodeType: 'property_declaration', kind: 'field', nameField: SWIFT_PROPERTY_NAME_FIELD, parentType: 'class_body' },
+            // A top-level or function-local `var`/`let` binding — `DefinitionRule.kind` cannot vary by the
+            // `value_binding_pattern` child's own keyword the way this needs, so `extractFile` computes
+            // `constant`/`variable` via `swiftDeclarationKind` (the same function also reports `field` for the
+            // rule above's match, since it inspects the node's actual parent rather than trusting which rule
+            // fired — see there). `scopeRestricted` excludes a function-local binding, matching every other
+            // language's own local-variable precedent.
+            { nodeType: 'property_declaration', kind: 'variable', nameField: SWIFT_PROPERTY_NAME_FIELD, scopeRestricted: true },
+        ],
+        // `call_expression` binds no field for its callee at all (verified against a real parse) — see
+        // `swiftCallee` in extract.ts, consulted directly by a dedicated dispatch branch in `extractFile`
+        // rather than through `callFunctionField`, which can never resolve anything for this node type.
+        // `target` is kept only as a placeholder so this table entry still type-checks as a normal
+        // `LanguageSpec`; it is never actually read for Swift.
+        callTypes: ['call_expression'],
+        callFunctionField: 'target',
+        importTypes: ['import_declaration'],
+        // A closure literal (`{ (x: Int) -> Int in ... }`, e.g. a callback argument) is never itself
+        // captured as a definition — but a `let`/`var` inside its body is still closure-local, not a
+        // workspace symbol, the same reasoning `ECMASCRIPT_BARE_FUNCTION_SCOPE_TYPES` applies to a callback.
+        // Verified against a real parse, not guessed.
+        bareFunctionScopeTypes: ['lambda_literal'],
+    },
+    {
+        language: 'dart',
+        extensions: ['.dart'],
+        wasmFile: 'tree-sitter-dart.wasm',
+        definitions: [
+            { nodeType: 'class_definition', kind: 'class', nameField: 'name' },
+            // A method's `function_signature` sits directly inside a `method_signature` wrapper; an abstract
+            // method (interface-only) signature (`double area();`, no body) instead sits inside a plain
+            // `declaration` whose own parent is the `class_body` — both tried before the unrestricted
+            // `function` rule below falls through to a top-level function. Verified against a real parse, not
+            // guessed.
+            { nodeType: 'function_signature', kind: 'method', nameField: 'name', parentType: 'method_signature' },
+            { nodeType: 'function_signature', kind: 'method', nameField: 'name', parentType: 'declaration', grandparentType: 'class_body' },
+            { nodeType: 'function_signature', kind: 'function', nameField: 'name' },
+            // A constructor (`Point(this.x, this.y);`) is its own node type, `constructor_signature`, wrapped
+            // by the very same `declaration` node type a field uses — matched directly here regardless of that
+            // wrapper (see `DART_FIELD_NAME_FIELD`'s doc comment). No dedicated `constructor` seam kind exists;
+            // a constructor is a method in every way this package's graph cares about, matching Java's/C#'s own
+            // constructor→`method` precedent.
+            { nodeType: 'constructor_signature', kind: 'method', nameField: 'name' },
+            { nodeType: 'enum_declaration', kind: 'enum', nameField: 'name' },
+            // An enum case — verified against a real parse, not guessed; can only ever appear directly inside
+            // an `enum_body`, so — like every other language's own unambiguous member node type — no
+            // `scopeRestricted`/`parentType` guard is needed.
+            { nodeType: 'enum_constant', kind: 'enum_member', nameField: 'name' },
+            // A class/struct field — see `DART_FIELD_NAME_FIELD`. Restricted to a direct `class_body` child
+            // since Dart uses an entirely different, already-unambiguous node type for a local variable
+            // (`local_variable_declaration`), so no `scopeRestricted` gate is needed either — this rule simply
+            // never matches one. A top-level `declaration` (Dart also allows a bare top-level `var`/`final`)
+            // is deliberately not captured at all — same "don't overreach" precedent this file already applies
+            // to a comparably rare shape elsewhere.
+            { nodeType: 'declaration', kind: 'field', nameField: DART_FIELD_NAME_FIELD, parentType: 'class_body' },
+        ],
+        // Dart's grammar has no call-expression node type at all — a call is a flat `identifier` followed by
+        // zero or more `selector` children, where a call is whichever `selector` happens to be an
+        // `argument_part` rather than a `.property` access; resolving its callee means walking backward
+        // through preceding siblings, not reading a field off a single call node the way every other
+        // language's `RawCall` extraction in this file works. Capturing this would need a structurally new,
+        // sibling-walking resolution strategy this package's call model does not support today, so this
+        // package captures no call sites for Dart at all — a real, verified limitation, not a guess. `name`
+        // is kept only as a placeholder so this table entry still type-checks as a normal `LanguageSpec`; it
+        // is never read, since `callTypes` is empty.
+        callTypes: [],
+        callFunctionField: 'name',
+        // Targets `import_specification` directly (nested inside `import_or_export` → `library_import`)
+        // rather than either wrapper — the walk reaches it regardless during ordinary recursion. A Dart
+        // `export` statement (`import_or_export` → `library_export`) is deliberately not captured: unlike an
+        // import, it re-exports the current file's own symbols to *its* importers, a different relationship
+        // than the "this file's own binding" every other `RawImport` in this package represents.
+        importTypes: ['import_specification'],
+        bareFunctionScopeTypes: [],
+    },
+    {
+        language: 'scala',
+        extensions: ['.scala', '.sc'],
+        wasmFile: 'tree-sitter-scala.wasm',
+        definitions: [
+            { nodeType: 'class_definition', kind: 'class', nameField: 'name' },
+            // A singleton `object` has no dedicated seam kind of its own; `class` is the closest existing fit —
+            // it shares `class_definition`'s exact shape (a `template_body`, an optional `extend` clause) and
+            // behaves like an ordinary class with a single implicit instance, matching Java's/C#'s own
+            // record→`class` precedent for a related-but-distinct construct.
+            { nodeType: 'object_definition', kind: 'class', nameField: 'name' },
+            { nodeType: 'trait_definition', kind: 'trait', nameField: 'name' },
+            // A method is a `function_definition`/`function_declaration` directly inside a `template_body` —
+            // the same node type a top-level function uses — tried first, before the unrestricted `function`
+            // rule below falls through to everything else. A trait's own method *signature* (`def area():
+            // Double`, no body) is `function_declaration`, always directly inside a `template_body` too (a
+            // trait's own), so no `parentType` guard is needed for that one — unambiguous by node type alone.
+            // Verified against a real parse, not guessed.
+            { nodeType: 'function_definition', kind: 'method', nameField: 'name', parentType: 'template_body' },
+            { nodeType: 'function_definition', kind: 'function', nameField: 'name' },
+            { nodeType: 'function_declaration', kind: 'method', nameField: 'name' },
+            // A class/trait/object member (`val x = 1` directly inside a `template_body`) — tried first, since
+            // this same node type is also how Scala spells a top-level or function-local immutable binding
+            // (the fallback rule below). `nameNodeTypes` rejects a destructuring pattern (`val (a, b) = ...`,
+            // `pattern` binds a `tuple_pattern`, not a bare `identifier`) rather than name it after a shape this
+            // package does not attempt to resolve, the same "don't guess" precedent `pythonBinding`/
+            // `ecmascriptImports` already follow. `var_definition` (a mutable binding) follows the identical
+            // split, reporting `variable` instead of `constant` for its own module/local-scope fallback.
+            // Verified against a real parse, not guessed.
+            { nodeType: 'val_definition', kind: 'field', nameField: 'pattern', nameNodeTypes: ['identifier'], parentType: 'template_body' },
+            { nodeType: 'val_definition', kind: 'constant', nameField: 'pattern', nameNodeTypes: ['identifier'], scopeRestricted: true },
+            { nodeType: 'var_definition', kind: 'field', nameField: 'pattern', nameNodeTypes: ['identifier'], parentType: 'template_body' },
+            { nodeType: 'var_definition', kind: 'variable', nameField: 'pattern', nameNodeTypes: ['identifier'], scopeRestricted: true },
+            // A primary constructor parameter (`class Point(val x: Int, val y: Int)`) — a very common Scala
+            // idiom for declaring fields directly in the class header instead of the body. Can only ever
+            // appear inside a `class_parameters` list, so — like every other language's own unambiguous member
+            // node type — no `scopeRestricted`/`parentType` guard is needed. Verified against a real parse,
+            // not guessed.
+            { nodeType: 'class_parameter', kind: 'field', nameField: 'name' },
+        ],
+        // `call_expression`'s callee sits in its own `function` field directly — a bare call
+        // (`add(1, 2)`)'s field value is a plain `identifier`; a member call (`p.length()`)'s is a
+        // `field_expression` instead, whose own `field` field names the callee and whose `value` field holds
+        // the receiver — both already handled by this file's existing generic `calleeName`/`isBareCallee`
+        // logic (the same `field` fallback Rust's `field_expression` already uses), so this language needs no
+        // call-specific dispatch of its own, unlike Kotlin/Swift/Lua/Ruby. Verified against a real parse, not
+        // guessed.
+        callTypes: ['call_expression'],
+        callFunctionField: 'function',
+        importTypes: ['import_declaration'],
+        // No anonymous-function-literal shape is special-cased here — this file's own attempt to write one
+        // parsed ambiguously as an `infix_expression` rather than a dedicated node type, an inconclusive
+        // result this package declines to guess a rule from; the practical impact is limited to a `val`/`var`
+        // inside a closure literal passed as a module-level argument, a rare pattern in idiomatic Scala.
+        bareFunctionScopeTypes: [],
+    },
 ];
 /**
  * The grammar for a file extension, or `undefined` when this package indexes nothing for it.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-plugin-codegraph-tree-sitter",
-  "version": "0.1.4",
+  "version": "0.1.5",
   "description": "Self-built code-graph indexer for DeepSeek Harness — parses a workspace with web-tree-sitter and writes schema version 4 to .codegraph/codegraph.db, the same on-disk format the codegraph CLI writes, so no external indexer is required",
   "keywords": [
     "dsh",
@@ -51,7 +51,7 @@
     "@deepseek-ai/schemastery": "^3.18.1",
     "tree-sitter-wasms": "^0.1.13",
     "web-tree-sitter": "^0.25.10",
-    "dsh-plugin-codegraph-service": "^0.1.4"
+    "dsh-plugin-codegraph-service": "^0.1.5"
   },
   "peerDependencies": {
     "@deepseek-ai/cordis": ">=4.0.1",