You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
codeanalyzer-typescript v1.6.0 — the graph resolves to text
No breaking changes. Nothing to migrate; every addition below is new surface on the Neo4j
projection. The analysis.json projection is byte-for-byte unchanged from 1.5.3.
The Neo4j graph can now resolve any span to its text
Before this release the two projections disagreed about the primary text, and the graph was the
one that was wrong. analysis.json carries each module's whole-file source; the graph carried
only a content hash and a line pair, while :TSCallable kept a code property — a slice of the
source the graph itself no longer held. The practical effect: nothing narrower than a callable
resolved to text on the graph backend. A class's text, a call site's text, a single statement's
text — none of it was reachable without going back to the JSON.
Two additions fix it, and they work only together:
:TSModule now carries source — the whole file. It is always present: an empty file
yields "", never an absent property, so a consumer can never confuse "the projection didn't
carry this" with "the file is empty".
Every span now carries columns and UTF-8 byte offsets — start_column, end_column, start_byte, end_byte, beside the line pair it already had, across ten node labels.
Together they make any node's text a byte slice of its module's source:
// given a node's start_byte/end_byte and its module's source
Buffer.from(source, 'utf8').subarray(start_byte, end_byte).toString('utf8')
Those are byte offsets, not character offsets, so slice with a byte-aware API — Buffer in
Node, source.encode("utf-8")[lo:hi] in Python. String.slice() runs short the moment a
multibyte character precedes the span.
Why the property names look like the Java analyzer's
They are the Java analyzer's. start_column / end_column / start_byte / end_byte were coined
in codeanalyzer-java and adopted here verbatim, so one slicing rule works across languages: a
database holding both languages previously had sliceable Java nodes and unsliceable TypeScript
ones, and a cross-language "give me the text at this span" query could not be written at all.
Detecting the addition
schema_version stays at 2.0.0 — the graph contract number moves only when every CLDK analyzer
re-baselines together. So these properties are detected by presence, not by a version check.
:TSCallable.code is unchanged and still present, even though it is now derivable. Nothing that
reads it needs to change.
Known limitation
If you reach the graph through python-sdk's TypeScript Neo4j backend, that backend currently
queries the older v1 graph shape and will not surface these properties yet — see codellm-devkit/python-sdk#391. Direct Cypher and the in-memory backend are unaffected.
Also in this release
Release automation now records this analyzer's emitted schemas in codellm-devkit/codeanalyzer-schema
on every tag, so the published graph contract and JSON samples stay in step with what ships (ci(release): record this analyzer's schemas in codeanalyzer-schema #199).
Internal; no effect on analyzer behaviour.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
codeanalyzer-typescript v1.6.0 — the graph resolves to text
No breaking changes. Nothing to migrate; every addition below is new surface on the Neo4j
projection. The
analysis.jsonprojection is byte-for-byte unchanged from 1.5.3.The Neo4j graph can now resolve any span to its text
Before this release the two projections disagreed about the primary text, and the graph was the
one that was wrong.
analysis.jsoncarries each module's whole-filesource; the graph carriedonly a content hash and a line pair, while
:TSCallablekept acodeproperty — a slice of thesource the graph itself no longer held. The practical effect: nothing narrower than a callable
resolved to text on the graph backend. A class's text, a call site's text, a single statement's
text — none of it was reachable without going back to the JSON.
Two additions fix it, and they work only together:
:TSModulenow carriessource— the whole file. It is always present: an empty fileyields
"", never an absent property, so a consumer can never confuse "the projection didn'tcarry this" with "the file is empty".
start_column,end_column,start_byte,end_byte, beside the line pair it already had, across ten node labels.Together they make any node's text a byte slice of its module's source:
Those are byte offsets, not character offsets, so slice with a byte-aware API —
BufferinNode,
source.encode("utf-8")[lo:hi]in Python.String.slice()runs short the moment amultibyte character precedes the span.
Why the property names look like the Java analyzer's
They are the Java analyzer's.
start_column/end_column/start_byte/end_bytewere coinedin codeanalyzer-java and adopted here verbatim, so one slicing rule works across languages: a
database holding both languages previously had sliceable Java nodes and unsliceable TypeScript
ones, and a cross-language "give me the text at this span" query could not be written at all.
Detecting the addition
schema_versionstays at 2.0.0 — the graph contract number moves only when every CLDK analyzerre-baselines together. So these properties are detected by presence, not by a version check.
:TSCallable.codeis unchanged and still present, even though it is now derivable. Nothing thatreads it needs to change.
Known limitation
If you reach the graph through
python-sdk's TypeScript Neo4j backend, that backend currentlyqueries the older v1 graph shape and will not surface these properties yet — see
codellm-devkit/python-sdk#391. Direct Cypher and the in-memory backend are unaffected.
Also in this release
codellm-devkit/codeanalyzer-schemaon every tag, so the published graph contract and JSON samples stay in step with what ships (ci(release): record this analyzer's schemas in codeanalyzer-schema #199).
Internal; no effect on analyzer behaviour.
Upgrade
PyPI:
Homebrew:
Shell installer (prebuilt binary; macOS and Linux):
Download
Links
docs/design/specs/graph-carries-source-and-byte-offsets.mdThis repository keeps no
CHANGELOG.md; the release notes and the linked spec are the record.All reactions