[BUG] Typing issue with @microsoft/applicationinsights-web v2.7.0

[mishani0x0ef]

Description/Screenshot

It seems that after the release of the @microsoft/applicationinsights-web v2.7.1 - apps with version v2.7.0 and TypeScript not working correctly anymore.

TS2322: Type 'ReactPlugin' is not assignable to type 'ITelemetryPlugin'.

Steps to Reproduce

Simple library with following deps:

"dependencies": {
    "@microsoft/applicationinsights-react-js": "3.0.5",
    "@microsoft/applicationinsights-web": "2.7.0",
    "axios": "0.21.1",
    "qs": "6.9.1",
    "reflect-metadata": "0.1.13"
  },

Initialize app:

this.pluginInstance = new ReactPlugin();
this.insightsInstance = new ApplicationInsights({
      config: {
        instrumentationKey,
        disableFetchTracking: false,
        enableRequestHeaderTracking: true,
        enableResponseHeaderTracking: true,
        extensions: [this.pluginInstance],
      },
    });

this.insightsInstance.loadAppInsights();

• OS/Browser: Windows
• SDK Version [e.g. 22]:
• How you initialized the SDK: NPM

Expected behavior

No breaking changes in typing between patches of the library.

Additional context
Add any other context about the problem here.

[mishani0x0ef]

The issue can be fixed by updating dependency @microsoft/applicationinsights-web to 2.7.1.

However, it's quite strange that by having exact dependencies in the package.json you can face such compatibility issues. And actually, it's the second time I'm fixing the same issues with the AppInsight library. The first one was when we were using 2.6.3 and 2.7.0 was released.

Other strange thing with versioning:

@microsoft/applicationinsights-react-js v.3.0.5 is using React 16 as peer dependency
@microsoft/applicationinsights-react-js v.3.1.0 is using React 17 as peer dependency

Not sure is it good to change the required version of React without a major update?

[MSNev]

We previously did have an issue where we needed to deploy the react and react-native components separately due to different versions of TypeScript that the components used.

We have since updated (as of v2.7.0) upgraded to a common version of TypeScript across the board. So that all of the components are now built, upgraded and deployed in sync and as such they are pinned to the specific versions.

As such for versions compatibility of the React component

• v3.0.5 is designed to work with v2.5.10
• v3.1.0 is designed to work with v2.6.0
• v3.2.x is designed to work with v2.7.x (with v3.2.1 (published on Friday) works with v2.7.1)

Ideally, all of these components would be release with the same version number, but due to historical issues the version numbers drifted.

The primary reason we pin the versions is that while we try to ensure backward compatibility from a functionality perspective, type compatibility is more complicated especially as we move forward providing tree-shaking and new features. We also try and limit how and when these types of changes are introduced, in part this is one of the reasons for introducing the BaseTelemetryPlugin base class to help minimize these issues.

Having said all this, yes it's painful and while if fails the compile phase you can

• Cast it, as functional compatibility is maintained
• When upgrading the base component you should always upgrade to the compatible sub component

Will use this issue to add a compatibility table to the readme's to make this more clear.

Not sure is it good to change the required version of React without a major update?

Probably so, but I believe that this was caused by some downstream dependencies (don't remember the exact reason), we are also not React experts so feel free to keep prodding us when we do something wrong 😄, as a React component user it would be good if you set up an alert on the react component code so that when we publish a PR you should be alerted and your feedback is welcome.

[MSNev]

Action: Add compatibility table for the supported versions of each component

[MSNev]

I think is this also the same fundamental issue as microsoft/ApplicationInsights-JS#1678

[mishani0x0ef]

Thanks for the great clarification.

I didn't know that there are versions compatibility relations. I will try to downgrade v2.5.10.

It perfectly makes sense to me now. And for sure historical issues its something that is unavoidable for a big project :)

[navigate-lifeworks]

After upgrading @microsoft/applicationinsights-web" from 2.8.8" to 2.8.9" in my react project , the error occurs again. It seems that the microsoft-applicationinsights-core-js dependency has conflict versions (e.g. 2.8.8 vs 2.8.9)

the package @microsoft/applicationinsights-react-js" is 3.4.0",

Type 'ReactPlugin' is not assignable to type 'ITelemetryPlugin'.
Types of property 'setNextPlugin' are incompatible.
Type '(next: import("../.yarn/virtual/@microsoft-applicationinsights-core-js-virtual-e8bb66ad9c/0/cache/@microsoft-applicationinsights-core-js-npm-2.8.8-c65c41fa9e-473e210e57.zip/node_modules/@microsoft/applicationinsights-core-js/types/JavaScriptSDK.Interfaces/ITelemetryPlugin").ITel...' is not assignable to type '(next: import("../.yarn/virtual/@microsoft-applicationinsights-core-js-virtual-9a8911a1d7/0/cache/@microsoft-applicationinsights-core-js-npm-2.8.9-98cea3c981-8066707bb0.zip/node_modules/@microsoft/applicationinsights-core-js/types/JavaScriptSDK.Interfaces/ITelemetryPlugin").ITel...'.
Types of parameters 'next' and 'next' are incompatible.

[MSNev]

Hmm, I just checked every commit from 2.8.8 to 2.8.9 and there was not any changes to any types, including the ITelemetryPlugin interface....

The only possible change was the 2.8.9 is not using ^1.1.7 of dynamicProto (which is used internally to help with the instance creation), but this does not affect the exported types and likewise applicationinsights-shims is now ^2.0.2 and this is also not involved with any types...

Can you try cleaning your local yarn packages? (I don't use / know yarn) as it's looking like some form of local conflict...

react has this as it versions
"@microsoft/applicationinsights-core-js": "^2.8.5",
"@microsoft/applicationinsights-common": "^2.8.5",

So with the release of 2.8.9, your code should only be referencing v2.8.9 and not 2.8.8 at all...

[navigate-lifeworks]

Nev (@MSNev), thanks for quick response, I did clean yarn cache but it didn't help. I tried to reinstalled all packages to regenerate the lock file, the problem is gone...seems its yarn (PNP) related.

[MSNev]

Linking #95, I'm "hoping" that with the signature changes being introduced with 19.4.0 (sorry, no backporting) that we will finally get / resolve these on-going issues