Critical: @sentry/browser v4.3.3 has usage of undeclared variable

[maxaon]

Package + Version

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

Version:

4.3.3

Description

In version 4.3.3 main file (dist/index.js) contains function safeJoin and assign which contains for loops with usage of tslib_1__default.

This variable is not declared anywhere. When we try in our code use console methods we get exception.

Code example:

console.log('sdf')

exception:

Uncaught ReferenceError: tslib_1__default is not defined
    at e.safeJoin (modal?debug:13)
    at console.log (modal?debug:13)
    at <anonymous>:1:9

Source code of safeJoin

function safeJoin(input, delimiter) {
    var e_1, _a;
    if (!Array.isArray(input)) {
        return '';
    }
    var output = [];
    try {
        for (var input_1 = tslib_1__default.__values(input), input_1_1 = input_1.next(); !input_1_1.done; input_1_1 = input_1.next()) {
            var value = input_1_1.value;
            try {
                output.push(String(value));
            }
            catch (e) {
                output.push('[value cannot be serialized]');
            }
        }
    }
    catch (e_1_1) { e_1 = { error: e_1_1 }; }
    finally {
        try {
            if (input_1_1 && !input_1_1.done && (_a = input_1.return)) _a.call(input_1);
        }
        finally { if (e_1) throw e_1.error; }
    }
    return output.join(delimiter);
}

File contain only 2 requirements

var tslib_1 = require('tslib');
var core = require('@sentry/core');

Please see the file https://unpkg.com/@sentry/browser@4.3.3/dist/index.js There is no declaration of tslib_1__default and this is not a global variable

[lestrato]

I got this too. My error thrown is:

Uncaught ReferenceError: tslib_1__default is not defined

My Solution: change tslib_1__default to tslib_1.

Funny enough, the errors still show up on my sentry.io workspace.

[alxmiron]

Get same error too in 4.3.3

[maxaon]

Maybe I didn't fully described. There is no declaration of variable tslib_1__default. There are only require of tslib and variable called tslib_1. Also tslib doesn't have default exports. I assume there could be issue in build process.

…

On Tue, Nov 20, 2018, 21:50 Kamil Ogórek ***@***.*** wrote: This is correct. tsilb is a direct dependency listed in package.json. If you want to use the build directly from npm install as a standalone file, use build/bundle.js instead. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub

[fuqua]

Agreed 4.3.3 completely crashes my application when I import it. And 4.3.2 does not. I get the same error as @maxaon described. Except it happens thousands of times.

[piotrblasiak]

Same here. Getting this just by importing the lib, which should be helping me with my crashes and not causing them. Good stuff.

[mrshll]

This brought down our production web application tonight, and corresponded with some minor changes to our webpack config. I spent an hour pouring over the change trying to figure out why typescript libraries were breaking. Oh well. In good company :)

[zetaab]

downgrading to 4.3.2 solves this problem

[reduxdj]

Sweet, i've been pulling my hair out for hours... thanks

[HazAT]

Fixed with 4.3.4 sorry for the inconvenience.

[kamilogorek]

TypeScript is hard.

[RXminuS]

Yeah this broke for us in production as well. As much as I appreciate the amazing work you guys are doing...this felt a bit like your fire alarm having a short, creating a fire and burning down your house. It kind of defeats the purpose. Luckily we were able to catch the release that caused this bug using Sentry, so there was some meta-humor at least. Maybe sent everyone that got caught by this bug some stickers to make it up?

[kamilogorek]

Added tests around this to prevent issues like this in the future - #1760

[munderwoods]

Same here! Rolled back for now.

[kamilogorek]

@munderwoods it's' already patched in the newest release

[stripathix]

Hi @kamilogorek Please, can you explain what does this mean "TypeScript is hard." was this problem caused due to typescript? "use strict" and JSLint would have caught this during development. :-)

[HazAT]

@stripathix It's more that the tooling is hard, we still do not fully understand what caused the issue. Somehow the import of tslib was broken in our utils library (but only there). We fixed it by working around the need for tslib to be imported there. I don't think "use strict" und TSLint (we use it) helped us there. We added a test so we catch something like this before we release stuff.

[kamilogorek]

@stripathix as Daniel mentioned, neither "use strict" nor JSLint would help, as it's not a code issue.

The thing is that all of our libraries are written in TypeScript, thus they use its builtin polyfills for some language methods/syntax. We changed it, so that tslib, which is a library containing all those runtime polyfills is bundled only once, during a final build, instead of per-depencency basis as it used to be.

To make it more visually clear. Before it was something like (kinda):

browser (bundled its own tslib) and has dependency on:
  - core (bundled its own tslib)
  - hub (bundled its own tslib)
  - utils (bundled its own tslib)

Now, we changed it so it's only done once:

browser (bundled its own tslib) and has dependency on:
  - core (references tslib from the main package)
  - hub (references tslib from the main package)
  - utils (references tslib from the main package)

This made a whole bundle smaller, as we removed tslib duplication.
For some strange reason, it worked for all our packages from mono-repo, but not for utils. And reference to tslib, which is generated fine (see @sentry/utils/dist), was not transcribed to reference parent package instance as it should, despite it being compiled by TS compiler just fine.

And yes, we have TSLint, Prettier, use strict (see @sentry/browser/dist) and none of it helped :)

[GuusDeGraeve]

This issue seems to be re-introduced in version 4.6.0 or earlier.
Getting below error now
tslib_1__default is not defined

I can see it is being referenced in node_modules/@sentry/browser/dist/index.js

[kamilogorek]

@GuusDeGraeve well, that's not something that should ever happen... fixed in 4.6.1 and added a very straightforward test for it so it won't happen (hopefully!) again.

[Galkon]

Can you guys please update the @sentry/electron module to reflect this new version? Installing the latest @sentry/electron comes with an @sentry/browser version with this issue.

[HazAT]

@Galkon I replied on the electron issue already 0.16.0 should fix the issue.