This package depends on [email protected] which doesn't play well with WebPack

[MTCMarkFranco]

This package depends on [email protected] which doesn't play well with WebPack see related issue here: node-fetch/node-fetch#667

can we update this model to leverage version 3 of node-fetch to fix this problem. Getting "TypeError: Expected signal to be an instanceof AbortSignal" whenever we const client = new SecretClient(url, credential); after we receive DefaultAzureCredential() using MSI.

[xirzec]

The three packages which take this dependency are: cosmos, core-http, and perfstress.

@daviwil @southpolesteve any thoughts on updating this dep? I can take a stab at the actual PR, but wanted to make sure there wasn't anything blocking this work.

/cc @bterlson @ramya-rao-a

[bterlson]

I'm not aware of anything blocking the upgrade fwiw.

[southpolesteve]

@MTCMarkFranco Can you provide more info about exactly which libraries you are using and how you are using webpack? const client = new SecretClient(url, credential) isn't something that would be used with @azure/cosmos. We don't support any MSI auth with that package.

@xirzec @bterlson This needs more thorough consideration. node-fetch v3 is still in beta. It also has a significant breaking change that likely will break webpack+browser users

cc/ @zfoster

[bterlson]

Since we aren't using node-fetch in the browser I hope that change won't affect us? We already map to an xhr implementation by default in browsers.

[southpolesteve]

@azure/cosmos does use native fetch in browsers, but other packages may not. We rely on the node-fetch browser field point to be a simple wrapper around the native fetch

[southpolesteve]

node-fetch/node-fetch#786

[southpolesteve]

Removing the cosmos labels since I don't believe this is referring to the Cosmos Data Plane SDK

[daviwil]

I agree with @southpolesteve about node-fetch 3.0, it's probably better to wait until there's a stable release before moving over to it.

[xirzec]

The new pipeline doesn't depend on node-fetch, just node's https module: https://github.com/Azure/azure-sdk-for-js/blob/master/sdk/core/core-https/src/nodeHttpsClient.ts

[MTCMarkFranco]

@MTCMarkFranco Can you provide more info about exactly which libraries you are using and how you are using webpack? const client = new SecretClient(url, credential) isn't something that would be used with @azure/cosmos. We don't support any MSI auth with that package.

@xirzec @bterlson This needs more thorough consideration. node-fetch v3 is still in beta. It also has a significant breaking change that likely will break webpack+browser users

cc/ @zfoster

Hi There,

sorry for the late response...my environment details:

NodeJS Team MessageExtension generated by the Team Yo generator. Basically, I was incorporating KeyVault access into the project (not part of the default template) using the following libraries:

@azure/identity
@azure/keyvault-secrets

full code:
const credential = new DefaultAzureCredential();
const vaultName = process.env["KEYVAULT_NAME"];
const kvUrl =https://${vaultName}.vault.azure.net;
const client = new SecretClient(kvUrl, credential);

[xirzec]

This should be resolved once we upgrade KeyVault to use CoreV2

[ramya-rao-a]

Closing this issue in favor of #15594 that tracks the work needed to update all our packages that use core-http to now use the newer core packages.

@MTCMarkFranco, please subscribe to #15522 and #15595 that specifically tracks the work needed to move the Key Vault and Identity packages (the ones you are using) to use the new Azure Core packages.

cc @sadasant, @maorleger