globals

globals is a small, dependency-free npm package that ships one thing: a JSON map of global identifiers for dozens of JavaScript environments — browsers, Node.js, Deno, Bun, web workers, service workers, and test frameworks like Jest and Vitest. Each environment key maps to an object of global names, where the value indicates whether static-analysis tools should treat that global as writable (true) or read-only (false).

The package is best known as the data source behind ESLint’s built-in environment configs (for ESLint 8 and earlier), letting linters know that window or process are legitimate globals rather than undefined variables. Its accuracy comes from an automated pipeline: rather than hand-maintaining lists from documentation, scripts/update.mjs and a monthly scheduled GitHub Action actually launch real browsers via Puppeteer and real Deno/Bun runtimes to enumerate live globals, then regenerate globals.json and its accompanying TypeScript types from that ground truth.

What You Get

• A globals.json data file covering 50+ environments, from browser and node to specific ECMAScript editions, test frameworks, and worker types
• Read-only vs. writable flags on every global, so tools can distinguish overridable identifiers (like event in some browser contexts) from strictly read-only ones
• Separate nodeBuiltin and node environments, letting consumers detect accidental CommonJS-only references in ESM code
• Generated TypeScript type definitions (index.d.ts) verified with tsd, giving typed, autocompletable access to every environment object
• A reproducible update pipeline (scripts/update.mjs) that regenerates the data by querying real browser, Deno, and Bun runtimes rather than transcribing documentation by hand

Common Use Cases

• Populating a linter’s or custom static-analysis tool’s list of predefined globals for a given runtime
• Detecting undeclared-variable false positives in codebases that mix multiple JavaScript environments
• Auditing whether code relies on CommonJS-only globals (require, module) inside a project meant to run as pure ESM
• Feeding bundler or transform tooling a canonical list of identifiers that should not be treated as free variables to resolve or polyfill

Under The Hood

Architecture The package cleanly separates build-time data generation from runtime consumption. Sixty-odd source modules under data/ (browser.mjs, node.mjs, jest.mjs, es2015.mjs through es2024.mjs, and more) each describe one environment’s globals; scripts/generate-data.mjs reads every file in data/, assembles them into a single globals.json, and scripts/generate-types.mjs derives index.d.ts from that same aggregate. The published package itself is deliberately minimal — index.js is a one-line re-export of the JSON file — so the real architectural surface lives in the scripts and data directories that produce it, and changing the shape of a per-environment entry means updating both the data-generation and type-generation scripts in lockstep, plus every downstream linter config that dereferences a specific environment key.

Tech Stack Everything runs on plain Node.js ESM scripts with zero runtime dependencies for the published package; devDependencies carry the real machinery — Puppeteer to launch actual browsers and scrape live window globals, nano-spawn to shell out to Deno and Bun for their builtin globals, Cheerio for parsing reference HTML, ava for tests, xo (ESLint-based) for linting, tsd with type-fest for type testing, and npm-run-all2 to sequence the build:data and build:types steps. The deployment target is simply the npm registry, publishing index.js, index.d.ts, and globals.json as static files.

Code Quality Testing goes beyond static assertions: test.mjs (run via ava) launches real browser, Deno, Bun, Jest, and Vitest environments and diffs the package’s data against what those runtimes actually expose, catching drift that a hand-maintained list would miss. Type correctness is checked with tsd against index.test-d.ts. CI (main.yml) runs the full test suite across Node 18 and 20 on every push and PR, and a separate scheduled update.yml workflow does a dry-run of the update script monthly across Ubuntu, macOS, and Windows to catch platform-specific drift before it reaches a release. Linting is enforced via xo, which is itself an ESLint config, giving the project a dogfooding relationship with the exact static-analysis ecosystem it serves.

What Makes It Unique Most lists of environment globals are hand-transcribed from documentation and go stale as runtimes evolve. This package’s distinguishing choice is verification by execution: its update pipeline doesn’t trust written docs, it spins up the actual browser/Deno/Bun/test-framework environments and reads their real global scope, then regenerates the data from that ground truth on a recurring schedule. That turns a seemingly static reference file into a continuously self-correcting one.