bugsnag-js is the notifier half of a commercial error monitoring service

A client library, not an error tracker

The first thing to understand about bugsnag-js is that it is the notifier, not the product. The repository is described as a monorepo containing the universal error reporting client @bugsnag/js and the React Native client @bugsnag/react-native, along with the core Bugsnag libraries for reporting errors, plugins for supporting various frameworks, and plugins for internal functionality.

What the client does is detect errors and report them. The README states the scope as automatically detecting JavaScript errors in the browser, Node.js and React Native, with plugins for React, Vue, Angular, Express, Restify and Koa, and the outcome as cross-platform error detection for handled and unhandled errors with real-time error alerts and detailed diagnostic reports.

The alerts and the dashboard live in the Bugsnag service, not here. The licence on the client code is MIT, and the getting-started flow makes the dependency on the service explicit in its first step: create a Bugsnag account, complete the integration guide, report handled exceptions with Bugsnag.notify(), then customise the integration using the configuration options.

That split is what makes the packages easy to evaluate and easy to misjudge. The open source part is genuinely useful on its own, as a well-tested way of capturing error events with consistent metadata. But an adopter who wants their own error store is looking at the wrong repository.

One monorepo, many notifier entry points

The package list shows how the monorepo is organised, and it is worth reading as a map of the supported surfaces. The core reporting library is @bugsnag/core. On top of it sit @bugsnag/js as the universal client, which covers the browser and Node.js cases, and @bugsnag/react-native as the mobile client. There is @bugsnag/electron for the desktop case.

The framework plugins are separate packages rather than switches inside one. On the browser side those are @bugsnag/plugin-vue, @bugsnag/plugin-react and @bugsnag/plugin-angular. On the server side they are @bugsnag/plugin-koa, @bugsnag/plugin-express and @bugsnag/plugin-restify. The README also names an internal plugin, @bugsnag/plugin-simple-throttle, which gives a hint at one of the problems a reporting client has to solve: an application in a loop can otherwise flood the endpoint with the same error.

The reason for separate packages is mostly payload size and platform fit. A React plugin that understands component boundaries has no business in a Node.js Express service, and a client that ships React Native native modules has no business in a browser bundle. The cost of that design is that the versions of the core library and of each plugin have to move together, which is a real operational consideration when a release lands.

The monorepo is managed with Lerna, and the top-level entries show the supporting machinery: a lerna.json, a jest.config.js and a jest directory, a cucumber.js for the end-to-end scenarios, a dangerfile.js, a babel.config.js, a Gemfile, a docker-compose.yml and a dockerfiles directory, plus a TESTING.md and an UPGRADING.md.

What it takes to build and test the repository

That quick start is short, and it is worth following in order because the build step produces the artefacts the tests need.

git clone [email protected]:bugsnag/bugsnag-js.git --recursive
cd bugsnag-js

npm i
npm run build
npm run test:unit

The clone uses the recursive flag, and the repository has a .gitmodules file, so some dependencies are git submodules that have to be fetched with the initial clone. Then the top-level dependencies are installed, the standalone notifiers and plugins are built, and the unit tests run.

The rest of that quick start shows the granularity available. A single package can be tested by passing a path pattern, and coverage is a flag on the same command:

npm run test:unit -- --testPathPattern="packages/react-native"
npm run test:unit -- --coverage
npm run test:lint
npm run test:types

The last of these runs the TypeScript compatibility tests, which matters for a library that ships type declarations to consumers on several TypeScript versions. The lint script is separate from the type test rather than folded into it, so a contributor runs two checks to know the tree is clean.

The build and test environment is containerised. The docker-compose file at the repository root defines a minimal-packager service built from dockerfiles/Dockerfile.package that mounts the working tree, and a ci service built from dockerfiles/Dockerfile.ci, plus browser and mobile test runner services that publish port ranges 9000 to 9499 for the automation grid. The environment block carries the service credentials, the BrowserStack keys and the Appium and Maze Runner keys that the end-to-end suites need.

The API is notify(), and the options are the real surface

The public entry point is Bugsnag.notify(), used to report handled exceptions, meaning errors your code catches and decides to deal with. Unhandled errors are detected automatically. So the library covers both halves of the problem: the errors a developer swallows with a try and catch, and the ones that escape.

The configuration options page is where the behaviour actually lives, and the README points at it as the fourth step of getting started. This is standard for a notifier: the difference between a useful error report and a useless one is almost always in the metadata, and the metadata is set through options rather than through the call site.

The framework plugins exist to supply that metadata correctly for each framework, which is why a React plugin is more than a wrapper. A React error carries a component stack, and a Vue error carries component and lifecycle information, and an Express or Koa error carries the request context. A generic client cannot infer those, and the plugin is what fills them in.

The internal plugin named in the package list, @bugsnag/plugin-simple-throttle, is the counterweight. Reporting every occurrence of an error in a tight loop is a self-inflicted denial of service on your own endpoint, and a throttle is the usual answer.

One caveat about reading the code: this repository is written in TypeScript and transpiled, and the README describes the build as producing the standalone notifiers and plugins. A team that needs to patch the client itself is patching a transpiled build output in packages, so it helps to know where the TypeScript sources sit before planning any change.

Upstream control, and what that means for a fork

The contributing section is unusually direct and belongs in any evaluation. Most updates to this repository will be made by Bugsnag employees, and the project is unable to accommodate significant external pull requests such as feature additions or any large refactoring, while minor fixes are welcome.

That is a reasonable position for a client library whose behaviour has to match a hosted service, and it is a significant one for anyone who was hoping to use the repository as a base. A large change to the notifier would have to be made as a small patch on top, or not at all.

The same logic explains the release cadence. The recent versions are v9.1.0 on 2026-10-09, v9.0.0 on 2026-09-22 and v8.10.0 on 2026-07-10, so the major line moved from 8 to 9 in September and the default branch is next, which is where the following major version is developed. The presence of an UPGRADING.md file at the top level is the sign that the v9 transition is the kind that requires reading rather than bumping.

For an adopter, the practical rule is that the client, the service and the framework plugins are versioned as a set. Upgrading the core while leaving a plugin behind is the likely source of a broken integration, and the compatibility matrix is not in the README, so it has to be checked on the documentation site or in the packages directory.

MIT for the code, a service for everything else

All packages in the repository are released under the MIT License, with the terms in LICENSE.txt at the root. That covers the code.

It does not cover the service. The notifier's job is to deliver error data to a Bugsnag account, and the useful parts of the product, the dashboard, the alerting and the diagnostics, live on the other side of that account. The MIT licence on the client is what lets you read, modify and redistribute the notifier; it says nothing about what happens to the data once it arrives, and those terms are the ones to read before sending production errors anywhere.

The repository also carries a SECURITY.md, which is where a disclosure policy would live, and an OpenSSF Scorecard badge and a Buildkite build status badge in the header, so the project publishes some of its supply chain posture.

The realistic adoption path is short. Install the notifier for the platform you are on, follow the integration guide, call Bugsnag.notify() where you catch errors you would otherwise swallow, and then read the configuration options carefully. The code is the easy part. The decisions that determine whether the tool is worth it are which events you send, what metadata you attach, and whether the account that receives them is one your organisation is allowed to use.

Editorial conclusion

bugsnag-js suits a team that has already chosen Bugsnag as its error monitoring service and wants the first-party notifier for a browser app, a Node service, an Electron desktop app or a React Native application, rather than a hand-rolled reporting client. It is the wrong tool for a team that wants to keep error data inside its own infrastructure, because the notifiers exist to feed a hosted service, and it is the wrong tool for a repository maintainer hoping to land a large external pull request, since the README says most updates are made by Bugsnag employees and significant external pull requests cannot be accommodated. Before you adopt it, read the configuration options page for the reporting defaults you would otherwise inherit, and check the UPGRADING.md file in the repository, because a v9 line change is a major version and the client version, the service and the framework plugins are upgraded together.

Frequently asked questions

Official sources

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