codeanalyzer-typescript 0.1.0__py3-none-win_amd64.whl → 0.2.0__py3-none-win_amd64.whl

codeanalyzer_typescript/__init__.py

@@ -1,6 +1,6 @@
-"""Prebuilt ``codeanalyzer-typescript`` backend binary for CLDK.
+"""Prebuilt ``cants`` (codeanalyzer-typescript) backend binary for CLDK.
 
-This package carries the platform-specific, self-contained ``codeanalyzer-typescript``
+This package carries the platform-specific, self-contained ``cants``
 executable (built from this repo with ``bun build --compile``) and exposes its
 filesystem path. CLDK's Python SDK depends on this package and calls
 :func:`bin_path` to locate the analyzer, exactly as it imports ``codeanalyzer-python``
@@ -18,15 +18,15 @@ import sys
 from importlib import resources
 from pathlib import Path
 
-__version__ = "0.1.0"
+__version__ = "0.2.0"
 
 __all__ = ["bin_path", "__version__"]
 
-_BINARY_NAME = "codeanalyzer-typescript" + (".exe" if sys.platform == "win32" else "")
+_BINARY_NAME = "cants" + (".exe" if sys.platform == "win32" else "")
 
 
 def bin_path() -> Path:
-    """Return the absolute path to the bundled ``codeanalyzer-typescript`` binary.
+    """Return the absolute path to the bundled ``cants`` binary.
 
     Raises:
         FileNotFoundError: if the wheel for this platform did not include a binary
@@ -38,7 +38,7 @@ def bin_path() -> Path:
 
     if not path.exists():
         raise FileNotFoundError(
-            f"Bundled codeanalyzer-typescript binary not found at {path}. "
+            f"Bundled cants binary not found at {path}. "
             "This usually means there is no prebuilt wheel for your platform; "
             "build the binary with `bun build --compile` and point CLDK at it via "
             "analysis_backend_path or $CODEANALYZER_TS_BIN."

codeanalyzer_typescript-0.2.0.dist-info/METADATA

@@ -0,0 +1,209 @@
+Metadata-Version: 2.4
+Name: codeanalyzer-typescript
+Version: 0.2.0
+Summary: Prebuilt codeanalyzer-typescript backend binary for CLDK (codellm-devkit).
+Project-URL: Homepage, https://codellm-devkit.info
+Project-URL: Repository, https://github.com/codellm-devkit/codeanalyzer-ts
+Author-email: Rahul Krishna <i.m.ralk@gmail.com>
+License: Apache-2.0
+Keywords: cldk,code analysis,codellm-devkit,typescript
+Classifier: Development Status :: 4 - Beta
+Classifier: License :: OSI Approved :: Apache Software License
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3
+Requires-Python: >=3.8
+Description-Content-Type: text/markdown
+
+![logo](https://github.com/codellm-devkit/codeanalyzer-python/blob/main/docs/assets/logo.png?raw=true)
+
+# A TypeScript Static Analysis Toolkit (and Library)
+
+A comprehensive static analysis tool for TypeScript and JavaScript source code that
+produces the canonical CodeLLM-DevKit (CLDK) `analysis.json` — a symbol table plus a
+resolver-based call graph — using the TypeScript compiler via [ts-morph](https://ts-morph.com/).
+It is the TypeScript backend behind [CLDK](https://github.com/codellm-devkit/python-sdk),
+mirroring its [Python](https://github.com/codellm-devkit/codeanalyzer-python) and
+[Java](https://github.com/codellm-devkit/codeanalyzer-java) siblings.
+
+## Usage
+
+The analyzer provides a command-line interface for performing static analysis on
+TypeScript/JavaScript projects.
+
+### Basic Usage
+
+```bash
+cants --input /path/to/typescript/project
+```
+
+### Command Line Options
+
+To view the available options, run `cants --help`:
+
+```text
+Usage: cants [options]
+
+CLDK TypeScript analyzer — emits the canonical analysis.json
+(symbol table + resolver call graph).
+
+Options:
+  -i, --input <path>             project root to analyze
+  -o, --output <dir>             output directory for analysis.json
+                                 (omit ⇒ compact JSON to stdout)
+  -f, --format <fmt>             output format: json | msgpack (default: "json")
+  -a, --analysis-level <n>       1 = tsc resolver call graph + RTA (default);
+                                 2 = + CodeQL enrichment (default: "1")
+  -t, --target-files <paths...>  restrict analysis to specific files (incremental)
+      --skip-tests               skip test trees (default)
+      --include-tests            include test trees
+      --eager                    force a clean rebuild instead of reusing the cache
+      --lazy                     reuse the cache (default)
+      --no-build                 skip dependency materialization
+                                 (use a prepared node_modules)
+      --no-phantoms              disable phantom (external) nodes for imported/
+                                 required library calls
+  -c, --cache-dir <dir>          cache/intermediate directory
+  -v, --verbose                  increase verbosity (repeatable)
+  -h, --help                     display help for command
+```
+
+### Examples
+
+1. **Basic analysis (symbol table + call graph):**
+   ```bash
+   cants --input ./my-ts-project
+   ```
+
+   This prints the analysis to stdout as compact JSON. To save it instead, use `--output`:
+
+   ```bash
+   cants --input ./my-ts-project --output /path/to/analysis-results
+   ```
+
+   The results are written to `analysis.json` in the specified directory.
+
+2. **Change output format to msgpack:**
+   ```bash
+   cants --input ./my-ts-project --output /path/to/analysis-results --format msgpack
+   ```
+
+   This saves the results to `analysis.msgpack`, a binary format that is more compact for
+   storage and transmission.
+
+3. **Deeper analysis with CodeQL enrichment (experimental):**
+   ```bash
+   cants --input ./my-ts-project --analysis-level 2
+   ```
+
+   Every run produces a symbol table **and** a call graph. At level 1, edges come from the
+   TypeScript compiler's resolver plus Rapid Type Analysis (RTA), with phantom nodes for
+   calls into imported libraries. Level 2 additionally merges in CodeQL-derived edges.
+
+4. **Incremental analysis of specific files:**
+   ```bash
+   cants --input ./my-ts-project --target-files src/a.ts src/b.ts
+   ```
+
+   Restricts the analysis to the named files, reusing the cached analysis for the rest of
+   the project.
+
+5. **Force a clean rebuild with a custom cache directory:**
+   ```bash
+   cants --input ./my-ts-project --eager --cache-dir /path/to/custom-cache
+   ```
+
+   `--eager` rebuilds the analysis cache from scratch. If `--cache-dir` is omitted, the cache
+   defaults to `.codeanalyzer` inside the project root.
+
+## Output
+
+By default, analysis results are printed to stdout as compact JSON. When `--output` is given,
+results are saved to `analysis.json` (or `analysis.msgpack` with `--format msgpack`) in the
+specified directory.
+
+The output document is a `TSApplication` with the following top-level shape:
+
+```jsonc
+{
+  "symbol_table":     { /* file path → module (classes, interfaces, enums,
+                           type aliases, functions, namespaces, variables, …) */ },
+  "call_graph":       [ /* CALL_DEP edges: { source, target, weight,
+                           provenance, tags } keyed by callable signature */ ],
+  "external_symbols": { /* phantom stubs for call targets outside the project
+                           (imported libraries / Node builtins) */ },
+  "entrypoints":      { /* framework-detected entrypoints (empty at level 1) */ }
+}
+```
+
+Caller- and callee-side identifiers are produced by a single signature canonicalizer, so call
+graph `source`/`target` values byte-match the corresponding `symbol_table` (or
+`external_symbols`) keys.
+
+## License
+
+Apache 2.0 — see [LICENSE](./LICENSE).
+
+---
+
+<!-- The sections below document this Python distribution itself; they have no
+     equivalent in the main repository README. -->
+
+## About this package
+
+This distributes the compiled `cants` binary as a set of
+platform-specific Python wheels, published to PyPI as **`codeanalyzer-typescript`**.
+The CLDK Python SDK depends on this package and calls
+`codeanalyzer_typescript.bin_path()` to locate the analyzer binary. The binary is
+built from this repo's `src/` with `bun build --compile`, so it is fully
+self-contained (no Node/Bun needed at runtime).
+
+### Why platform wheels?
+
+A `bun --compile` binary is platform-specific and large (~70 MB) — there is no single
+cross-platform artifact (the way a JVM backend could ship one `.jar`). So we ship **one
+wheel per OS/arch**, tagged `py3-none-<platform>` (the binary is Python-agnostic — no
+per-Python-version matrix), and let pip resolve the correct one at install time. There
+is intentionally no usable sdist: the binary cannot be built without Bun.
+
+### Building & publishing
+
+```bash
+python -m pip install build wheel hatchling twine
+./build_wheels.sh            # cross-compiles every target via Bun, emits ./dist/*.whl
+twine upload dist/*.whl
+```
+
+`build_wheels.sh` loops over the Bun targets, compiles each binary into
+`src/codeanalyzer_typescript/_bin/`, builds a pure wheel, and retags it to the platform.
+Bun cross-compiles all targets from a single host, so this does not need a CI runner
+matrix.
+
+### Versioning
+
+The released version comes from the **git tag**. A push of `vX.Y.Z` triggers the
+release workflow, which derives `X.Y.Z` from the tag, verifies it matches this
+repo's `package.json` `version` (failing fast on mismatch), and stamps it into
+`__init__.py` via `$PKG_VERSION` — hatch reads `__version__` as the wheel version
+(`pyproject.toml` declares `dynamic = ["version"]`). So the GitHub Release tag, the
+PyPI wheel version, and the npm `package.json` version are always in lockstep.
+
+To cut a release: bump `package.json` `version`, then push the matching tag, e.g.
+
+```bash
+npm version 0.2.0 --no-git-tag-version   # or edit package.json
+git commit -am "Release v0.2.0" && git tag v0.2.0 && git push --tags
+```
+
+For a **local** wheel build, override the fallback version explicitly:
+`PKG_VERSION=0.2.0 ./build_wheels.sh`.
+
+One thing still tracked by hand: the python-sdk pin — `[tool.backend-versions]
+codeanalyzer-typescript` and the `dependencies` entry
+`codeanalyzer-typescript==<version>` — must be bumped to consume a new release.
+
+### SDK integration
+
+In the python-sdk, `TSCodeanalyzer._get_codeanalyzer_exec()` resolves the binary in
+this order: `analysis_backend_path` → `$CODEANALYZER_TS_BIN` → **this package** →
+in-tree bundled `bin/`. Adding `codeanalyzer-typescript` to the SDK's `dependencies`
+makes the binary available automatically on install.

codeanalyzer_typescript-0.2.0.dist-info/RECORD

@@ -0,0 +1,6 @@
+codeanalyzer_typescript/__init__.py,sha256=w_G2b2FETBJH7KqvG-e-kOMewShb69rc5--_B53A2ug,1836
+codeanalyzer_typescript/_bin/.gitignore,sha256=_mZ_61eDWQ65V05VrmLP33rSeppQmwCwV8_qsgHUOHM,251
+codeanalyzer_typescript/_bin/cants.exe,sha256=KTRR1UtbgwZmbhPWKga38qCfRjYxKlhT9835Mwnqf8c,111492608
+codeanalyzer_typescript-0.2.0.dist-info/METADATA,sha256=iiupqvPre6UG3Fz74gRdtPbUQtF-4soER-XX8cv2x5k,8518
+codeanalyzer_typescript-0.2.0.dist-info/WHEEL,sha256=pp_iTzO0EBcCvlZZV2dJYp6L2tdDWBsn1ceo50wEt8Q,94
+codeanalyzer_typescript-0.2.0.dist-info/RECORD,,

codeanalyzer_typescript-0.1.0.dist-info/METADATA

@@ -1,76 +0,0 @@
-Metadata-Version: 2.4
-Name: codeanalyzer-typescript
-Version: 0.1.0
-Summary: Prebuilt codeanalyzer-typescript backend binary for CLDK (codellm-devkit).
-Project-URL: Homepage, https://codellm-devkit.info
-Project-URL: Repository, https://github.com/codellm-devkit/codeanalyzer-ts
-Author-email: Rahul Krishna <i.m.ralk@gmail.com>
-License: Apache-2.0
-Keywords: cldk,code analysis,codellm-devkit,typescript
-Classifier: Development Status :: 4 - Beta
-Classifier: License :: OSI Approved :: Apache Software License
-Classifier: Operating System :: OS Independent
-Classifier: Programming Language :: Python :: 3
-Requires-Python: >=3.8
-Description-Content-Type: text/markdown
-
-# codeanalyzer-typescript (Python distribution)
-
-This directory packages the compiled `codeanalyzer-typescript` binary as a set of
-platform-specific Python wheels, published to PyPI as **`codeanalyzer-typescript`**.
-
-The CLDK Python SDK depends on this package and calls `codeanalyzer_typescript.bin_path()`
-to locate the analyzer binary — the same way it imports `codeanalyzer-python` for the
-Python backend. The binary itself is built from this repo's `src/` with
-`bun build --compile`, so it is fully self-contained (no Node/Bun needed at runtime).
-
-## Why platform wheels?
-
-Unlike the Java backend (one cross-platform `.jar`), a `bun --compile` binary is
-platform-specific and large (~70 MB). So we ship **one wheel per OS/arch**, tagged
-`py3-none-<platform>` (the binary is Python-agnostic — no per-Python-version matrix),
-and let pip resolve the correct one at install time. There is intentionally no usable
-sdist: the binary cannot be built without Bun.
-
-## Building & publishing
-
-```bash
-python -m pip install build wheel hatchling twine
-./build_wheels.sh            # cross-compiles every target via Bun, emits ./dist/*.whl
-twine upload dist/*.whl
-```
-
-`build_wheels.sh` loops over the Bun targets, compiles each binary into
-`src/codeanalyzer_typescript/_bin/`, builds a pure wheel, and retags it to the platform.
-Bun cross-compiles all targets from a single host, so this does not need a CI runner
-matrix.
-
-## Versioning
-
-The released version comes from the **git tag**. A push of `vX.Y.Z` triggers the
-release workflow, which derives `X.Y.Z` from the tag, verifies it matches this
-repo's `package.json` `version` (failing fast on mismatch), and stamps it into
-`__init__.py` via `$PKG_VERSION` — hatch reads `__version__` as the wheel version
-(`pyproject.toml` declares `dynamic = ["version"]`). So the GitHub Release tag, the
-PyPI wheel version, and the npm `package.json` version are always in lockstep.
-
-To cut a release: bump `package.json` `version`, then push the matching tag, e.g.
-
-```bash
-npm version 0.2.0 --no-git-tag-version   # or edit package.json
-git commit -am "Release v0.2.0" && git tag v0.2.0 && git push --tags
-```
-
-For a **local** wheel build, override the fallback version explicitly:
-`PKG_VERSION=0.2.0 ./build_wheels.sh`.
-
-One thing still tracked by hand: the python-sdk pin — `[tool.backend-versions]
-codeanalyzer-typescript` and the `dependencies` entry
-`codeanalyzer-typescript==<version>` — must be bumped to consume a new release.
-
-## SDK integration
-
-In the python-sdk, `TSCodeanalyzer._get_codeanalyzer_exec()` resolves the binary in
-this order: `analysis_backend_path` → `$CODEANALYZER_TS_BIN` → **this package** →
-in-tree bundled `bin/`. Adding `codeanalyzer-typescript` to the SDK's `dependencies`
-makes the binary available automatically on install.

codeanalyzer_typescript-0.1.0.dist-info/RECORD

@@ -1,6 +0,0 @@
-codeanalyzer_typescript/__init__.py,sha256=f2JzA_PPc4SU59_EDbYC1YktWFtEWnEwGuj_8ovQypY,1900
-codeanalyzer_typescript/_bin/.gitignore,sha256=_mZ_61eDWQ65V05VrmLP33rSeppQmwCwV8_qsgHUOHM,251
-codeanalyzer_typescript/_bin/codeanalyzer-typescript.exe,sha256=ri0chkdaCeanYd5HqYRIvoij4-9_11bTPFKbhBodIeE,111492608
-codeanalyzer_typescript-0.1.0.dist-info/METADATA,sha256=MzNfbhKNfb4KV85v8PGqbqauwA81aP5Emd4J_FUKL2w,3477
-codeanalyzer_typescript-0.1.0.dist-info/WHEEL,sha256=pp_iTzO0EBcCvlZZV2dJYp6L2tdDWBsn1ceo50wEt8Q,94
-codeanalyzer_typescript-0.1.0.dist-info/RECORD,,