How to find the exact version of an npm package used by a site
Most technology detectors use regex against URLs and headers, which rarely surfaces more than a major version. The only way to get the exact semver is to read the package's own `package.json`, which shows up inside the site's sourcemap whenever webpack includes `node_modules/<pkg>/package.json` as a source.
Background
Every real-world bundler — webpack, esbuild, Rollup, Vite, SWC, Turbopack — resolves your `import 'react'` statements against `node_modules/react/` on disk. When the bundler emits a sourcemap, each source file it used gets a `sources[]` entry with its original path. And crucially, `node_modules/<pkg>/package.json` is often included as one of those source files — either because the bundler's module resolver touched it directly or because a plugin decided it was useful. When it's included, the matching `sourcesContent[]` entry is the literal contents of that `package.json`, including the `name` and `version` fields. That means the exact semver of every bundled library is sitting inside the sourcemap, text-searchable, if you know to look for it. The extraction is mechanical — no regex guessing, no version inference. Just JSON.parse.
Why this matters
Version precision matters for security research ('is this site running a CVE-vulnerable React-DOM 18.0.0?'), for compatibility research ('does this Stripe integration use Elements v5 or v6?'), for competitive analysis ('they're still on Next.js 12 — they haven't migrated to App Router'), and for authoritative technographic data. A major-version-only detector gives you a ballpark; a package.json-derived version gives you the ground truth.
Prerequisites
- Target site that exposes sourcemaps.
- Chrome DevTools or curl for direct fetches.
- A JSON parser — either `jq` or your favorite language's stdlib.
Step-by-step
- 1
Confirm the site exposes sourcemaps
Open DevTools → Network → look at any non-vendor script request and check the response headers for `SourceMap` or `X-SourceMap`. If it's there, you're in luck. If not, try the last 4 KB of the file for a `//# sourceMappingURL=` comment.
- 2
Download and parse the map
Fetch the `.map` URL. Inside, look for any entry in `sources[]` matching `node_modules/<pkg>/package.json` or `./node_modules/<pkg>/package.json`. The matching entry in `sourcesContent[]` (same index) is that package's literal `package.json` with `name`, `version`, and dependencies.
jq -r '.sources | to_entries[] | select(.value | test("node_modules/[^/]+/package.json$")) | "\(.key) \(.value)"' bundle.js.map - 3
Cross-reference with node_modules paths
Even without `package.json` as a source, `node_modules/<pkg>/<file>` paths in `sources[]` confirm the package is bundled. The version may not be extractable from paths alone, but you can deduce it from distinctive file names or API surface.
- 4
Use Sourcemap Explorer
The extension automates all of the above across every bundle on the page, extracts versions from every embedded `package.json`, and reports them on the Stack tab. It's the only way to scale this lookup to an entire site without writing custom code. Versions from sourcemap `package.json` are marked as authoritative; versions inferred from URLs are marked as inferred.
Real-world example
Troubleshooting
`node_modules/react/package.json` shows up but version is empty.
The bundler stripped the `version` field as an optimization. Very rare but possible. Check other `package.json` files in the same sourcemap — they'll usually have versions.
I see the same package version listed twice.
Monorepo package hoisting can cause the same library to be bundled twice from two locations. Both are real; the UI deduplicates to the semver-max.
Caveats
What to do next
With exact versions in hand, the typical follow-up is either security research (checking those versions against CVE databases) or architecture research (correlating library choices across frameworks). The 'see every JavaScript library' guide expands from 'find one version' to 'list everything bundled'.
FAQ
Why aren't most detectors doing this already?
Because they don't parse sourcemaps. They run on HTML/headers/DOM only. Adding sourcemap parsing is non-trivial — you need to fetch the `.map`, JSON-parse it (often tens of MB), and walk `sources[]` for every package. Sourcemap Explorer was designed specifically to do that.
Can I do this in DevTools alone?
Yes, manually per map. Download the `.map`, open it in a JSON viewer, search for `package.json`. Tedious across 10-20 bundles per site; the extension automates it.
What about CSS-only packages?
`node_modules/tailwindcss/package.json` shows up in the CSS sourcemap. Same extraction method. The extension reads both JS and CSS maps.
Related
Skip the manual steps.
Sourcemap Explorer automates every workflow in this guide — free, local, no sign-up.