Support Javascript: Codeanalyzer-typescript pin v0.6.0 offers JavaScript support. Python-SDK must make this a supported language.

[rahlk]

Plan

Propagation follow-on from codeanalyzer-typescript #84 / #85 (PR #86). Planning context: roadmap.

Blocked until codeanalyzer-typescript v0.6.0 is published to PyPI.

Problem

The SDK pins the TypeScript analyzer at an exact version:

pyproject.toml:43    "codeanalyzer-typescript==0.4.3",
pyproject.toml:98    codeanalyzer-typescript = "0.4.3"   # [tool.backend-versions], informational

0.6.0 makes JavaScript analyzable for the first time. On 0.4.3 a JavaScript-only project returns an empty symbol table with exit code 0 — no error, no warning — so any SDK caller pointed at a Node/Express app silently gets nothing back. Measured on OWASP NodeGoat: 0 modules on 0.4.3, 27 modules / 59 callables / 184 call-graph edges on 0.6.0.

This is a plain version bump, not a migration: 0.6.0 is still on the v1 schema, which is what cldk/models/typescript/models.py:445 (TSApplication { symbol_table, call_graph }) already models. Nothing in the model layer changes.

Scope boundary

Bumps the pin and proves the new capability reaches SDK consumers. This issue does not:

• migrate the TypeScript model layer to schema v2 — that is the separate, unowned v1→v2/v3 migration (candidate 9 on the roadmap), and 0.6.0 deliberately does not require it;
• touch the Java or Python analyzer pins;
• add JavaScript-specific SDK surface — the existing CLDK.typescript(...) facade covers it, since the analyzer emits the same v1 shape for .js as for .ts.

Goals

• pyproject.toml:43 → codeanalyzer-typescript==0.6.0
• pyproject.toml:98 [tool.backend-versions] → 0.6.0 (informational, but it disagreeing with the real pin is how it rots)
• Add a small JavaScript fixture and an e2e assertion that a .js-only project yields a non-empty symbol table through the SDK — the capability is worthless if nothing proves it arrives
• Re-run the three SDK gates: mocked, e2e, backend-contract

Caveats and known risks

• Analyzer caches are invalidated by this bump. ANALYZER_VERSION moved in lockstep with the release, which is the only thing that invalidates analysis_cache.json — the per-file source hash cannot see that extraction logic changed. First run after upgrading rebuilds from scratch; expect a slower first analysis, not a failure.
• Callable counts increase on unchanged TypeScript sources. 0.6.0 materializes this.x = fn and object-literal methods, which were previously absent — this is language-neutral, so TypeScript projects using those idioms gain callables too. Any SDK test asserting an exact callable or edge count against a fixture will need its expected set updated. This is a correction, not a regression: sample-app output is byte-identical, so only fixtures using the dynamic idioms move.
• --tsc-only still exists (cldk/analysis/commons/backend_config.py:84 documents it as >= 0.4.2), so no config break. Worth noting in passing that on JavaScript it is a bad default — the analyzer's own measurement puts tsc at 53 edges against 184 for the union default.
• Known analyzer gaps that will surface through the SDK and are not bugs in this bump: CommonJS require/module.exports are not modelled at module level (imports/exports stay empty on CJS input), and method calls on untyped receivers produce no library edge (tracked as codeanalyzer-typescript#87).

Definition of done

• Both pin sites read 0.6.0 and agree with each other.
• pytest tests/test_typescript_analysis.py, tests/test_typescript_e2e.py and tests/test_typescript_backend_contract.py all pass against the published 0.6.0 wheel — not a local build.
• The new JavaScript fixture returns a symbol table whose module set equals the fixture's .js files, asserted as an exact set rather than "non-empty", and that test fails against 0.4.3.