Jest: ESモジュールのネイティブサポートを追加することを検討してください

Jestには独自のrequire実装（https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js）があるため、単なる実装よりもはるかに複雑になります。構文をサポートし、デフォルトで.mjsます。 また、実験的なフラグをアクティブにすることにも反対です。

import / exportを自動的にトランスパイルすることは可能かもしれませんが、セマンティクスの実装は大変な作業であり、ノード6のサポートのためにおそらく1年間ブロックされます。

SimenBに同意します。 これをvmモジュールと連携させるには、ノードチームからのいくつかのフックが必要です。 ただし、当面はこれをサポートする必要があると思いますが、完全なネイティブ実装をミラーリングするのではなく、babelを使用してコンパイルし、 babel-jest内部を要求するようにします。 テストの目的では、これは正常に機能すると思います。とにかく、ノードランタイムが提供する必要があるのと同じ保証を提供する必要はありません。

では、 babel-plugin-transform-es2015-modules-commonjsとbabel-plugin-dynamic-import-nodeをbabel-jest追加するだけですか？

ええ、それは私が考えていたものです。

皆さん、 https：//github.com/standard-things/esmを統合するのはどうですか？ 高速で、多くのエッジケースを維持します。

@TrySound具体的にはどのように見えますか？ 試作品を作れますか？

まだ独自のrequire-implementation（モックに必要）があるので、それはあまり役に立たないと思います。

そして、ノードのルールとブラウザのルールの両方を操作する必要があります。

私は修正されて、それが私たちのために完全に機能することを非常に嬉しく思います：D

@std/esmどうやら冗談で動作するはずです： https ：

誰かがそれを回転させて、ドキュメントのPRで戻ってくることができますか？ 🙂

ユーザーはどこでもサポートを望んでいると思いますが、テストファイルの依存関係に対してのみ機能することがわかりました。

// test.js
require = require('@std/esm')(module, { esm: 'js', cjs: true });
const utils = require('./utils');

// utils.js
export { default as update } from './update';

それは良いですが、理想的ではありません。

https://github.com/tarunlalwani/jest-overriding-require-function-stackoverflow

では、babel-plugin-transform-es2015-modules-commonjsとbabel-plugin-dynamic-import-nodeをbabel-jestに追加するだけですか？

ESモジュールで非常に価値のある「エクスポートの欠落」チェックを実行しないため、これは優れたソリューションではないと思います。 たとえば、Reactリポジトリでは、Rollupがこれらの間違いを見つけたが、 es2015-modules-commonjs Jestは見つけられなかったという理由だけで、ビルドをより頻繁に実行し始めました。

@ std / esmはどうやらjestで動作するはずです

彼らの相互運用に時間を費やすのはかなり素晴らしいことです。 このハッキーなソリューションが最終的に壊れることはかなり確実です： //stackoverflow.com/questions/46433678/specify-code-to-run-before-any-jest-setup-happens。 しかし、Jest側で何かを公開するだけの問題であれば、それがサポートされているのを見るのはクールでしょう。

@SimenB 、私の考えでは、当面のステップはそれほど複雑ではありません。 緊急のことは、たとえbabelがテストの舞台裏で助けているとしても、人々が.mjsモジュールで作業できるようにすることです。 そうしないと、.mjsを使用したい場合に、別のテストソリューションを見つける必要が生じる可能性があります。

1. testMatchプロパティを修正して、.mjsファイルが見つかるようにします
   （現在、正規表現がすでに正しいように見えても機能しません。.mjs拡張子を拒否するハードコードがどこかにある可能性があります）
2. node.jsを実行するときに--experimental-modulesフラグを渡して、ネイティブで実行されるようにします
3. Jestは.mjsを今日の.jsとまったく同じように扱う必要があります（たとえば、jest requireの場合）-インポートステートメントは今日の.js内ですでに許可されているため、.mjs拡張子のみを許可する必要があります。

最終的な解決策は複雑で時間がかかるかもしれませんが、それは避けられないことではありませんか？

こんにちは、誰かがこのエラーを修正することができましたか？

「node--experimental-modules」オプションを指定して.mjsを使用しています。 回避策はありますか？

「node--experimental-modules」オプションを指定して.mjsを使用しています。 回避策はありますか？

これは実験的なものであり、完全には具体化されていません。 組み込みモジュールをインポートする方法など、基本的なことでまだ空中にあるチャーンがたくさんあります。 AVAのようなプロジェクトでは、ローダーパイプラインとして@std/esmを使用できるようになりました（Babelをバイパス）。 たぶん、冗談は同様のアプローチを取ることができます。

@std/esmサポートすることは私たちがやりたいことです、それを実装するのを手伝うことは大歓迎です！

@SimenBいつかハングアウトでチャットできますか？

こんにちは@ SimenB👋

esmユーザーがesm + Jestデモを提供してくれたので、より公式な牛の小道を作成するための良い出発点になるかもしれないと思いました。

アップデート：

esm + Jestデモが更新され、基本的なモジュール名マッピングがサポートされました。

それはいいね！ 共有していただきありがとうございます。

統合をどこにしたいかを理解する必要があります。 CSS（または他の非jsアセット）ファイルをどのように処理しますか？ それはただの変容であるべきですか？ 組み込みのbabel変換はどうですか？ 何かに影響を与える場合、着信ローダーに関してJestはどのように動作する必要がありますか？

コミュニティの貢献esm対応の代替ジェストランナー（または非公式/実験的な旗）にはメリットがあるようですので、そのようなことで進歩を遂げることができます。 ジェストチームからの興味はありますか？

requireはランナーに実装されておらず、ランタイム自体にあります。 プラグ可能にするための貢献は大歓迎です（参照番号848）。

サンプルコード@jdaltonをリンクして問題なく（またはそれに近い）moduleグローバルが必要なことです。 モジュールがテスト間でリークする可能性があることを意味するかどうかわかりませんか？ esmが内部でそれをどのように処理するのかわかりません。 また、モックを処理しないため、 importモックはまだ壊れます

JestがCJSを利用する方法を微調整する必要があるかもしれません。 たとえば、 moduleオブジェクトをモックする場合、プレーンオブジェクトを使用する代わりに、 require("module")から、 module.requireをラップ/上書きして、要求をインターセプトし、必要に応じてジャグリングすることができます。

アップデート：

私は現在、 esmしてJestを箱から出して有効にすることに取り組んでいます

@jdalton esm互換性のあるアップデートはありますか？

こんにちは@JasonCust 、すごい私のコメントがいくつかの注目を集めています！

esm Jestサポートを有効にするために必要な作業の特定が進んでいます。 私の実験では、ESMで記述されたテストをJestにロードして評価しました。 esmローダー側で必要な作業は、 vm.Script処理方法をより一般的なものにすることです。 現時点では、主に単一のモジュールを想定したREPLで使用するためにこれに接続します。 Jestのサポートを揺るがすには、これをもう少し一般的にする必要があります。 Jestが何かを変更する必要があるようには見えません。 vm.Scriptサポートのリファクタリングはまだ私のTODOにあり、実験的なWASMサポートなどをリリースする前に引き続き取り組む予定です。 現時点では、改善されたAPMとモックサポートの周りに出現したバグを潰してきました。

Jestでesmを使用できることに興奮しているので、 @ jdaltonを更新していただきありがとうございます。 あなたがそれらのことに取り組んでいる間あなたを煩わせないように、私たちが進歩とともに従うことができるesmためのタスクはありますか？

リポジトリをフォローするこのスレッドを購読し続けることができます。 Jestのサポートはv3.1.0リリースで行われるため、そのバージョンに注意を払うことができます。

@jdalton esmでJestをサポートすることについてのニュースはありますか？

こんにちは@deepj！

それはまだ私のリストにあり、これを行う前に取り組むことができる項目は縮小しています。 Jest内でesmモジュールをテストするための補足的なJestサポートを改善してきました_（ただし、Jestテスト内のCJS）_。 Jest側の実装を批判的にブロックするものはまだありません_（したがって、彼らが行う作業はありません）_。 私の雇用主であるMicrosoftもJestのヘビーユーザーであるため、これを改善することも私の日常業務の目標の1つです。 私はすぐにそれに取り組むことを望んでいます。

@jdalton知って

この機能を本当に楽しみにしています：speak_no_evil：

過去2時間、この機能を機能させようとしています。 非常に多くの部分的な解決策、半分文書化された回答があり、それらはすべて互いに異なります...以前はnode.jsパッケージをテストするのは簡単でした。

では、 babel-plugin-transform-es2015-modules-commonjsとbabel-plugin-dynamic-import-nodeをbabel-jest追加するだけですか？

その考えはどうなりましたか？ それを実装する上で何か問題はありますか？

こんにちは@jdalton。 この問題の状況について最新の情報を入手していただけませんか。 ご迷惑をおかけして申し訳ありませんが、しばらくお待ちしております。少なくとも過去6か月間はアップデートをお送りいただければ幸いです。 ありがとうございました ：）

こんにちは@ SurenAt93！

お待ちいただいてありがとうございます。 Jestのサポートを受けて、月末までにリリースされることを望んでいます。 これで、Jest変換としてesmを指定します。

いいね。 その変換はバベルとどう違うのですか？

@kenotron

Jestのtransformオプションを使用することは、 esmローダーをサイドロードする方法です。 そのため、ソースも技術的に変換されていますが、 esmローダーも接続されています。

質問がもっとある場合、バベルとesmの違いは何ですか。 Babelは、ソースを変換するパッケージのコレクションです。ターゲットの1つはESM構文である可能性があります。 esmローダーは、ランタイム環境をシミュレートするゼロ依存関係ローダーです。 したがって、 esmは、動的なimport()などをサポートし、関連する

@jdalton仕事とサポートをありがとう！

@tomheller ;）

過去2時間、この機能を機能させようとしています。 非常に多くの部分的な解決策、半分文書化された回答があり、それらはすべて互いに異なります...以前はnode.jsパッケージをテストするのは簡単でした。

同意します。

私は簡単なVueプロジェクトを作成しましたが、これも問題を明らかにしています。
https://github.com/igasparetto/vue-jest-test
私はそれを動かすことができませんでした。

次のページの指示に従いました。

• https://vuejs.org/v2/guide/unit-testing.html
• https://medium.com/@kevin_peters/unit -testing-vue-js-components-with-jest-86e14ef499da
• このスレッドを参照してください： https ：

私のマシン（それが重要かどうかはわかりません）：

• Windows 10 Pro64ビット
• ノードv8.9.4
• Vue：3.2.3
• npm：6.5.0

@kenotron

Jestのtransformオプションを使用することは、 esmローダーをサイドロードする方法です。 そのため、ソースも技術的に変換されていますが、 esmローダーも接続されています。

質問がもっとある場合、バベルとesmの違いは何ですか。 Babelは、ソースを変換するパッケージのコレクションです。ターゲットの1つはESM構文である可能性があります。 esmローダーは、ランタイム環境をシミュレートするゼロ依存関係ローダーです。 したがって、 esmは、動的なimport()などをサポートし、関連する

@kenotronアップデートをお願いします。

@igasparetto 、これを@jdaltonの仕事です。 私はまだその解決策を試していませんでした。

そこにある最新のステータスは次のとおりです： https ：

うん！ 申し訳ありませんが、思ったより時間がかかっています。 ローカルでは、関連するすべてのtest262テストに合格しています。 それらを取得する過程で、モック関連のシナリオテストがスリップしたため、リリースする前にそれらを元に戻す必要があります。 乗り越えられないわけではなく、少し時間がかかります。 私は1月16日にCovalentConfでプレゼンテーションをnpm tinkはESM構文のサポートにesmを早期に

1月16日、それまでにリリースされることを望んでいます

@jdaltonプレゼンテーションがうまくいったことを願っています。

このリリースのアップデートはありますか？

@igasparettohttps ： //github.com/standard-things/esm/issues/97#issuecomment-454985896およびhttps://github.com/standard-things/esm/issues/706☺️にあります

計画を立てるのに役立つように、ここに小さな「データポイント」を残しておきます。 この問題に対処するために、皆さんが時間とスキルを寄付していることを理解しています。 私自身開発者として、あなたの貢献に感謝します。

私は昨日のほとんど、土曜日もそうですが、クライアント側とサーバー側の両方でjavascriptモジュールの速度を上げるために費やしました。 ESM、CommonJS、AMD、なんて紛らわしい混乱。 .mjs拡張子を使用して（ノード）モジュールをロードするESMで動作するjestテストを取得できませんでした。 同じモジュールをクライアント側で正常にロードできました。 importステートメントでモジュールを使用するノード「クライアント」を作成できます。 babelの有無にかかわらず、esmの有無にかかわらず、同じインポートステートメントを消費するようにjestを正しく構成できませんでした。 私は最終的にavaに切り替え、彼らのWebサイトのレシピに従って動作するようになりました。 はい、私はレシピに従いました、私はすべての部品を機能させる機械を完全に理解していません。 しかし、少なくとも、JavaScriptモジュールと関連する単体テストをロードするESMを作成できるようになりました。 私が思うに。 私は1つの成功に基づいて外挿しています。 また、avaをwebstormに接続するためのレシピもあります。 しかし、少なくとも彼らは私のような単なる人間にレシピを提示しています。

私はまた、このメッセージが私が泣き言を言っているように読まれるのを理解しています（私は部分的にそうです）。 私は冗談になっているすべての仕事を見る。 しかし、このESMサポートは、私にとってキラーであり、取引を妨げるものです。 フィードバックをいただければ幸いですが、そうでない場合は、これを無視するか、削除するように依頼してください。

v12リリースでの

冗談はノード12でネイティブESモジュールをサポートできる場合@dandv私はにいくつかの調査を行ってきたそれは使用して冗談を伴いますvm.SourceTextModuleに渡される、いくつかのCLIフラグを必要とする、APIをnode ：

--experimental-modules --es-module-specifier-resolution=node --experimental-vm-modules

APIも超低レベルです。

未定。

https://github.com/nodejs/node/issues/27387でのディスカッション

更新：ノードのモジュールローダーの設計がロックダウンされるまで待機するように指示されました。 それまでの間、standard-things / esm＃706が最善の策かもしれません。

jestは非常に優れたテストライブラリです。 esmのサポートは本当にそれが完了するために必要なすべてです！

更新：ノードのモジュールローダーの設計がロックダウンされるまで待機するように指示されました。 それまでの間、 standard-things / esm＃706が最善の策かもしれません。

悲しいことに、これは冗談では機能しません。

@jdaltonlodashのESModuleExportsビルドであるlodash-esを使用しています。 私たちのプロジェクトはAngularv7プロジェクトであり、内部でWebpackv4をバンドラーとして使用します。 知らない人のために、 lodash-esはWebpack v4でツリーシェイク可能です！ （◔౪◔）⊃ʻ☆ﾟ。*・。

残念ながら、JestがまだESモジュールをサポートしていないことを考えると、これが問題を引き起こしています。 この機能がまもなくJestの一部になることを願っています。 lodash-esをJestと連携させる方法を知っている人はいますか？

Jestは次のエラーメッセージで失敗します。

node_modules\lodash-es\lodash.js:10
    export { default as add } from './add.js';
    ^^^^^^

    SyntaxError: Unexpected token export

私たちのjest.config.js

jest-preset- angularnpmパッケージも使用しています。

module.exports = {
  testMatch: ['**/+(*.)+(spec|test).+(ts|js)?(x)'],
  transform: {
    '^.+\\.(ts|js|html)$': 'ts-jest'
  },
  resolver: '@nrwl/builders/plugins/jest/resolver',
  moduleFileExtensions: ['ts', 'js', 'html'],
  collectCoverage: true,
  coverageReporters: ['html']
};

残念ながら、JestがまだESモジュールをサポートしていないことを考えると、これが問題を引き起こしています。 この機能がまもなくJestの一部になることを願っています。 lodash-esをJestと連携させる方法を知っている人はい

変換時にlodash-esを無視しないようにJestに指示します。

  "transformIgnorePatterns": [
    "[/\\\\]node_modules[/\\\\](?!lodash-es/).+\\.js$"
  ],

https://www.npmjs.com/package/jest-esnext

https://github.com/haraldrudell/ECMAScript2049/tree/master/packages/jest-esnext

@haraldrudellの指示によると、パッケージの使用方法は明確ではありません。package.jsonの横にjest.config.js content module.exports = require('jest-esnext')という名前のファイルを作成しますが、すでに構成がある場合はどうなりますか？ 統合する方法は？

これは使用されるファイルです

https://github.com/haraldrudell/ECMAScript2049/blob/master/packages/jest-esnext/config/jest.config.js

あなたはの内容置き換えることができるかもしれません_defaultあなたのものにjest.config.js

こんにちは、みんな、
node 12.13.0 LTSがついにリリースされました...その件に関するニュースはありますか？

@ mtsmachado8 ESMモジュールはまだ実験的なものとしてフラグが立てられているので、v8チームはまだしばらく時間が必要だと思います...おそらくロードマップで失敗しました。

https://nodejs.org/api/esm.html

フラグのないESMの場合、このPRが実施されます
https://github.com/nodejs/node/pull/29866

@azder @haraldrudellだから、基本的にあなたのソリューションでは、 node_modulesものを含むすべてのJSファイルに対してBabel変換を行いますか？

私の場合、次のようにトランスフォーマーを構成する方法が見つからなかったため、プリセットを直接使用する必要がありました。

const babelPreset7Esnext = require('babel-preset-7-esnext');
const babelJest = require('babel-jest');

module.exports = babelJest.createTransformer(
    babelPreset7Esnext(undefined, {decorators: {legacy: true}})
);

ノードのモジュールサポートがデフォルトで切り替えられるようになりました

https://github.com/nodejs/node/pull/29866

ECMAScriptモジュールのデフォルトサポートは13.2.0に搭載されました

https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V13.md#13.2.0

ローダーが利用可能になるまで、これに取り組むことはありません。 それらがなければ、NodeにはJestが適切なサポートを提供するために必要なフックがありません。 https://medium.com/@nodejs/announcing -core-node-js-support-for-ecmascript-modules-c5d6dc29b663を参照して

ネイティブモジュールを使用していて、 jestを使用したい人のために。
これに取り組んでいる間、ノードv。13.2.0のクイックフィックスを提案します。
babel-plugin-transform-default-import
使用法（_package.json_内）：

{
  "babel": {
    "presets": [
      [
        "@babel/preset-env",
        {
          "targets": {
            "node": "current"
          }
        }
      ]
    ],
    "plugins": ["transform-default-import"]
  },
}

Libsをインストールする必要があります：
npm i --save-dev @babel/core @babel/preset-env babel-plugin-transform-default-import

注：exportという名前のbabelを持つライブラリがない場合（または使用しない場合）、mabyはbabel-plugin-transform-default-importを使用する必要はありません。

@infodusha素晴らしい:)。 これありがとう。

私のプロジェクトでは、プラグインなしで動作します。

npm i --save-dev @babel/preset-env

babel.config.js （これは、 .babelrcではなく、そのように名前を付ける必要がありました）：

module.exports = {
    presets: [
        [
            '@babel/preset-env',
            {
                targets: {
                    node: '13.2',
                },
                modules: 'commonjs',
            },
        ],
    ],

    plugins: [],
};

秘訣は、ファイルをディレクトリに分割し、適切なpackage.jsonを使用することです。

testディレクトリで、私は使用しました

{
  "type": "commonjs"
}

src dirにいる間：

{
  "type": "module"
}

@azderただし、ネイティブモジュールでcommonjsという名前のインポートを提供するパッケージをインポートする場合は、デフォルトのインポートでインポートする必要があり、babelでは名前付きのインポートを使用する必要があります。 おそらく、そのようなパッケージ、またはes6エクスポートを提供するパッケージはありませんが、すべてのパッケージが明日それを実行する準備ができているわけではありません

@infodushaおそらく私は今何も持っていませんか？ 私が書いたものを試して問題を見つけましたか、それとも私がそれを使用するのに問題があると思いますか？

「ネイティブモジュールでimportという名前のcommonjsを提供するimportパッケージ」の意味が明確ではないため、実際の例を提供してください。

これまでのところ、 .jsファイル拡張子を持つすべてのファイルの書き込みに問題はありません./srcディレクトリには"type":"module"あり、 ./testディレクトリには"type":"commonjs" ：

const imported = require('../src/module.js').default;
const {anotherOne} = require('../src/module.js');

これは、 JestがESモジュールをCommonJSコードにサイレントにトランスパイルするためです。

これは、 ESモジュールをネイティブにテストする必要があると私が思うものです。

(async () => {
    const [
        { default: imported },
        { anotherOne },
    ] = await Promise.all([
        import('../src/some-module.js'),
        import('../src/another-module.js'),
    ]);

    // Rest of your test goes here.
})();

@azderこれらは回避策です。

package.son type=moduleとその中に2つのファイルfirst.jsとsecond.jsを含むディレクトリmymoduleを作成します。
次に、 import { first } from "mymodule";試してください

Node ESMを使用するには、jsonにexportsフィールドを配置する必要がありますが、現在、このフィールドを備えたパッケージはありません（つまり、lodash）。

あなたの例はうまくいくように見えるかもしれませんが、 some-module.jsまたはanother-module.jsいずれかが名前付きモジュールをimportしようとするとすぐに壊れます：それらはカスケードで壊れます。

@damianobarbatiあなた_ NEED _ "type": "module"でpackage.json 、それなしで、すべての.jsあなたのモジュール内のファイルがCommonJSとしてロードされます。

exportsは、外部コンシューマーに公開されるものを制限するためにのみ使用され、条件付きエクスポートの場合、 .jsファイルがCommonJSまたはESMのどちらとして解析されるかにはまったく影響しません。

@ Exe-Bossが言ったことによると、@ damianobarbatiあなたは間違っています、ところで、

これは、JestがESモジュールをCommonJSコードにサイレントにトランスパイルするためです。

はい、私はJestの癖に頼っています。それが、 devDependencies babelを追加せずにbabel.config.jsを使用していた理由です。

@damianobarbati

注意してください、私は作業中のプロジェクトを持っています、その中で私はトランスパイルされたJestを使用していますが、srcディレクトリはモジュールタイプを持っています、注意してください、 ./srcはbabel設定ファイルがあるルートではありません（それはCJSです）癖のため）。

また、NPM（またはパッケージの作成者）がミックスアンドマッチの準備が整っているとは思わないため、CJSであるNPMから何もインポートしないのであなたは正しいです。

私のプロジェクトの目標は、ESM（工具の脂肪を減らすこと）だけを持つことです。したがって、Jestは、それ自体でトランスパイルされる唯一の例外です。

@azderこのようなもの？ https://github.com/damianobarbati/node-jest/tree/feature/azder-test

@damianobarbati

そのようなもの、これがプロジェクトhttps://github.com/azder/clipです。 ブログ投稿の抜粋の最後の文にあるように、私のpackage.jsonには「依存関係」がないことに注意してください。私は、NPMのESMモジュールとCJSモジュールを混在させないことにしました。

この方法でJestのニーズに対応するために、ESMモジュールから必要なものをトランスパイルしますが、 node_modulesディレクトリを処理するにはさらに多くのbabel構成が必要になる可能性があります。

https://medium.com/@nodejs/announcing -a-new-experimental-modules-1be8d2d6c2ff

現在、require（ 'pkg'）とimport'pkg 'の両方で使用できるパッケージを作成することはできません。 これに対処するための取り組みが進行中であり、上記の変更が含まれる可能性があります。 特に、Node.jsは、パッケージのESモジュールエントリポイントを定義するために「メイン」以外のフィールドを選択する場合があります。 コミュニティが「モジュール」フィールドを採用していることは承知していますが、「モジュール」を使用して公開されたパッケージの多くには、Node.jsで評価されない可能性のあるESモジュールJavaScriptが含まれているため、Node.jsがそのフィールドを採用する可能性は低いです（拡張子がファイル名から除外されているか、コードにrequireステートメントなどが含まれています。 これが解決されるまで、Node.jsでの使用を目的としたESモジュールパッケージを公開しないでください。

Jestでのサポートを追跡するために開いたばかりの＃9430を参照してください。 私はこの問題を議論のために開いたままにしておきます。

@SimenBこれは良い兆候です！ これとJest25リリースノートでのモジュールの言及は、サポートがより早く見られることを期待しています。

@SimenB正しく覚えていれば、JestはESMとしてのみ公開されているNPMパッケージを使用できなかったため、一部のnode_modulesパッケージでもBabelを有効にする必要がありました。 これは変わりましたか？

ユーザーコードとライブラリコードの両方がサポートされるまで、インポート/エクスポートをトランスパイルする必要があります

@SimenB ：

ユーザーコードとライブラリコードの両方がサポートされるまで、インポート/エクスポートをトランスパイルする必要があります

私たちの場合、これまでのところ最善の方法はこれです。すべてのパッケージに/es/ dirがあるためですが、これは壊れやすく、他のプロジェクトには適さない可能性があります。

transformIgnorePatterns: ['node_modules/(?!.*?/es/.*\\.js)'],

あなたが言ったように、Jestはtype: moduleにもかかわらず、変換なしでそれらのパッケージを取得しません。

ユーザーコードとライブラリコードの両方がサポートされるまで、インポート/エクスポートをトランスパイルする必要があります

これに関する大まかなスケジュールはありますか？
ノード14リリースから：

現在の実装は、ユニバーサルJavaScriptへの道を開くESMモジュールを作成するための将来の証明モデルを提供すると私たちは信じています。 詳細については、ドキュメントをご覧ください。

Node.jsでのESMの実装はまだ実験段階ですが、Node.jsでESMを「安定」と呼ぶことができるようになりつつあると確信しています。 警告を取り除くことは、その方向への大きな一歩です。

そのため、commonJSを使用してNPMパッケージ（JESTテストフレームワークを実装するテストで消費される可能性があります）をずっと長くエクスポートすることには消極的です。

Jest25.4から実験版を出荷しています。 25.5にはかなりの数のバグ修正がありますが、それでも本来あるべき場所にはありません。 ＃9430で進捗状況を確認できます