rollbar.js: one error reporting SDK for browser and Node, with replay as a separate bundle

One package, two runtimes, and an exports map that decides which

rollbar.js is the JavaScript SDK for the Rollbar error monitoring platform, and its package manifest is where the design becomes clear. The package is named rollbar, it is an ES module package with type set to module, and its exports map has separate node and browser conditions.

Under the node condition the import entry is src/server/rollbar.js and the require entry is dist/rollbar.cjs. Under the browser condition the import entry is src/browser/rollbar.js and the require entry is dist/rollbar.umd.min.js. The main field points at the CommonJS build, the browser field at the minified UMD build, the module field at the browser source, and the types at a hand written index.d.ts.

So the same import statement gives you a server implementation in Node and a browser implementation in a bundler, with the resolver picking the right one. The two implementations are not interchangeable, though, and the reason is in the source tree: there is a src/server and a src/browser, each with its own core, and the browser side has separate entry points for telemetry and for the globals wrapper.

The extra export paths make the internals reachable for advanced use. There is ./src/browser/core, ./src/telemetry, ./src/browser/telemetry and ./src/browser/wrapGlobals, each with its own types and both a require and a default condition. That is a large surface area for a client SDK, and it exists because people need to embed the pieces in their own wrappers rather than accept the default one.

Session Replay is a separate entry point, not a config flag

The single most useful packaging fact in the README is that Session Replay is not a boolean you flip. Because replay includes additional recording capabilities, it uses a separate and larger bundle, so you import it from a different path:

// Standard bundle (smaller, no replay)
import Rollbar from 'rollbar';

// Session Replay bundle (includes replay capabilities)
import Rollbar from 'rollbar/replay';

The exports map confirms the split. The replay entry has its own types and its own browser condition, with the import entry pointing at src/browser/rollbarReplay.js and the require entry at the minified replay UMD build, and a default of dist/rollbar.replay.umd.min.js.

This is a good design for a client-side SDK, because most applications do not need session recording and a larger bundle is paid for by every visitor on every page load. Choosing the standard bundle if you do not need replay is stated plainly in the README, and the cost of the alternative is a bundle that ships recording code to users who never trigger an error.

What replay does is capture and replay user sessions around errors, so you can see what happened before the failure, and it can also be triggered on custom conditions to capture critical user flows. The examples directory has a dedicated react-replay-webpack4 example and a snippet-with-replay.html file, so the two paths are exercised separately in the sample projects.

The Node quick start is six lines and every option is visible

The Node.js quick start in the README is the whole server setup in one block:

const Rollbar = require('rollbar');

const rollbar = new Rollbar({
  accessToken: 'POST_SERVER_ITEM_ACCESS_TOKEN',
  captureUncaught: true,
  captureUnhandledRejections: true,
  payload: { code_version: '1.0.0' },
});

// log a generic message and send to rollbar
rollbar.log('Hello world!');

Four options carry the weight. accessToken identifies your project, and the placeholder in the example makes the shape obvious: it is a server item access token, meaning it is a post-only token that can report items but cannot read your project.

captureUncaught turns on capture of exceptions that would otherwise terminate the process, and captureUnhandledRejections does the same for promise rejections that nobody awaited. Both default to on in this example, and both are worth setting deliberately rather than by copying, because a service that reports every unhandled rejection will tell you about code you have already decided is acceptable.

payload carries metadata attached to every item, and code_version in the example is the field that ties a report to a deployed revision, which is the field that makes a regression visible after a release. The last line shows the API shape: an instance with a log method that sends a message.

For framework integrations, Express, Koa, Hapi and more, custom error handlers and advanced configuration, the README points at the Node.js server configuration documentation rather than repeating it, and the examples directory holds a node-require example and a node-components example.

Telemetry is the part that makes a browser report actionable

The feature list names five benefits, and the first two are about what reaches Rollbar rather than about counting errors.

The first is cross platform support. The SDK covers server-side and client-side JavaScript, and the README calls out React, Angular, Express, Next.js and more. The examples directory backs that up with directories for angular, next, next-typescript, react-16, react-19-js-components, react-19-ts-components and react-19-typescript, plus browserify and requirejs setups and two browser extension examples.

The second is telemetry, described as a timeline of breadcrumbs events that help developers understand and fix problems in client-side JavaScript. Breadcrumbs are the sequence of things the user did before the error, and they are usually the difference between an error report you can act on and one that only tells you a line number.

The third feature is automatic error grouping: Rollbar aggregates Occurrences caused by the same error into Items that represent application issues. The capitalisation is deliberate, Occurrences and Items are two different entities in the data model, and grouping is what keeps a storm of identical failures from burying the one new problem.

The last two are platform features rather than SDK features. Advanced search filters items by many different properties, and customizable notifications reach the team through several messaging and incident management tools with real-time alerts. The SDK is the pipe; grouping, search and alerting happen on the other end.

Installation is a package manager line, and the browser has its own route

Installation with npm is one command:

npm install --save rollbar

and with yarn it is:

yarn add rollbar

For a CDN or script tag installation, the README points to the Quick Start section for the browser, and the examples directory contains script.html, include_custom_object.html and itemsPerMinute.html, which is where the plain script tag path is demonstrated.

The browser quick start itself is documentation rather than code in the README. It refers to a recommended snippet-based installation with automatic error capture and telemetry, and sends you to the Browser JS quick start documentation. The snippet files in the examples directory, snippet.html and snippet-with-replay.html, are the two variants of that approach, one plain and one with replay.

The quick start also assumes you have an account. The first instruction is to sign up for a Rollbar account if you have not already, and the documentation site is at docs.rollbar.com/docs/javascript, with the browser and Node quick starts on separate pages under the same documentation set. The README is deliberately a map to that documentation rather than a replacement for it, which is the right division of labour for an SDK with this many framework integrations.

A 4.x SDK that is still moving

The release history shows a project in active development on a new major line. v4.1.0 was tagged on 2026-10-18, v4.0.0 on 2026-10-06, and v3.1.0 back in March 2026. The last push was the same day as the 4.1.0 release, and the repository is not archived.

The jump from 3.x to 4.0.0 within the package's own release history is worth noting because a major version bump in an SDK usually means a change in the module shape, and here the manifest is type module with an exports map and a separate server and browser implementation. If you are upgrading from a 3.x install, the import path and the bundler behaviour are the things to check rather than just the option names.

The repository is a full project rather than a single file. There is src/ and dist/, a replay/ directory, a test/ directory, a docs/ folder, scripts/, examples/, a Makefile with separate build, test, test-browser, test-server and test-ci targets, a webpack config, a Babel config, a web-test-runner config, both a prettier config and an eslint config, and TypeScript configuration in two files, one of which is for the tests.

The licence is MIT, and the package is published to npm as rollbar. The security policy, the contributing guide and an AGENTS.md are all in the repository root, alongside a CLAUDE.md and a cursor directory. Support goes to [email protected], and bug reports are filed as GitHub issues.

One thing to keep in mind when weighing this SDK: it reports to a hosted platform, so what you send leaves your infrastructure and the details of your application end up under someone else's retention policy. That is a normal trade for a commercial error tracker, and it is a decision to make deliberately rather than by default.

Editorial conclusion

Adopt rollbar.js if you already use Rollbar or want a single error reporting SDK that covers both your browser bundle and your Node service, and you are prepared to send application data to a third party. Do not adopt it as a self-hosted logging library, because the SDK reports to the Rollbar platform rather than to a destination you control. Before you ship it, decide which entry point you import, since rollbar gives you the smaller bundle and rollbar/replay gives you Session Replay at the cost of size, and set captureUncaught and captureUnhandledRejections deliberately rather than by copying the example.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. rollbar/rollbar.js on GitHub