Rewrite JS parser and Segmenter:

[tmihalac]

• Replaced esprima-based JavaScript segmenter with tree-sitter for reliable parsing of modern JS syntax (optional chaining, nullish coalescing, top-level await)
  • Fixed JS function name extraction: keyword filtering, position-aware matching, redundant pattern removal, generator/TypeScript/anonymous-export support
  • Added build-artifact filtering (should_skip) that excludes app-level dist/, build/static/, .min.js while preserving node_modules/*/dist/ as legitimate third-party source
  • Added empty-name guards in CCA BFS to prevent documents with unextractable function names from entering call-chain analysis
  • Fixed _get_function_calls regex to detect calls through optional chaining (obj?.method())

Fixes https://redhat.atlassian.net/browse/APPENG-5453

[vbelouso]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[tmihalac]

/test-heavy

[tmihalac]

/test-heavy

[zvigrinberg]

@tmihalac Looks very good in overall, performance wise, and supporting better a modern JS ESM Syntax.

Please see some minor comments.

[zvigrinberg]

@tmihalac Not sure if it's critical, but anyway, You're missing here the following reserved keywords in js:

case
default
export
false
true
import
in
null
super
this

[tmihalac]

These keywords (default, case, export,
import, in, super, this) are deliberately excluded from _JS_KEYWORDS because
they're valid method names in JS (e.g., commander.default(), queryBuilder.in(),
serializer.export()).

[zvigrinberg]

@tmihalac these are not valid function names in javascript, only as methods under class.
But because it's cascading to it after checking functions with regex so i would say it is OK....
But it's also applies for some of the keywords in _JS_KEYWORDS set

Welcome to Node.js v22.22.2.
Type ".help" for more information.
> class Test {
...   constructor(arg1, arg2) {
...     this.arg1 = arg1;
...     this.arg2 = arg2;
...   }
... 
...   export() {
...     return `This is a ${this.arg1} ${this.arg2}.`;
...   }
... 
...   delete() {
...     return "delete can be defined as method name" ;
...   }
...   
...   with() {
...     return "with can be defined as method name";
...   }
...   
... }
undefined
> 
> let test = new Test(1,2)
undefined
> test.with()
'with can be defined as method name'
> test.delete()
'delete can be defined as method name'
> 

[zvigrinberg]

@tmihalac It's factual that i==0 in that case, so why not:

Suggested change

	if i + 1 < len(parts) - 1:
	if 1 < len(parts) - 1:

Or equivalently:

Suggested change

	if i + 1 < len(parts) - 1:
	if 2 < len(parts) :

[zvigrinberg]

@tmihalac I Would add comments to each one of the regex(s) , what exactly it handles, so it will be clear exactly what is the target of each one of the regex(s), as if one will add a new regex to handle an edge-case, it won't break anything or won't have side effects ( the precedence of the regexs here are crucial), because one would have a better clarity about all the regex(s).
another useful objective for this comments about regex(s) is to order the current ones with numbers ( 1, 2, 3....), so future additions would see if their target edge cases are not targeted yet they will be placed underneath in a new regex ( that will be documented and numbered as well), or will fix an existing related regex with something small it misses.

[zvigrinberg]

@tmihalac This is a reasonable assumption covering 99.999% of the cases :)

[zvigrinberg]

@tmihalac It does the job..
Wouldn't it be cleaner If we'll add this should_skip attribute to all segmenters with constant default false?

[tmihalac]

The base class is langchain's

[zvigrinberg]

@tmihalac You're right that for langchain' segmenters you don't have control over it, but in ours we have ( subclasses)...
So anyway we need that one.