Universal JavaScript library for integrating apps with the ⚡ Honeybadger Error Notifier.
For comprehensive documentation and support, check out our documentation site.
This project is isomorphic, meaning it's a single library which contains both browser and server builds. It's written in TypeScript, and transpiled and bundled with Rollup. Our Rollup config generates three main files:
- The server build, which transpiles
src/server.ts
and its dependencies intodist/server/honeybadger.js
. - The browser build, which transpiles
src/browser.ts
and its dependencies intodist/browser/honeybadger.js
. - The minified browser build, which transpiles
src/browser.ts
and its dependencies intodist/browser/honeybadger.min.js
(+ source maps).
In addition, the TypeScript type declaration for each build is generated into its types/
directory (ie dist/browser/types/browser.d.ts
and dist/server/types/server.d.ts
).
However, since the package is isomorphic, TypeScript users will likely be writing import Honeybadger from '@honeybadger-io/js'
or import Honeybadger = require('@honeybadger-io/js')
in their IDE. Our package.json
has main
and browser
fields that determine which build they get, but there can only be a single type declaration file. So we use an extra file in the project root, honeybadger.d.ts
, that combines the types from both builds.
- To run unit tests for both browser and server builds:
npm test
. Or separately:npm run test:browser
,npm run test:server
. - To run integration tests across all supported platforms, see End-to-end tests with Playwright and Browserstack.
- To test the TypeScript type definitions:
npm run tsd
.
We use Playwright to run integration tests in a real browser.
The config file is at test/e2e/playwright.config.ts
.
To run these tests locally, you'll need to install the browsers you want to test with.
Open test/e2e/browsers.ts
and enable the browsers you want to test with.
Then, run npx playwright install --with-deps
to install the browsers.
Lastly, run npm run test:integration
.
Additionally, if you want to run the tests on Browserstack:
- enable Browserstack browsers in
browsers.ts
, - set up a BrowserStack account and
- use
BROWSERSTACK_USERNAME=your_username BROWSERSTACK_ACCESS_KEY=your-access-key npm run test:integration
.
Inside ./test/e2e
, you will find a server.js
file that runs a simple nodejs http server.
This server is used to serve the test page, along with other static assets and to receive the error reports from the browser.
The server is automatically started and stopped by Playwright, as you can see at the bottom of the ./test/e2e/playwright.config.ts
file.
The test page is found in ./test/e2e/sandbox.html
.
All tests are found in ./test/e2e/integration.spec.ts
.
Two more configuration files, ./test/e2e/global-setup.ts
and ./test/e2e/global-teardown.ts
are used to start and stop
a local browserstack executable, needed to run the tests on Browserstack. This executable will only be executed if you are testing on Browserstack.
Finally, the ./test/e2e/browserstack.config.ts
file contains the configuration and helper functions to run the tests on Browserstack.
Playwright recommends that integration tests should run on the latest browser versions. But we also use BrowserStack to run these tests on older browsers. This setup is a bit fragile and error logs are not always helpful
If CI starts failing without clear reason, try the following:
Sometimes BrowserStack will resolve to a newer playwright version than the one we use in our tests.
If this happens (compare input capabilities client.playwrightVersion
and browserstack.playwrightVersion
on a BrowserStack test session)
first try to update @playwright/test
and browserstack-local
to their latest versions.
This is necessary because BrowserStack might select a newer playwright version to run the
tests on and unfortunately we don't have full control over this.
This package comes with a postpublish
script (scripts/release-cdn.sh
)
which is executed every time a new version is released to NPM.
The script publishes to our js.honeybadger.io CDN (hosted on AWS via S3/CloudFront).
For the CDN release, make sure you have the following environment variable available in your shell:
export HONEYBADGER_JS_S3_BUCKET=honeybadger-js
export HONEYBADGER_DISTRIBUTION_ID=cloudfront-id
AWS credentials are read from ~/.aws/credentials, using the default profile.
If the CDN release fails for some reason (bad AWS credentials, for instance),
re-run the release manually with by executing the script npm run postpublish
.
We use BrowserStack to run our automated integration tests on multiple platforms in CI.
This package is MIT licensed. See the MIT-LICENSE file in this folder for details.