How to extract package.json files from a sourcemap

Background

A `package.json` inside a sourcemap is a peculiar artifact. It's the literal manifest of the bundled version of a library — the same file you'd find in `node_modules/<pkg>/package.json` on the author's machine at build time. For popular packages (React, Vue, Next.js, lodash, the Radix primitives, Tailwind) it includes the `name`, `version`, `main`, `module`, `exports`, `dependencies`, `devDependencies`, `peerDependencies`, `engines`, `sideEffects`, `repository` and (on packages that ship them) `keywords` and `funding` fields. That's more information than you could reasonably extract any other way from a deployed bundle.

Extracting them is mechanical: iterate `sources[]`, filter entries whose path ends in `package.json`, find the matching index, JSON.parse the matching `sourcesContent[]`, push the result into an aggregation. The whole pipeline is 15-20 lines of Node.js or a single `jq` invocation. Doing the same thing across every bundle on a page (a typical Next.js app loads 5-30 chunks each with its own map) requires fanning the extraction out and deduping by `<name>@<version>` at the end. Sourcemap Explorer parallelises this in an offscreen worker pool and serves you the result in the popup, but the underlying primitive is dead simple and writing your own version takes an afternoon if you ever need to integrate it into a custom audit pipeline.

The data is genuinely lockfile-grade. Compare a published npm-registry manifest for `react@18.2.0` with the `package.json` you extract from a sourcemap of a site running React 18.2.0 and the two should match byte for byte (modulo deliberate trimming by the publisher). That equivalence is what makes the extraction so useful for downstream work — security scanning, CVE matching, compatibility-matrix generation, dependency-tree reconstruction — because the inputs are the canonical published manifests for the exact versions the site bundled.

Why this matters

`package.json` files tell you not just what version of a library is running, but what it expects of its environment (`engines`), what it depends on (`dependencies`, `peerDependencies`), what shape it exposes (`exports`, `main`, `module`), and often what the author of the site explicitly chose (`sideEffects`, `bin`, `funding`). Aggregating them across a site's sourcemaps gives you a lockfile-quality view of the bundled ecosystem — the same kind of dataset you would assemble by hand from a project's `pnpm-lock.yaml` or `yarn.lock`, except derived from a deployed bundle rather than from source-control access.

For security work the dataset is directly actionable: feed each `name@version` pair into the GitHub Advisory Database, the Snyk Vulnerability DB, or the OSS Index and you get a per-site CVE exposure report in seconds. For compatibility work the `peerDependencies` and `engines` fields tell you which React, Node or browser versions the site needs to keep around. For audit work the `dependencies` graph tells you the second-degree imports — what `react-hot-toast` brings in, what Sentry's browser SDK pulls into the bundle — without having to run a fresh install yourself.

For competitive and partnership work the published manifests reveal a lot of small choices that summary detectors miss. The `repository.url` field tells you who maintains a package; the `funding` field tells you which projects the site implicitly supports; the `keywords` field tells you how the package author categorises themselves; the `exports` map tells you which API surface the bundler targeted. Aggregated across an entire site, those small signals add up to a richer picture than the categorical 'they use React' answer that any other technique can reach.

For education the dataset is unmatched. If you are learning how a real production application is composed, having the bundled manifests of every dependency in front of you, version-aligned and byte-identical to what the developer shipped, is a kind of access that did not exist before sourcemap-aware tooling. You can read the manifests, follow the `dependencies` chain, see how a modern app is layered, and learn the architectural conventions a thousand teams have settled on.

Prerequisites

• Node.js 18+ for the JavaScript path, or `jq` for the shell-script path. Either one is fine; pick the one your tooling already uses.
• A sourcemap file — either downloaded with the [download-sourcemaps-from-a-website](/how-to/download-sourcemaps-from-a-website) workflow or pulled directly with `curl` from the URL referenced by the `SourceMap` header.
• Optional: Sourcemap Explorer installed, which runs the extraction across every bundle on the page automatically and surfaces the result in the popup's Stack tab.
• Optional: a CVE database or vulnerability scanner (`npm audit`, `osv-scanner`, Snyk CLI) for the next-step security work that the extracted dataset enables.

Step-by-step

1. 1

   Load the sourcemap

   Read the `.map` file as a string and `JSON.parse` it. The result has at minimum a `version` field (always 3 for modern maps), a `sources` array (paths the bundler consumed), a `sourcesContent` array (the literal content of each source, in the same order as `sources`), and a `mappings` field (encoded position information, irrelevant for this workflow). Some maps also have `names`, `file`, `sourceRoot` and other fields. You only need `sources` and `sourcesContent` for `package.json` extraction.

   import fs from 'node:fs';
   const map = JSON.parse(fs.readFileSync('bundle.js.map', 'utf8'));
   console.log('sources:', map.sources.length, 'sourcesContent:', map.sourcesContent?.length ?? 0);

2. 2

   Filter paths ending in package.json

   Loop `map.sources`, keep entries whose path ends in `/package.json` (or starts with `package.json` if the bundler used relative paths from the project root). Remember the index `i` — you'll need it to look up the matching `sourcesContent[i]` in the next step. Be careful with scoped packages: `node_modules/@radix-ui/react-dialog/package.json` is a perfectly valid scoped path and your regex needs to match it.

   const pkgIndices = [];
   for (let i = 0; i < map.sources.length; i++) {
     const src = map.sources[i];
     if (/(^|\/)package\.json$/.test(src)) pkgIndices.push(i);
   }
   console.log('package.json sources:', pkgIndices.length);

3. 3

   Parse the matching sourcesContent

   For each kept index, `const pkg = JSON.parse(map.sourcesContent[i])`. Pull `pkg.name`, `pkg.version`, and whatever else you care about — `dependencies`, `peerDependencies`, `engines`, `sideEffects`, `repository`, `funding`. Wrap the parse in a try/catch in case some entries are stripped or malformed (rare but possible).

   const packages = [];
   for (const i of pkgIndices) {
     try {
       const pkg = JSON.parse(map.sourcesContent[i]);
       packages.push({
         name: pkg.name,
         version: pkg.version,
         deps: Object.keys(pkg.dependencies ?? {}).length,
         sourcePath: map.sources[i],
       });
     } catch (err) {
       console.warn('skipped', map.sources[i], err.message);
     }
   }

4. 4

   Build a name → version map

   Aggregate across bundles. If two `package.json`s share a name with different versions (common when pnpm/yarn dedupe differs across chunks, or when a monorepo accidentally hoisted two Reacts), keep both — they're both real and the duplication is itself worth flagging. The simplest aggregation is `Map<name, Set<version>>`; print and sort by name at the end.

   const inventory = new Map();
   for (const p of packages) {
     if (!inventory.has(p.name)) inventory.set(p.name, new Set());
     inventory.get(p.name).add(p.version);
   }
   for (const [name, versions] of [...inventory].sort()) {
     console.log(`${name}: ${[...versions].join(', ')}`);
   }

5. 5

   Aggregate across all chunks

   A single page typically loads 5-30 chunks, each with its own map. The full library inventory is the union of all the `package.json` extractions. Walk every map URL listed in [download-sourcemaps-from-a-website](/how-to/download-sourcemaps-from-a-website), run the extractor, and merge into a single `Map<name, Set<version>>`. The result is the page-level lockfile-shape inventory.

6. 6

   Feed the inventory into vulnerability scanning

   Convert the inventory into a synthetic `package.json` (or any format your scanner consumes) and run `npm audit --json`, `osv-scanner --lockfile`, or your scanner of choice. The CVE matches you get back are the per-site security exposure derived purely from the deployed bundle. This is one of the highest-leverage uses of sourcemap-extracted manifests and impossible without the extraction step.

   Tip: `osv-scanner` and the GitHub Advisory database use the same OSV format and are easy to integrate into a script. The whole pipeline — sourcemap → manifests → CVEs — runs in a few seconds for a typical site and produces an actionable security audit at the end.

7. 7

   Use Sourcemap Explorer for the day-to-day case

   The extension does this step automatically on every bundle it finds, surfaces the resulting versions alongside the library entry on the Stack tab, and lets you click into any entry to see the originating `package.json`. For bulk / offline / scripted analysis, the Node.js script above is what you want; for everyday in-browser use, the extension is faster and lower-friction.

Real-world example

Alternative methods

Troubleshooting

Caveats

What to do next

`package.json` data pairs naturally with the [reconstruct-source-code-from-a-sourcemap](/how-to/reconstruct-source-code-from-a-sourcemap) guide — combined, you get a full browsable project tree with a lockfile-shape manifest of its bundled dependencies. For per-version scanning across a single site without writing a script, [find-the-exact-version-of-an-npm-package-on-a-site](/how-to/find-the-exact-version-of-an-npm-package-on-a-site) is the lighter-weight workflow. For the broader 'what is in the bundle' question, [see-every-javascript-library-a-site-uses](/how-to/see-every-javascript-library-a-site-uses) is the natural next step. For security workflows the extracted dataset feeds directly into vulnerability scanning — `osv-scanner --lockfile <synthetic-package.json>` is the simplest pipeline; `npm audit` consumed via a synthetic `package-lock.json` is another option; commercial scanners (Snyk, GitHub Advanced Security, Sonatype) all consume similar inputs. For competitive analysis the dataset feeds into stack-comparison work; the [Wappalyzer alternatives](/alternatives/wappalyzer) page contrasts what fingerprint-based detectors miss against what sourcemap-derived inventory captures, and the [Next.js detection page](/detect/nextjs) shows how the version-level reading folds back into framework-aware analysis.

FAQ

Related