🔍 Exploring Collections

A database grade collection & DataTable visualizer for the VS Code debugger — for C#, F#, JavaScript and TypeScript.

Sort it, search it, filter it, chart it, export it — while your program sits at a breakpoint.

English · Русский

_{100 000 List<Employee> elements · condition x.Age > 20 · area chart · row details · the status bar reports the retrieval strategy, the request count and the capture time}

🚀 Quick start

1. Install the extension from the Marketplace (or press F5 in a clone of this repo).
2. Start a debug session in any supported language and stop at a breakpoint.
3. Hover the Variables view, right-click a collection → 🔍 Explore collection.
4. Optionally, run the command Exploring Collections: Explore a Collection… from the Command Palette to pick any variable of the current frame.

🧪 No breakpoint? No problem

Data that is hardcoded in the source can be opened without debugging anything. Put the caret in a file that declares a collection literal, open the Command Palette → Exploring Collections: Preview Collection Data from Source, or simply click the 🧪 Preview data CodeLens that appears above the literal:

temperatures = [                                  # 🧪 Preview data · temperatures · 3
    {"city": "Seoul", "degrees": 21},
    {"city": "Busan", "degrees": 24},
    {"city": "Incheon", "degrees": 22},
]

The parser understands the literal syntax of the supported languages — JavaScript/TypeScript objects and arrays, C# new List<T> { new T { … } } and new Dictionary<K,V> { ["k"] = v }, F# record lists and JSON documents. Press Ctrl+Alt+R to re-read the literal after editing it.

🌍 Supported languages

Four languages, two capture strategies: .NET is read only through the bundled helper (one debugger request, whole page in one go), and JavaScript/TypeScript is read from adapter previews, falling back to the universal variables walk when an adapter hides the previews.

✅ = bundled and used automatically

Column kinds (number, string, boolean, date, null, object, …) are inferred per language, so sorting and chart axes behave correctly in all of them.

📊 What you get

🔗 Locals in your filter

The Filter rows with a condition button next to the search collects the condition from per-column rows and keeps it visible as a chip with a clear button. The condition is evaluated locally over the rows that were captured, so applying it costs no debugger request and cannot block the debuggee. Free identifiers that are not columns are resolved in the current frame, just like a query parameter:

x.Day == dayOfMonth        ← dayOfMonth is a local of the stopped statement
x.Price > budget * 1.2     ← budget too

📈 Charts

Nine chart types, Show Chart from the toolbar, Series settings in the corner:

Pick the X axis, a Y series, an optional group column (that is what turns one series into one series per group), a bubble size column, and an aggregation (none, mean, sum, min, max, count, first, last). Every chart can be exported to PNG for sharing without screenshots.

💾 Export

Copy to the clipboard as TSV with Exploring Collections: Copy Rows.

Exports contain exactly the rows you see — filters, search and sorting applied — and the extension tells you when a collection was truncated so a partial export is never silent.

🧰 Native helpers (bundled per language)

The bundled helpers are what make .NET ADO.NET collections and rich typed data work. They live in helpers/ — see helpers/README.md for the full contract.

Every helper speaks the same tiny envelope, so the extension needs one parser per language, not one per type:

{ "__ec": 1, "kind": "sequence", "total": 14, "items": [ { "City": "Seoul" } ] }

kind is sequence, mapping (items are [key, value] pairs) or record (a single object). Limits, cycle detection and depth are handled inside the helper, so a cyclic graph yields a readable row rather than a hung debuggee. The helper writes a page to a temporary file that the extension reads and deletes, because a value returned from a method call is truncated by the adapter at about 1,000 characters. .NET collections therefore have one path: when the helper cannot be loaded or cannot write its file, the capture fails with an explanatory message instead of slowly walking thousands of variables. JavaScript/TypeScript never needs the helper and keeps the variables walk as its fallback.

⚙️ Settings

⌨️ Commands

🌐 Localization

English is the primary language; Russian ships as the secondary one — for both the manifest (package.nls.json / package.nls.ru.json) and runtime strings (l10n/bundle.l10n.json / l10n/bundle.l10n.ru.json, 138 strings).

npm run l10n          # regenerate l10n/bundle.l10n.json + report missing translations
npm run l10n -- --check   # fail when a translated string is missing (CI)

To add a language: copy l10n/bundle.l10n.ru.json to l10n/bundle.l10n.<tag>.json, translate, add package.nls.<tag>.json, then run npm run l10n -- --check.

🏗️ How it works

      capture request
            │
            ▼
  ┌───────────────────────┐
  │ 1. fast path          │   C#/F#: helper file (1 request, required)
  │                       │   JS/TS: adapter previews (1–2 requests)
  │ 2. variables walk     │   JS/TS fallback when previews are hidden
  └───────────────────────┘
            │
            ▼  language providers (syntax, column kinds)
  ┌───────────────────────┐
  │ snapshot + rows model │   immutable, serializable, exportable
  └───────────────────────┘
            │
            ▼  strict CSP webview (no framework, no runtime dependencies)
  grid · column filters · filter builder · 9 charts · value pane · export

src/            extension host: providers, DAP client, filters, exports, commands
webview/        the UI (vanilla TypeScript, self contained SVG charts)
helpers/        per language helper libraries with their own test suites
test/           unit + integration tests (node:test over the bundled output)
resources/      icon and activity bar artwork
docs/           README screenshots (they ship with the VSIX so the Marketplace can show them)
scripts/        icon generation, l10n generation, helper test runner

Deliberate engineering choices: no runtime dependencies (own ZIP + XLSX writer, own SVG charts, own expression parser), strict CSP in the webview, immutable snapshots so a capture can be re-rendered after the session is gone, and an AST based filter so a condition is never rewritten by string surgery.

🛠️ Build from source

npm install
npm run build            # dist/extension.js + dist/webview.js
npm run check            # TypeScript 7 type check
npm test                 # unit tests + the .NET helper suite
npm run test:helpers     # helper suites only (skips toolchains you don't have)
npm run test:integration # drives the extension inside a real VS Code window
npm run preview          # renders the viewer into media/screenshot-*.png
npm run package          # produce exploring-collections-1.0.0.vsix

Helper build steps: npm run package packs the .NET helper assembly (helpers/dotnet/dist/ExploringCollections.Helper.dll — one dll for both C# and F#) into the VSIX. That assembly is tracked in git, so a fresh clone can be packaged as is; rebuild it with npm run build:helper:dotnet after any change under helpers/dotnet/. The JavaScript/TypeScript serializer is injected by the extension and needs no build step. npm run test:helpers runs the .NET helper suite, skipping the run when the toolchain is missing; the build and test commands are in helpers/README.md.

npm run test:integration launches the installed Visual Studio Code with a throwaway profile, starts a real Node debug session on a sample program and checks the CodeLens, the hover link, the capture pipeline and the panel — including screenshots of the DOM through the headless preview renderer (npm run preview).

Requires Node.js 20+ (developed against Node 26), TypeScript 7 and, for the .NET helper suite, a .NET SDK.

📄 License

MIT — full text in LICENSE. © 2026 Dmitry Sorokin (dimanrus).