globalThis.ts

Code Explorer analyzes TypeScript code in the browser. It parses types, call graphs, and module structures using the full TypeScript compiler, loaded via CDN <script> tag. 493 lines of analysis logic. Zero tests.

The obvious concern: how do you test code that depends on a browser global loaded from a CDN? The TypeScript compiler lands on window.ts at runtime. Node.js has no CDN, no <script> tags.

Three lines

The TypeScript compiler is also an npm package. Vitest has setup files. The entire bridge:

That's the entire test-setup.ts. Point Vitest at it in vitest.config.ts and every test gets the full compiler. Same API surface, same behavior, no mocks.

The bug

33 tests. 14 for type analysis, 10 for call graphs, 9 for module imports. They all passed on the first run except one. The module graph test for resolving import { create } from "./lib" to lib/index.ts returned no edge.

Root cause: resolveImport built the resolved path by splitting the importer's directory, walking the relative segments, then joining. When the importer was at the root (e.g. main.ts), the directory was ".". After joining: ./lib/index.ts. But the known paths set contained lib/index.ts. No match.

One line. Would have caused silent failures in any project with root-level files importing from subdirectories. The kind of bug you don't notice until someone pastes real code and wonders why the module graph is missing edges.

The pattern

If your browser code reads from a global (window.X, globalThis.X), you probably have a matching npm package. A three-line setup file makes the entire test suite work without jsdom, without browser launchers, without mocks. The API is the same either way.