Sentry-javascript: Expose @sentry/browser isEnabled

[stnwk]

Hi!

Previoulsy with the raven-sdk there was a isSetup() api, see https://github.com/getsentry/sentry-javascript/issues/1226.

It seems to be not available anymore for @sentry/browser, although I found
a protected SentryBrowser.getCurrentHub().getClient()._isEnabled().
Can you please expose this?

https://github.com/getsentry/sentry-javascript/blob/93200d18a7c6bfc3aafd8c2264c997e1d5b28310/packages/core/src/baseclient.ts#L234

[HazAT]

You should be able to do this:
SentryBrowser.getCurrentHub().getClient().getOptions().enabled

Anyway, can you elaborate what the usecase of this is? ^^
This question may sound weird but we want to understand the motivation why to have it exposed, maybe there is a better solution to your problem?!

[stnwk]

Thanks, that worked!

[didnotwant]

@HazAT — it’s worth mentioning that getClient might return undefined:
https://github.com/getsentry/sentry-javascript/blob/c9339c1c8ef10249f35ce5d010462c412db597ea/packages/hub/src/hub.ts#L137
In my code I use it like this:

/**
 * @returns {boolean}
 */
export default () => {
  const client = getCurrentHub().getClient();

  // Note: client might be `undefined`. See: https://github.com/getsentry/sentry-javascript/blob/c9339c1c8ef10249f35ce5d010462c412db597ea/packages/hub/src/hub.ts#L137
  return !!client &&

    // Note: this method was confirmed by one of Sentry maintainers.
    // See: https://github.com/getsentry/sentry-javascript/issues/2027#issuecomment-484475157
    client.getOptions().enabled;
};

[josokinas]

@HazAT We use such for custom event emitters to check whether Sentry has been setup. For example, it might be setup in production and staging but not within local development environment.

[didnotwant]

It’s also worth mentioning that in Raven the isSetup method took dsn into consideration.

In one of my projects the use case was like this:

if (Raven.isSetup()) {
  // emit an event to sentry.io
} else {
  // console.log
}

What was the benefit of it?
We didn’t pass DSN on dev environment (it was an empty string actually) so Raven was disabled but we didn’t want to lose some information (about errors etc.) so we logged them to console.
I think it’s quite similar to what @josokinas described.

In order to keep the behaviour, I decided to re-implement Raven’s isSetup method as a custom utility like this:

import {
  getCurrentHub,
} from '@sentry/browser';

/**
 * @returns {boolean}
 */
export default () => {
  const client = getCurrentHub().getClient();

  // Note: client might be `undefined`. See: https://github.com/getsentry/sentry-javascript/blob/c9339c1c8ef10249f35ce5d010462c412db597ea/packages/hub/src/hub.ts#L137
  return !!client &&

    // Note: previously in usages of `Raven.isSetup` (which
    // this utility recreates) we exploited the fact that [passing falsy DSN
    // prevents Raven from setup](https://github.com/getsentry/sentry-javascript/blob/6edd5d3840017ca6c710a1e0e9d0b6a3aec4072b/src/raven.js#L64).
    // It was useful in case of fallback to `console` methods on development
    // environment where DSN is not given (so Raven was not setup).
    //
    // We don’t want to lose this behavior but unfortunately in @sentry/browser
    // there’s no corresponding method (there’s actually a not exposed method
    // [`_isEnabled`](https://github.com/getsentry/sentry-javascript/blob/93200d18a7c6bfc3aafd8c2264c997e1d5b28310/packages/core/src/baseclient.ts#L234)
    // and only recommended by maintainers way is to [use
    // `client.getOptions().enabled`](https://github.com/getsentry/sentry-javascript/issues/2027#issuecomment-484475157)
    // which does not fit our needs) and that’s why it’s implemented like this
    // here.
    !!client.getOptions().dsn;
};

It’s an update on what I posted in my previous comment.

@HazAT — what do you think about it? Maybe there’s another (I mean: more elegant) way to handle such use-case?

[josokinas]

Yes @didnotwant, this is very similar to what we have been doing 👍

[kamilogorek]

@didnotwant is your only use the one described above? If so, maybe using beforeSend would be the simplest solution here? This way you'd not need if/else in all the places.

Sentry.init({
  beforeSend(event) {
    if (isDevMode) {
      console.log(event);
      return null;
    }
    return event;
  }
});