issue with ts jest and node-fetch v3

[a-wf]

I upgraded node-fetch to v3, and run jest test and I get:

 Jest encountered an unexpected token

    Jest failed to parse a file. This happens e.g. when your code or its dependencies use non-standard JavaScript syntax, or when Jest is not configured to support such syntax.

    Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration.

    By default "node_modules" folder is ignored by transformers.

    Here's what you can do:
     • If you are trying to use ECMAScript Modules, see https://jestjs.io/docs/ecmascript-modules for how to enable it.
     • To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
     • If you need a custom transformation specify a "transform" option in your config.
     • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.

    You'll find more details and examples of these config options in the docs:
    https://jestjs.io/docs/configuration
    For information about custom transformations, see:
    https://jestjs.io/docs/code-transformation

    Details:
import http from 'http';
    ^^^^^^

    SyntaxError: Cannot use import statement outside a module

      1 | import { Task, DataError } from '@koober/std';
    > 2 | import fetch from 'node-fetch';
        | ^
      3 | import { FacebookResponseError, FacebookTokenInfo, FacebookTokenInfoFormatted, FacebookUserIdentity } from './data';
      4 |
      5 | export interface FacebookClient

      at Runtime.createScriptFromCode (node_modules/jest-runtime/build/index.js:1597:14)
      at Object.<anonymous> (src/bundle/facebook/client.ts:2:1)

I followed instructions, but nothing changes,
I also tried this jest config

  "extensionsToTreatAsEsm": [
      ".ts"
    ],
    "globals": {
      "ts-jest": {
        "tsconfig": "tsconfig.json",
        "useESM": true
      }
    },
     "preset": "ts-jest/presets/default-esm",

but nothing happens

[tomas-hartman]

+1 same issue with ts/jest compiled with babel

  // jest.config.js option that might be relevant
  transform: {
    '^.+\\.[t|j]sx?$': 'babel-jest',
  },

[lynxtaa]

I think I made it work with jest and Typescript. Run jest with experimental-vm-modules enabled:

"test:watch": "node --experimental-vm-modules node_modules/jest/bin/jest.js --watch",

jest.config.json if you are using ES Modules:

{
  "roots": ["<rootDir>/src"],
  "extensionsToTreatAsEsm": [".ts"],
  "testEnvironment": "node",
  "moduleNameMapper": {
    "^(\\.{1,2}/.*)\\.js$": "$1"
  },
  "transform": {
    "\\.[jt]sx?$": [
      "babel-jest",
      {
        "babelrc": false,
        "presets": ["@babel/preset-typescript"],
        "plugins": ["@babel/plugin-proposal-optional-chaining"]
      }
    ]
  }
}

Check you my example repository: https://github.com/lynxtaa/node-fetch-jest-example

jest.config.json if you are using CommonJS:

{
  "roots": ["<rootDir>/src"],
  "testEnvironment": "node",
  "transform": {
    "\\.[jt]sx?$": [
      "babel-jest",
      {
        "babelrc": false,
        "presets": ["@babel/preset-typescript"],
        "plugins": [
          "@babel/plugin-proposal-optional-chaining",
          "@babel/plugin-transform-modules-commonjs"
        ]
      }
    ]
  }
}

And in this case you should use dynamic import:

const fetch = (...args) => import('node-fetch').then(({default: fetch}) => fetch(...args));

[storyalex]

I have a few typescript projects where this happened to me.

Add the following to jest.config.js to run all .js-files through babel when running jest:

  transform: {
    "^.+\\.(ts|tsx)$": "ts-jest",
    "^.+\\.(js)$": "babel-jest",
  },
  transformIgnorePatterns: [
  ],

Note the empty transformIgnorePatterns. By default transforms ignore node_modules.
This worked for me with:

node-fetch: ^3.0.0
babel-jest: ^27.3.1
jest: ^27.3.1
ts-jest: ^27.0.7

[martsie]

Rolling back to 2.6 worked for me to get serverless-bundle to run jest tests.

[ccarcaci]

Same here, rolling back to 2.6 worked. Any of the other solutions were not working.

[sergiycheck]

worked with node-fetch: 2.6.7
example project (ts, ts-jest, node-fetch)

[rguzg]

As typing information is already included in node-fetch 3.0 and up, the @types/node-fetch package after version 3.0 is just a stub. To get typing information you need to install a version of the types package that's inside the 2.x range. In my case, I installed version 2.5.12 and everything's working fine. El lun, 10 ene 2022 a las 11:54, Bruno Mello ***@***.***>) escribió:

…

To those who are rolling back, how are you using the type definitions? ***@***.*** doesn't ship with type definitions and installing @types/node-fetch doesn't seem to solve my problem. Here is how I am importing the module [image: image] <https://user-images.githubusercontent.com/29875060/148814451-763c57a7-3d24-41e5-ad5d-7682db554f48.png> And in my package.json I have listed both @types/node-fetch on devDependencies and node-fetch on dependencies { ... "devDependencies": { ... ***@***.***/node-fetch": "^3.0.3", ... }, "dependencies": { ... "node-fetch": "^2.6.6", ... } } — Reply to this email directly, view it on GitHub <#1289 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMYD4L4RSBSLIK2KKVL424TUVMMNXANCNFSM5D7Q2BZA> . You are receiving this because you commented.Message ID: ***@***.***>

[ravshansbox]

This is a small example where jest works with node-fetch@3: https://github.com/ravshansbox/jest-node-fetch-es-modules

[yunnysunny]

This is a small example where jest works with node-fetch@3: https://github.com/ravshansbox/jest-node-fetch-es-modules

Your link is 404 now.

[plemelin]

Note: edited after original comment this issue should be closed and reference #1279 End note

This is a small example where jest works with node-fetch@3: https://github.com/ravshansbox/jest-node-fetch-es-modules

This is misleading as it works only because you are telling jest to run with support for ESM (--experimental-vm-modules).

As far as I can tell, node-fetch v3 only works as an ESM and you cannot make it work in jest without that flag. Our teams are not going to use that flag unfortunately. So unless this becomes supported in Jest, we are going to use node-fetch <3.0.0

Also looks like it's slowing the adoption of node-fetch v3:

[jimmywarting]

I haven't played with jest lately...
but is the "commonjs" vm able to load esm-only packages using the lazy/async import('node-fetch')?

[vrfdivino]

Using ts-jest with node-fetch@3 still won't work. I suggest use the following version packages. Still works great!

    "@types/node-fetch": "2",
    "node-fetch": "2",

[Brian-McBride]

It is pretty clear that the NodeJS and DOM ecosystem is not ready for 100% ESM modules.
Locking in a lower version creates confusion. It seems that there could have been a period of supporting both until ESM became more mainstream.
Dropping all commonjs support seems to be more idealistic than meeting the realistic needs of production.

[madamiak]

It's just frustrating when you get a SNYK report with the high severity security issue in 2.6.7 and you need to bump to 3.2.10 to resolve it (https://security.snyk.io/vuln/SNYK-JS-NODEFETCH-2964180), but it doesn't work because of Jest issues. What should we do then?

[bahrmichael]

@madamiak If you configure Snyk to only raise issues for dependencies (but not devDependencies), you may decide to only override the dependencies' dependencies. E.g. puppeteer-core has a dependency on node-fetch, which one can override in the package.json as below

  "overrides": {
    "puppeteer-core": {
      "node-fetch": "^3.2.10"
    }
  }

You can then decide to leave Jest at an older version with the vulnerability in place, but without bundling that vuln into your production code.

[Brian-McBride]

I am all for pushing to current releases and standards.
It is clear that ESM is just a bit "too new" for the ecosystem.

Patching a ton of existing tools across thousands to millions of repos to ignore the current version of node-fetch is just burning so many man hours in this world.

I heard the complaint was maintaining two code bases in one repo and the final size. Supporting commonjs is a tooling issue, not at all some manual task every release. And size... We can live with a little bloat during the transitions to ESM across the board.

I very much appreciate the open-source maintainers here. And whatever you all want to do, I'll roll with it even if I don't think it is the best decision for the greater community at this time. I do support the move to ESM only, it is clearly just a little too early at the moment.

[ruslansadygov]

steps are next:

1. jest.config.cjs add
   moduleNameMapper: { "node-fetch": "<rootDir>/node_modules/node-fetch-jest" }
2. and package.json dev dependencies
   "node-fetch-jest": "npm:node-fetch@^2.6.9",
3. package.json dependencies
   "node-fetch": "^3.3.0"

[ravshansbox]

Isn't it the same as requiring "node-fetch": "^2" in package.json?

[ruslansadygov]

nope, because your actual prod code will use latest node-fetch, but for test you will use compatible version as here https://jestjs.io/docs/next/bypassing-module-mocks

[iamrenejr]

This works for me.

[helbing]

If you use ts-jest, this document will help you:

https://kulshekhar.github.io/ts-jest/docs/guides/esm-support/

And you also need to know one thing, if you use snapshotResolver in jest.config.ts, it will not work, because snapshotResolver does not support loading ESM. The support of loading ESM is still progressing.

jestjs/jest/issues/11167

[devjiwonchoi]

@a-wf You can use transformIgnorePatterns in jest.config.

transformIgnorePatterns: [
  "/node_modules/(?!node-fetch)/"
]

package.json

"transformIgnorePatterns": [
  "/node_modules/(?!node-fetch)/"
]