Skip to content

feat(extraction): index SAP HANA .xsjs/.xsjslib as JavaScript (#556)#594

Open
maxmilian wants to merge 1 commit into
colbymchenry:mainfrom
maxmilian:fix/556-sap-xsjs-extension
Open

feat(extraction): index SAP HANA .xsjs/.xsjslib as JavaScript (#556)#594
maxmilian wants to merge 1 commit into
colbymchenry:mainfrom
maxmilian:fix/556-sap-xsjs-extension

Conversation

@maxmilian
Copy link
Copy Markdown

@maxmilian maxmilian commented May 31, 2026

Summary

Fixes #556. SAP HANA 1.0 XS classic .xsjs (services) and .xsjslib (libraries) are plain JavaScript (SAP docs), but their extensions weren't mapped, so CodeGraph skipped them entirely.

Fix

  • Add .xsjs and .xsjslibjavascript in EXTENSION_MAP. That map is the single source of truth for both "should we index this file" (isSourceFile derives from it) and grammar selection, so this one change makes the files index and parse with the JS grammar — their functions then surface in search / callers / callees / trace.
  • Add the same two extensions to the JS import-path resolution list, so an ES-style import './helper' from a .xsjs/.xsjslib file resolves to the right on-disk file (removes the asymmetry of indexing the files but not resolving imports between them).

Tests (__tests__/extraction.test.ts)

  • Extension detection: .xsjs / .xsjslibjavascript.
  • End-to-end: indexing a .xsjs (containing SAP $.import / $.db globals) and a .xsjslib file tracks both as JavaScript and extracts their function symbols — proving the JS grammar runs and tolerates SAP runtime globals, not just file-level tracking.

Full suite green locally (npm test).

Scope

Extension + import-path mapping only — no SAP-specific runtime modeling ($.import, $.db, …); those are ordinary member-access/call expressions to the JS grammar (parsed fine, simply unresolved). $.import(...)-based module loading is not turned into edges; that would be SAP-specific resolution beyond this change.

@maxmilian maxmilian force-pushed the fix/556-sap-xsjs-extension branch from d62e14a to 70eaf94 Compare May 31, 2026 14:57
…chenry#556)

SAP HANA 1.0 XS classic `.xsjs` services and `.xsjslib` libraries are
plain JavaScript but were skipped because their extensions weren't mapped.
Map both to the JavaScript grammar via EXTENSION_MAP (the single source of
truth for both index selection and grammar choice), so their symbols are
extracted and surface in search/callers/callees/trace. Also add the two
extensions to the JS import-path resolution list so an ES-style
`import './helper'` from a .xsjs file can resolve to a .xsjslib/.xsjs file.

Tests: extension detection + an end-to-end index (with SAP `$.import` /
`$.db` globals present) proving functions are extracted from .xsjs/.xsjslib,
not just file-level tracking.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@maxmilian maxmilian force-pushed the fix/556-sap-xsjs-extension branch from 70eaf94 to 1564c6a Compare May 31, 2026 15:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SAP xsjs and xsjslib files from SAP HANA 1.0 are js files but ignored by codegraph

1 participant