TypeScript backend silently shadows duplicate signatures where the Java backend raises

[rahlk]

The Java and TypeScript backends handle the same condition — two declarations spelling one name — with opposite failure modes. Java refuses; TypeScript overwrites without a word.

Java: raises

cldk/analysis/java/codeanalyzer/codeanalyzer.py:347-353, mirrored identically in cldk/analysis/java/neo4j/neo4j_backend.py:657-663:

def _add_type(self, t: JType, path: str) -> None:
    name = t.qualified_name
    if name in self._types:
        raise CodeanalyzerExecutionException(duplicate_type_name(name))
    self._types[name] = t
    self._file_of[name] = path

duplicate_type_name (cldk/analysis/java/backend.py:515) states the rationale: the collision "would make a get_call_graph() node key and a get_class() key ambiguous, so it is surfaced rather than letting the second silently shadow the first."

TypeScript: shadows

cldk/analysis/typescript/codeanalyzer/codeanalyzer.py:298-300:

def _add_type(self, t, fp: str) -> None:
    self._file_of[t.signature] = fp
    self._id_index[t.id] = (t.signature, t.kind)

Plain assignment, no guard. _add_callable (302-305) does the same for self._callables[c.signature] and self._file_of[c.signature]. A second declaration spelling the same signature silently replaces the first, so _file_of reports one file for several declarations and every consumer of it — get_typescript_file, the path= on TSCallableOverview / TSClassOverview, resolve_callable's SliceNode.file — silently attributes code to the wrong file.

Why it matters now

Vendored duplicates are the realistic trigger: several service repos analyzed in one run, each carrying its own copy of a shared internal module. That is exactly the input the Java guard exists to reject. A polyglot monorepo therefore gets a loud, correct refusal on its Java half and a quiet wrong answer on its TypeScript half, from the same analysis.

The Java docstring's own reasoning applies unchanged to TypeScript, so the two should agree. Which direction they agree in is the open question:

1. TypeScript raises too — parity with Java, and consistent with the stated rationale. Breaking for any caller currently relying on last-wins, though it is hard to argue that reliance is intentional.
2. Both warn instead of raising, with the ambiguity recorded so a caller can decide. Softer, but changes documented Java behavior and needs somewhere for the warning to go.

Option 1 is the smaller change and matches the existing intent; worth confirming before implementing, since it turns a silent pass into a hard failure for existing TypeScript callers.

Related: codellm-devkit/codeanalyzer-java#269 — the analyzer that produces these duplicates neither reports nor resolves them correctly, binding every caller to the last source root.

[rahlk]

Proposed approach: id-keyed storage, unchanged signatures

Recording the option considered and the two larger ones rejected, with the measurements behind the choice.

The defect is that the index loses declarations — _file_of[t.signature] = fp keeps the last of N copies. The fix is to stop the index losing them, not to change what callers receive.

Store by can:// id; resolve by name at query time.

• Index on t.id / c.id, which are distinct per copy, so nothing is dropped.
• Keep a name → entries map that may hold several entries per name.
• Public signatures are untouched: get_class(name) -> T | None, get_typescript_file(name) -> str | None. A name with exactly one entry answers as it does today. A name with several is surfaced — the Java backend's stated intent, "surfaced rather than letting the second silently shadow the first" — rather than silently resolved to whichever was written last.

For Java this also converts an index-time refusal into a query-time one. JCodeanalyzer._index currently raises while flattening, so a bundled monorepo is entirely unloadable through the SDK even for queries touching none of the duplicated types. Storing by id means the analysis loads and only the genuinely ambiguous queries fail — strictly more usable, with no loss of safety.

Why not "return all candidates"

The name-addressed methods are on the shared cross-language ABC (cldk/analysis/commons/backend.py:119-136), not the Java backend. Widening their return types touches 44 definitions across 10 files:

Method	Definitions
get_class	10
get_method	10
get_method_parameters	10
get_all_methods_in_class	7
get_all_fields	7

The ABC, plus an in-memory backend, a Neo4j backend and a facade for each of Java, Python and TypeScript. Beyond that: 59 Java methods take a qualified name, 25 call sites read the name-keyed indexes, get_call_graph()'s node keys are f"{klass}.{signature}" and would have to become ids or the graph re-collapses exactly what the index just separated, and every downstream caller unwraps a collection where it used to get one object.

The deciding argument is that the ambiguity is not universal. A well-formed single-service analysis has exactly one class per fully-qualified name. Making every caller in every language handle a list forever — to accommodate an input shape that codellm-devkit/codeanalyzer-java#269 shows is already producing wrong edges — charges Python and TypeScript a permanent tax for a Java monorepo's vendored copies.

If enumerating the copies turns out to be a real need, the additive move is a parallel plural surface (get_classes(name) -> List[T]) alongside the singular one. New code rather than edits to a contract everything depends on, and no existing caller breaks. Worth doing when a caller asks for it, not before.

Sequencing

This should land with or behind codellm-devkit/codeanalyzer-java#269, not ahead of it. The Java index-time raise is currently the only mechanism telling a caller the input is unsafe. Making bundled analyses load cleanly without #269's detection in place means they start silently answering with the wrong-copy edges the analyzer emitted.

[rahlk]

Correction: the premise of this issue is wrong

I filed this by analogy from the Java backend — Java guards, TypeScript does not, therefore TypeScript shadows — without checking whether the condition the guard protects against is reachable in TypeScript. It is not, on either axis where a collision would have to occur.

Across files, the signature already carries the module path:

src/controllers.ts    name=UserController   signature=src/controllers.UserController
src/models.ts         name=Entity           signature=src/models.Entity

So two vendored copies of one class in different files get different signatures (svc-a/lib/shared.Bean vs svc-b/lib/shared.Bean). The exact scenario that breaks Java — five services each vendoring one library, all declaring org.apache.geronimo...RunStatsDataBean — cannot produce a TypeScript signature collision, because the path that distinguishes them is inside the key. Java's qualified_name is package + "." + name, which is path-independent; TypeScript's signature is not. That asymmetry is the whole reason Java needs the guard, and it is the reason TypeScript does not.

Measured on tests/resources/typescript/analysis_json/v2/a4: 40 signatures, 0 duplicated.

Within a file, the analyzer has already collapsed any merge. A module's types is a named map keyed by name, so two declarations spelling one name cannot both reach the SDK — the collision, if any, happens upstream in the emitter, not in _add_type.

Both axes closed, so self._file_of[t.signature] = fp cannot overwrite an entry with a different file. The missing guard guards nothing, and adding one would be dead code.

What remains open, stated as unverified

TypeScript permits declaration merging (interface Foo twice, class Foo + namespace Foo) and overload sets. Whether codeanalyzer-typescript emits those as one entry or somehow as several is upstream behaviour I have not checked; the named-map argument above says it cannot be several by the time the SDK reads it, but that is an argument from the schema shape rather than a measurement of the emitter. If someone wants certainty, the thing to check is how the emitter handles a merged declaration, in codeanalyzer-typescript rather than here.

Consequence

Closing this as not-a-defect unless the declaration-merging case turns up something. The id-keyed storage approach in the previous comment was designed to fix a problem this backend does not have, so it should not be implemented on that basis.

The Java half of the concern is unaffected and still real — JCodeanalyzer._index raises at index time, so a bundled multi-service analysis is entirely unloadable through the SDK. That is worth addressing on its own terms, but it is a Java issue and belongs with codellm-devkit/codeanalyzer-java#269, not under a TypeScript-parity heading.