swr

About

React Hooks library for remote data fetching

What detecting swr tells you about a site

swr reveals a Vercel-flavoured data-fetching strategy — stale-while-revalidate caching with React hooks — chosen for its tiny footprint and tight Next.js integration. Its presence is a strong hint the site is a Next.js app built by a team that preferred SWR's simplicity over the heavier React Query.

Why the exact swr version matters

SWR 2 added mutation and optimistic-update APIs and changed some hook signatures; the exact version tells you which caching and mutation contract the code relies on.

swr in a real-world stack

When you find swr in a bundle, it rarely travels alone. next (the two come from the same ecosystem), and a fetch layer underneath the hook.

Quick facts

Common pairings

Packages this one expects to find in the same project. Each is also a Sourcemap Explorer detection target.

What swr pulls in

swr declares 2 direct dependencies — each one also rides into any bundle that ships swr, so they are detection targets too. Reading them is a quick way to understand the package's real footprint .

How Sourcemap Explorer detects swr

swr ships as v2.5.0, published 2026-08-03 and carries 2 direct dependencies, 1 peer dependency (react), 179 versions on the registry. Those exact numbers are the footprint Sourcemap Explorer matches when swr rides inside a deployed bundle — here is how the detection works.

We catch swr from two complementary signals: bundled source paths and the embedded package.json. Modern bundlers (webpack, Vite, esbuild, Rollup, Turbopack) preserve the original node_modules/swr/ paths inside the JavaScript sourcemap's sources[] array — that's the canonical signal. When the matching package.json is also captured in sourcesContent[], we read the exact version field — patch number included. No regex guessing, no version inference.

1. 1

   Confirm the site exposes sourcemaps

   In DevTools Network, check the response headers of any application script for `SourceMap` or `X-SourceMap`. Failing that, fetch the script's last 4 KB and look for a `//# sourceMappingURL=` comment — that map is where the `swr` paths live.

2. 2

   Find the package in the bundle

   Open DevTools → Network → reload. Click any application script and look at its sourcemap. Inside, search `sources[]` for entries matching `node_modules/swr/` — every match confirms the package is bundled. The matching `sourcesContent[i]` for `node_modules/swr/package.json` gives you the exact installed version.

3. 3

   Read the version directly from package.json

   Run `jq -r '. as $m | $m.sources | to_entries[] | select(.value | endswith("node_modules/swr/package.json")) | $m.sourcesContent[.key] | fromjson | .version' bundle.js.map`. Sourcemap Explorer automates the same query in the popup.

Major releases of swr

When each major version first landed. Major bumps are where breaking changes live, so this timeline is the fastest way to date the swr version a site actually ships against the ecosystem.

Recent versions

swr README

Live mirror of the GitHub README, for reference. Updated whenever the repo's default branch changes.

import useSWR from 'swr'

function Profile() {
  const { data, error, isLoading } = useSWR('/api/user', fetcher)

  if (error) return <div>failed to load</div>
  if (isLoading) return <div>loading...</div>
  return <div>hello {data.name}!</div>
}

FAQ

Keep reading on Sourcemap Explorer