How to see every JavaScript library a website uses
Wappalyzer, BuiltWith and WhatRuns will identify the big frameworks: React, Vue, lodash, jQuery. They'll miss every internal utility and every niche npm package. The complete list only exists inside the sourcemap.
Background
A typical modern React application bundles 80-200 npm packages. The detector-visible subset — the ones with explicit fingerprint rules — is usually the 15-30 most popular. That leaves 50-170+ packages per site invisible to categorical detectors. Some of them are transitive (a utility your framework depends on), some are deliberate choices (a form library, a date picker, an analytics SDK), some are niche and make the site interesting (an animation library no one else uses, a specific charting package, a proprietary npm package). Reading the sourcemap gives you the full set, because every bundled package leaves `node_modules/<pkg>/` paths in the `sources[]` array. Collapsing those to unique package names is straightforward; extracting versions from embedded `package.json` files is one JSON.parse away.
Why this matters
The 'invisible libraries' layer is often where the interesting stack decisions live. The framework and popular libraries are plausibly just defaults; the specific form library, the specific animation package, the specific date-handling choice reveals taste and architecture. For hiring research, for competitive analysis, for security auditing, for learning — the full library list is much more informative than the top-line categorical answer.
Prerequisites
- Sourcemaps available on the target site.
- Chrome DevTools or Sourcemap Explorer.
Step-by-step
- 1
Find a sourcemap
DevTools → Network → JS filter → check response headers for `SourceMap` / `X-SourceMap`, or look for the `//# sourceMappingURL=` comment at the bottom of a bundle.
- 2
List node_modules paths
Download the map, parse JSON, filter `sources[]` for anything matching `node_modules/<pkg>/`. Collapse to unique package names (handle `@scope/name` correctly — the scope plus the first subfolder). That's your package list.
jq -r '.sources[] | capture("node_modules/(?<p>(@[^/]+/)?[^/]+)") | .p' bundle.js.map | sort -u - 3
Extract versions where possible
For each unique package, check if `node_modules/<pkg>/package.json` is in `sources[]`. If yes, the matching `sourcesContent[]` entry has the exact version.
- 4
Let Sourcemap Explorer do all of it
The extension's Stack tab runs this across every bundle on the page, deduplicates packages across chunks, extracts versions from every embedded `package.json`, and reports both known libraries (matched to fingerprint rules) and ad-hoc packages (validated against the npm registry before showing).
Real-world example
Alternative methods
Bundle analysis tools
`source-map-explorer` or `webpack-bundle-analyzer` can tell you package composition of a specific bundle. Useful when you have the `.map` on disk; slower than the extension for casual use.
Statistical inference
For sites without sourcemaps, you're guessing — and usually only catching the top-N libraries with runtime signatures. No complete list is possible without the map.
Troubleshooting
`sources[]` has hundreds of entries that all look like the same package.
Monorepo workspace — one package's source is split across many sub-paths. Collapse by the package-name prefix, not the full path.
A package appears but has no version.
`package.json` wasn't included in the map. The package is still confirmed-present; just no version available from the sourcemap layer.
Caveats
What to do next
With the full library list, common follow-ups are exact-version extraction per library (the 'find exact npm versions' guide) and tree reconstruction for reading the author's code (the 'reconstruct source' guide).
FAQ
How is this different from reading the DOM?
The DOM shows libraries that register themselves as globals. Sourcemaps show libraries that were bundled. Most modern apps bundle hundreds more than they register — you only see the full picture via sourcemaps.
Can I get this list without the sourcemap?
Not completely. You can catch the top ~30 via runtime signatures, but the long tail of internal utilities and niche libraries is invisible without the map.
Does Sourcemap Explorer show transitive dependencies?
By default the Stack tab emphasizes top-level meaningful packages; transitive-only packages (like `goober` bundled by `react-hot-toast`) are filtered out via a curated skip list. The raw sourcemap package scan is available for deeper analysis.
Related
Skip the manual steps.
Sourcemap Explorer automates every workflow in this guide — free, local, no sign-up.