deprecated-tracker 2.6.0 → 2.7.0

package/CHANGELOG.md

@@ -20,6 +20,25 @@ If a version is missing from the channel you are looking at, the entry below
 tells you which artifact it changed. A release that touches only one artifact is
 noted as such in its own section.
 
+## [2.7.0]
+
+*Ships the internal `2.6.1` work below, which was never released on its own.*
+
+### Added
+
+- **The sidebar and `--help` point at the browser scanner.** A footer link under the scan history opens the page, and the CLI help closes with its URL. The page scans any public GitHub repository without an install, which makes it the one thing here that can be handed to someone who has installed nothing — and until now nothing inside the tool said it existed.
+
+## [2.6.1]
+
+*Internal only — no behaviour changes. The scanner reaches the filesystem through an interface now, which is what lets it run somewhere without one.*
+
+### Internal
+
+- **The scanner no longer imports `fs`.** Every filesystem read it made — one directory walk, one folder-existence check, one `stat` for the program cache, and the file reader `tsconfig.json` is parsed with — now goes through a `ScannerPlatform` passed to the constructor. The default is the real filesystem, so the extension and the CLI behave exactly as before; what changes is that a caller can supply a platform backed by something else. Detection logic is untouched.
+- **`ts.createProgram` is given a compiler host.** It was called without one, which makes TypeScript build a host out of `ts.sys` — a global that does not exist outside Node, and the single reason the scanner could not be bundled for a browser even with a virtual filesystem in place.
+- **The requirements check no longer loads the TypeScript compiler.** It only needs to know whether a `tsconfig.json` exists anywhere, so directory listing lives in its own module. Importing `typescript` evaluates `ts.sys` at module load, which reads `fs.realpath.native` — enough to break any caller whose tests mock `fs`, which is exactly what happened while making this change.
+- **A browser bundle, built and smoke-tested.** `npm run build:web` type-checks and bundles the scanner for a browser: `path` is aliased to a POSIX shim, `fs` to a module whose every export throws rather than silently returning nothing, `process.platform` is replaced with a literal, and `setImmediate` is injected as a `setTimeout`. `npm run smoke:web` runs the built bundle against a set of files held in memory and asserts it finds the declarations, the call sites, the link between them and the deprecation reason. Neither the `.vsix` nor the npm tarball carries any of it.
+
 ## [2.6.0]
 
 ### Added

package/README.md

@@ -2,6 +2,8 @@
 
 Find deprecated code — and everywhere you still use it — in TypeScript and JavaScript projects, from the command line.
 
+**See it before you install it:** [scan any public GitHub repository in your browser](https://milad-hub.github.io/deprecated-tracker/) — the same scanner, running in a page. The CLI adds your dependencies, the standard library, and an exit code CI can gate on.
+
 Most "find deprecated code" tools grep for `@deprecated` and show you the declarations. This one uses the TypeScript type checker, so it also finds every **usage** of a deprecated symbol, including calls into deprecated APIs from your dependencies. That's the part you need when planning a migration: not "what is deprecated", but "where am I still using it".
 
 ```bash
@@ -76,14 +78,18 @@ npx deprecated-tracker --files src/a.ts src/b.ts --format json
 {
   "passed": false,
   "total": 1,
+  "summary": { "documented": 1, "bare": 0, "unused": 0 },
   "items": [
     { "name": "oldApi", "kind": "usage", "file": "src/a.ts",
-      "line": 12, "character": 10, "reason": "Use newApi instead" }
+      "line": 12, "character": 10, "reason": "Use newApi instead",
+      "declaration": { "name": "oldApi", "file": "src/api.ts", "line": 4 } }
   ]
 }
 ```
 
-`items[].reason` carries the `@deprecated` text — usually the replacement instruction, and the field to act on.
+`items[].reason` carries the `@deprecated` text — usually the replacement instruction, and the field to act on. `declaration` is present on a usage and points at the symbol it reaches, so a call site can be traced without a second scan.
+
+`summary` counts **declarations**, not items, so it does not add up to `total`: *documented* has a reason and is still called, *bare* is deprecated with no explanation, *unused* is called nowhere and is the cheapest thing to delete. The `text` report prints the same three counts under the headline.
 
 ## Options