TypeError: Object(...) is not a function

[Christilut]

Versions + Platform

• SDK version - @sentry/[email protected]
• Electron version - [email protected]
• Platform - Windows

Description

TypeError: Object(...) is not a function
    at Module.init (C:\Users\user\workspace\my-app\.webpack\main\index.js:2711:158)
    at Module../src/system/sentry.ts (C:\Users\user\workspace\my-app\.webpack\main\index.js:61734:58)
    at __webpack_require__ (C:\Users\user\workspace\my-app\.webpack\main\index.js:21:30)
    at Module../src/main.ts (C:\Users\user\workspace\my-app\.webpack\main\index.js:61297:72)
    at __webpack_require__ (C:\Users\user\workspace\my-app\.webpack\main\index.js:21:30)
    at C:\Users\user\workspace\my-app\.webpack\main\index.js:85:18
    at Object.<anonymous> (C:\Users\user\workspace\my-app\.webpack\main\index.js:88:10)
    at Module._compile (internal/modules/cjs/loader.js:967:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1004:10)
    at Module.load (internal/modules/cjs/loader.js:815:32)
webpack built a902fc3ba47ce5946243 in 26053ms

Getting the above error after upgrading from 2.4.0 to 2.5.2.
Downgrading back to 2.4.0 works for now.

Not running the latest Electron, that might be it?

[timfish]

Nothing changed drastically between 2.4.0 and 2.5.2 and there haven't been any other reports of similar issues.

I'd be happy to look at a repository that demonstrates the issue, but without a reproducible example, I have no way to diagnose what's causing this.

[chetbox]

We are getting the same error with @sentry/[email protected] but not with @sentry/[email protected]. We are using Electron 12.0.9 with Electron Forge and @electron-forge/plugin-webpack 6.0.0-beta.52.

[timfish]

If someone can supply a simple reproduction of this issue I more easily advise of the cause.

[chetbox]

We don't see the issue with a fresh Electron Forge + Webpack + Typescript project, even after downgrading to use the same versions of electron (12.0.9) and webpack (4.44.1)

We're using Typescript and the issue persists with both ts-loader and babel-loader with @babel/preset-typescript.

I've tried both const Sentry = require('@sentry/electron') and import * as Sentry from '@sentry/electron' with the same results.

I'm a bit stuck as how to reproduce this in a minimal project!

[timfish]

What code does the error originate from? ie. what code does the top of the stack trace point to?

[chetbox]

Just as the stack trace above, the error occurs within the Sentry.init.

I tried adding logging into the init function but don't see the log printed. I might be barking up the wrong tree though..!

[timfish]

What does your webpack configuration look like? TypeScript config?

It seems like webpack somehow messes up the imports when bundling but nothing drastic has changed between 2.4.0 and 2.5.2.

The only time I've seen webpack bundle with no errors but it fail at something like this at runtime has been related to TypeScript allowSyntheticDefaultImports being enabled.

[ThomasSzabo]

Exact same issue here. Rolling back to 2.4.1 fixes the problem. The error points to this line

function init(options) {
    var electronIntegrations = _sentry_node__WEBPACK_IMPORTED_MODULE_4__["defaultIntegrations"].filter(function (integration) { return integration.name !== 'OnUncaughtException'; });
    if (options.defaultIntegrations === undefined) {
-->        options.defaultIntegrations = Object(tslib__WEBPACK_IMPORTED_MODULE_0__["__spreadArray"])(Object(tslib__WEBPACK_IMPORTED_MODULE_0__["__spreadArray"])([], Object(tslib__WEBPACK_IMPORTED_MODULE_0__["__read"])(electronIntegrations)), [
            // eslint-disable-next-line @typescript-eslint/unbound-method
            new _integrations__WEBPACK_IMPORTED_MODULE_6__["OnUncaughtException"]({ onFatalError: options.onFatalError }),
            new _integrations__WEBPACK_IMPORTED_MODULE_6__["Electron"](),
        ]);
    }
    Object(_sentry_core__WEBPACK_IMPORTED_MODULE_2__["initAndBind"])(_client__WEBPACK_IMPORTED_MODULE_5__["MainClient"], Object(tslib__WEBPACK_IMPORTED_MODULE_0__["__assign"])({ transport: _transports_net__WEBPACK_IMPORTED_MODULE_7__["NetTransport"] }, options));
}

[timfish]

@ThomasSzabo thanks for the update.

My best guess is that this has been caused by the upgrade of the tslib library which occurred at 2.5.0. This should not have caused any issues because the version of TypeScript we use to build is apparently compatible. However this comment suggests that it may also cause incompatibility with TypeScript versions consuming this library!

What versions of the TypeScript compiler are you using in your projects where this issue can be reproduced? I'm guessing <3.9?

@AbhiPrasad is @sentry/browser on [email protected] for this reason, or is that more to do with it being stuck on an older TypeScript version?

[chetbox]

We're having this problem with a project using Typescript 4.0.5.

I finally managed to repro the error in a minimal project by copying all dependencies from our project's package.json and yarn.lock: https://github.com/chetbox/sentry-electron-init-error

Thanks for looking into this, @timfish!

[timfish]

@chetbox I updated your tslib dependency to ^2.3.1 and everything works.

Looks like webpack 5 had compatibility issues with tslib < v2:
webpack/webpack#11613

[chetbox]

Thanks @timfish, that works!

[chetbox]

It it possible to change the dependency on tslib to >2 to ensure you end up with the right version?

[timfish]

I'm not sure I follow.

You were using a version of tslib that was not compatible with the version of webpack you're using.

For 2.5.4 we depend on tslib@^2.2.0.

[chetbox]

Given that @sentry/electron has a dependency on tslib@^2.2.0 should NPM/Yarn throw an error if I have a tslib dependency of 1.x.y? If not, is it possible to express that in @sentry/electron (or webpack's) package.json?

[timfish]

Given that @sentry/electron has a dependency on tslib@^2.2.0 should NPM/Yarn throw an error if I have a tslib dependency of 1.x.y? If not, is it possible to express that in @sentry/electron (or webpack's) package.json?

That's not how JavaScript dependency resolution works. It's perfectly valid to have multiple versions of the same dependency in your dependency tree.

I'm pretty sure the issue you have encountered is that you listed [email protected] in your dependencies and this is not compatible with your tooling. There is nothing we can do in @sentry/electron to ensure you've selected suitable dependencies for your webpack version.

I've just noticed a new problem after upgrading @sentry/electron...

Please report different/unrelated issues in new Github issues rather than adding them to this discussion.

[chetbox]

Please report different/unrelated issues in new Github issues rather than adding them to this discussion.

Will do, thanks. I thought it might be related given we didn't get that issue before so wanted to flag it here. I'll see if I can make a minimal repro of this and open a new issue.

[AbhiPrasad]

@AbhiPrasad is @sentry/browser on [email protected] for this reason, or is that more to do with it being stuck on an older TypeScript version?

It's due to us being on a lower typescript version, see: getsentry/sentry-javascript#3354

[timfish]

If anyone can reproduce this with the correct version of tslib installed and supply a reproduction please open a new issue!