Overriding Sentry.init throws TypeError: Cannot set property init of #<Object> which has only a getter.

[kavitaasiwal]

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• Provide a link to the affected event from your Sentry account

Package + Version

• @sentry/browser
• @sentry/node
• raven-js
• raven-node (raven for node)
• other:

Version:

5.21.1

Description

Overriding Sentry.init results in TypeError: Cannot set property init of #<Object> which has only a getter.

With the typescript upgrade to v3.9.7 in v5.21.1, the init export has changed unexpectedly.

It changed from -
var sdk_1 = require("./sdk"); exports.init = sdk_1.init;
to -
Object.defineProperty(exports, "init", { enumerable: true, get: function () { return sdk_1.init; } });

Previously, one could use the following to override Sentry.init which does not work anymore -

`const Sentry = require('@sentry/node');
Sentry.init = (options) => {
init({
dsn: ...
...options
});

Sentry.init()
`

[AbhiPrasad]

Hey thanks for reporting.

We know this is an issue as it was raised by some other users previously.

Just curious though, why did you choose to override Sentry.init over just creating a new function to initialize Sentry? I figure you can probably do something like

export function initSentry(options) {
  Sentry.init(options);
}

and then import initSentry as needed right?

We are currently trying to determine if we should roll back the change from the typescript upgrade, so if others arrive on this issue, please comment with your situation and use case.

[kavitaasiwal]

Thanks for the quick response Abhijeet! The only reason we decided to overwrite init was to make it easier for other teams that needed to use our internal package to migrate from their existing usage of @sentry/node.

I am going to add our own init function to guard against future breakages but it would be nice if this issue is fixed so that our existing users on the previous version don't start breaking.

[jacobpgn]

Hey there! Thanks for the library.

I think we've seen a similar issue as a result of this change. In tests, we're using sinon to stub/fake/spy methods on Sentry, and assert that they're called correctly, eg

sinon.spy(Sentry, 'captureException');
doStuff();
expect(Sentry.captureException).to.have.been.calledOnceWithExactly("foo");

Previously this was okay, but since the TypeScript bump sinon is unable to set up the spy:
TypeError: Attempted to wrap undefined property captureException as function

I imagine we could solve this with an application-specific handleException function or something instead of testing against Sentry specifically, but it was a surprising change!

[AbhiPrasad]

Cool, thank you for your feedback. We have decided to rollback the typescript change to fix this, and we will better communicate typescript upgrades in the future to prevent situations like this.