feat(extraction): add ArkTS language support

[DXX5678]

feat(extraction): add ArkTS language support

Summary

Adds tree-sitter-based extraction support for ArkTS — the TypeScript superset used in Huawei's HarmonyOS / ArkUI application development. ArkTS files use the .ets extension and introduce the struct keyword for component definitions (@Component struct X { ... }), along with ArkUI-specific decorators (@State, @Prop, @Link, @Builder, etc.).

Changes

File	Change
src/types.ts	Register 'arkts' in LANGUAGES
src/extraction/grammars.ts	Add .ets → 'arkts' extension mapping, WASM grammar registration, local-wasm loading path, and display name
src/extraction/languages/arkts.ts	New — ArkTS LanguageExtractor (extends TypeScript extractor, adds structTypes: ['struct_declaration'])
src/extraction/languages/index.ts	Import + register arktsExtractor
src/extraction/wasm/tree-sitter-arkts.wasm	New — tree-sitter-arkts grammar (ABI 15, sourced from tree-sitter-arkts-open)

No changes were needed to the core extractor (tree-sitter.ts, parse-worker.ts, tree-sitter-types.ts). The existing LanguageExtractor interface and structTypes dispatch in visitNode handle ArkTS out of the box. ArkTS-specific decorators (@Component, @State, etc.) are already captured by the shared extractDecoratorsFor path.

Architecture

ArkTS is treated as a distinct language (not a TypeScript variant) because its grammar produces unique AST node types (struct_declaration). The extractor extends the TypeScript extractor via object spread and overrides only structTypes:

export const arktsExtractor: LanguageExtractor = {
  ...typescriptExtractor,
  structTypes: ['struct_declaration'],
};

The dispatch chain in TreeSitterExtractor.visitNode flows:

struct_declaration
  → structTypes.includes(nodeType)      ✅ matches
  → extractStruct(node)                 ✅ produces Node + containment edges
  → extractDecoratorsFor(node, nodeId)  ✅ captures @Component, @State, etc.
  → visitNode children                  ✅ extracts methods (build(), aboutToAppear(), etc.)

Verification

Tested against a real HarmonyOS application (233 files, 228 .ets):

Files:  233 (arkts: 228, typescript: 2, xml: 3)
Nodes:  6,085 (121 struct, 4,106 method, 454 interface, 842 import, …)
Edges:  11,902

All .ets files parse without errors. struct nodes (e.g. SpecialDetailScreen, MainPage) are correctly classified with their build() and lifecycle methods, decorators, and containment edges.

[DXX5678]

Resolves #648

[clipsheep6]

ARKUI Framework-aware Routes optimize is also needed I think, tree-sitter is the first step for code search in arkts repos, since closure is not easy for agents working with arkui

[DXX5678]

I agree – tree-sitter is just the first step for ArkTS repos. In ArkUI, most of the “logic” lives in @State/@prop fields and @builder closures, and UI event handlers (onClick, onChange, etc.) form chains that are really hard for agents to follow if we only have plain call edges.

And I plan to add ArkUI Framework-aware Routes and state/event chains, roughly:
Add arkui_page / arkui_route nodes for @Page/@component structs and router_map / main_pages.json entries;
Add arkui_state_dep and arkui_event_chain edges to connect @State → @builder → UI event handlers;
Expose these in codegraph_search / codegraph_explore so agents can trace “page → builder → event → state” in one go.