sonner

About

An opinionated toast component for React.

What detecting sonner tells you about a site

sonner is Emil Kowalski's opinionated toast component, and it has become the default notification layer of the shadcn/ui generation, so finding it is a near-certain marker of a modern, design-conscious React stack that values motion and polish. Its presence suggests the team copied components into their own tree rather than installing a monolithic UI library, and that they care about the small interaction details (stacking, swipe-to-dismiss, promise states). It reads as a recent build with current taste, frequently in a Next.js App Router project.

Why the exact sonner version matters

sonner moved quickly through its early versions, refining the API for promise toasts, positioning and the rich-content variants, so a given version pins which of those capabilities and prop names were available. Newer releases tightened theming and accessibility; an older pin usually correlates with an earlier shadcn snapshot frozen in the project.

sonner in a real-world stack

When you find sonner in a bundle, it rarely travels alone. shadcn/ui, Radix primitives, Tailwind CSS and Next.js.

Quick facts

Common pairings

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

How Sourcemap Explorer detects sonner

sonner ships as v2.0.7, published 2025-08-02 and carries 0 direct dependencies, 2 peer dependencies (react, react-dom), 64 versions on the registry. Those exact numbers are the footprint Sourcemap Explorer matches when sonner rides inside a deployed bundle — here is how the detection works.

We catch sonner from two complementary signals: bundled source paths and the embedded package.json. Modern bundlers (webpack, Vite, esbuild, Rollup, Turbopack) preserve the original node_modules/sonner/ 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 `sonner` 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/sonner/` — every match confirms the package is bundled. The matching `sourcesContent[i]` for `node_modules/sonner/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/sonner/package.json")) | $m.sourcesContent[.key] | fromjson | .version' bundle.js.map`. Sourcemap Explorer automates the same query in the popup.

Major releases of sonner

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

Recent versions

sonner README

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

npm install sonner

import { Toaster, toast } from 'sonner';

// ...

function App() {
  return (
    <div>
      <Toaster />
      <button onClick={() => toast('My first toast')}>Give me a toast</button>
    </div>
  );
}

FAQ

Keep reading on Sourcemap Explorer