TypeError: Expected signal to be an instanceof AbortSignal

[netcoding87]

Package Version: "^3.0.3"

• nodejs
  • nodejs version: 12.13.1
  • os name/version: Win 10 (1809)

Describe the bug
I am deploying a backend node app (using typescript) inside a docker container (based on node:12.13.1-alpine). Inside this app I am trying to authenticate to azure via loginWithServicePrincipalSecret. But right now I am getting the following error: TypeError: Expected signal to be an instanceof AbortSignal

To Reproduce
Steps to reproduce the behavior:

import { ComputeManagementClient } from '@azure/arm-compute'
import { VirtualMachine } from '@azure/arm-compute/esm/models'
import * as msRestNodeAuth from '@azure/ms-rest-nodeauth'

const login = async () => {
  try {
    return await msRestNodeAuth.loginWithServicePrincipalSecret(
      cliendId,
      secret,
      domain
    )
  } catch (err) {
    console.error(err)
  }

  return null
}

export const listVMs = async (): Promise<VirtualMachine[]> => {
  try {
    const resourceGroupName = 'myResourceGroupName'
    const creds = await login()
    if (creds) {
      const client = new ComputeManagementClient(creds, subscriptionId)
      const result = await client.virtualMachines.list(resourceGroupName )
      return result.map((machine) => machine)
    }
  } catch (err) {
    console.error(err)
  }

  return []
}

Expected behavior
Expect to be able to receive the auth response.

Additional context
I've already seen the issue #82 which is similar but adding dom and/or dom.iterable to the tsconfig.json did not help. Here is what my tsconfig.json looks now:

{
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "emitDecoratorMetadata": true,
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "forceConsistentCasingInFileNames": true,
    "isolatedModules": false,
    "lib": ["esnext", "esnext.asynciterable", "dom", "dom.iterable"],
    "module": "esnext",
    "moduleResolution": "node",
    "noImplicitAny": false,
    "outDir": "./build",
    "resolveJsonModule": true,
    "sourceMap": true,
    "strict": true,
    "target": "ES2019"
  },
  "include": ["src"]
}

[netcoding87]

After further investigation on this topic I managed to find out that this problem comes from the production mode build. On local dev I build and run the app in development mode and everythings works fine. But of course for deployment I switch to production and then the type error is thrown. When build and running the app locally in production mode the same error is also thrown...

[kepikoi]

Having the same issue with @azure/identity@1.0.2 running a production webpack build. No issue evident when building to development

@netcoding87 were you able to work around this?

[netcoding87]

Hey @kepikoi, unfortunately not with webpack... We switched to use typescript compiler only and there we do not have this issue anymore.

[kepikoi]

I think I found the cause of this issue. Tldr is webpack does rewrite the constructor names in production mode and node-fetch 2.6 contains logic where it compares whether some constructor name is exactly AbortSignal which is just not the case with the rewritten artifact.

This issue is documented in node-fetch/node-fetch#667 and was fixed in the 3.x branch which is currently in the pre-release stage.

So, unless the maintainers of https://github.com/Azure/ms-rest-js are willing to upgrade node-fetch to an unstable release, it seems like we're stuck with this error for some time

[kepikoi]

It is possible to disable the minimization of constructor names in webpack in production which will work around node-fetch/node-fetch#667

module.exports = {
  //...
  optimization: {
    minimize: false
  }
};

With this I was able to get a working production build again

[daviwil]

Hi all, thanks for documenting the fixes you made to work around the issue! I don't think we'll be able to update to a pre-release version of node-fetch in the short term since it would introduce extra maintenance overhead. For now I'd recommend that anyone who encounters this issue to follow @kepikoi's example to disable this option in Webpack to get around the issue.

[rohinz]

If you don't want to disable minimization at all, just use a regular expression to prevent minificaiton of the AbortSignal type:

const TerserPlugin = require('terser-webpack-plugin')

const config = {
  mode: 'development',
 // your default config
}

module.exports = (env, argv) => {

  if (argv.mode === 'production') {
    config.mode = 'production'
    config.devtool = 'source-map'
    config.optimization = {
      ...(config.optimization || {}),
      minimize: true,
      minimizer: [
        new TerserPlugin({
          terserOptions: {
            keep_fnames: /AbortSignal/,
          },
        }),
      ],
    }
  }

  return config
}

[CdTgr]

For anyone working with esbuild and encounter the same error, use the --keep-names flag.