tslib v1.13.0 has breaking change

[MSNev]

tslib v 1.13.0 is causing a compile error due to a breaking change

Compiling...
Using tsc v2.5.3
common/temp/node_modules/tslib/tslib.d.ts(37,78): error TS2304: Cannot find name 'PropertyKey'.
common/temp/node_modules/tslib/tslib.d.ts(37,103): error TS2304: Cannot find name 'PropertyKey'.

We have created an issue with tslib to try and get this fixed, if not we will need to roll back and be fixed to v 1.11.2. As a temporary workaround if you have this issue is to update your local package.json files to reference "1.11.2" instead of "^1.11.1"

Raised TSLib Issue
microsoft/tslib#115

[MSNev]

As this is the 2nd time in recent history and looking at how the tslib project is now structured, it appears that it's going to remain busted for us as we are currently targeting es3 as our base module to ensure that we don't accidently break our SDK user base that has users that are currently still relying on ES3 based browsers.

As such, I'm going to completely break our dependency on tslib, without the normal corresponding code bloat (as size is still a major concern). But I'm attempting to do this in a backward compatible way so that we don't break

• CDN only users
• Older TypeScript users ( < 3.x)
• More modern TypeScript users (i.e. 3.x)
• Anyone who is currently user any version of tslib
  • as previously we broke users using TypeScript and a newer version of tslib then we needed to be pinned to (v1.10.1 from memory
  • This is also a major consideration for breaking the dependency, so we don't break anyone who wants/needs to use a version of tslib > 1.11.2 (the last known good version that we can compile with)

[nicolashenry]

@MSNev Could you release a version still using tslib at least for esm version? The recent change create pollution in global object.

[MSNev]

Hi @nicolashenry, this is probably not going to be an easy thing until TSLib address the breaking change they have created in version 1.13.x. As the only way we can currently do that would be to fix the version of tslib to "1.11.2" as this is the last version that we can actually compile with (anything > 1.12.0 causes compile failure).

As part of this first iteration I did deliberately expose __extends() and __assign() to ensure that anyone who consumes the *.ts files directly would not break, as typescript by default (when we don't importHelpers (tslib) AND set noEmitHelpers to true) uses global versions of __extends() and __assign() :-(

The reason we don't emit the helpers is for overall size, as when the helpers are emitted (for every class) the total size explodes for no real gain and we are actively working to reduce the overall size for all new features and we will eventually be going over the existing code to reduce their sizes as well.

I'll create a new Issue (as this one will get closed once we are fully deployed to the public CDN) to investigate the removal of the global methods.

If I could ask the following to make sure I end up investigating the correct things

• Is it just the __extends() or __assign() or are you seeing something else in the global scope
• Which modules / files are you ingesting (using) [i.e. just the AISku or the individual components, if the later which ones).

Cheers

Nev

[MSNev]

Created #1280 to investigate how we could possibly stop exposing the global functions.

[nicolashenry]

Is it just the __extends() or __assign() or are you seeing something else in the global scope

Both __extends and __assign but nothing else.

Which modules / files are you ingesting (using) [i.e. just the AISku or the individual components, if the later which ones).

I am only using "@microsoft/applicationinsights-web" module (and indirectly its dependencies).

I would prefer tslib version to be fixed to 1.11.2 even if it would potentially create duplicated version of tslib in my projects because, since I am using rollupjs, it would be the same result as with 2.5.5 except that it would not pollute the global object (but I understand that it could cause some trouble in a different configuration than mine to have different versions of tslib in the same project).

I see your issue here microsoft/tslib#115 , if the problem is only with "es3" target in a major version, I would suggest to drop support for this target and change it to "es5" (all alive browsers including IE11 support it since more than 10 years now).

[MSNev]

Looking at the generated code the /dist/ folder looks like we could safely stop exposing these methods, but, for the /dist-esm/ we can't, without declaring this as a breaking change and requiring users to provide their own versions of these methods.

Unfortunately, we can't just fix it @ 1.11.2 as this breaks some consumers such as the discussion in #1242. So that's not really an option.

Likewise we also have users who's end-users are still using IE7/IE8 (i.e. medical organizations that are still using XP), so while it would be great to be able to re-target @ es5 we would also need to beef up our testing infrastructure to ensure that we don't break any es3 users.... However, our current test infra actually doesn't work on IE at all let alone IE running in IE7/8 mode.

So for now that is not currently an option either...

On the upside, these methods are only exposed via the applicationinsights-shims module, so we only have a single location to make the change (once we identify a safe way to achieve this).

[nicolashenry]

You may can re-bind "tslib" to a local module with some post-build script after typescript transpilation. For example:

import * as tslib_1 from "tslib";

to

import * as tslib_1 from "./tslib.js";

or maybe bind it to your own tslib compatible module:

import * as tslib_1 from "@microsoft/applicationinsights-shims";

It would maybe break sourcemaps however.

Thanks for your answers :).

[MSNev]

Included in v 2.5.5 which is now fully deployed

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.