Jest: [バグ]別のディレクトリで重複した手動モックが見つかりました

+1

私の場合、 cacheDirectory / var / folder / dm / vt920lmd6tzdq_709zkykwx40000gn / T / jestをクリアし、npmの依存関係を再インストールすると、これらのメッセージは表示されなくなりました。

問題のあるコードは次のとおりです。

https://github.com/facebook/jest/blob/cd8976ec50dbed79cfe07f275052cdd80d466e73/packages/jest-haste-map/src/index.js#L98

しかし、それを確認するテストがあるため、動作が明示的に必要とされる可能性があるようです。

https://github.com/facebook/jest/blob/8de90b320c87a0a36d68f6bd8177620a985df269/packages/jest-haste-map/src/__tests__/__snapshots__/index-test.js.snap#L15

追加されたもの：

https://github.com/facebook/jest/commit/cfade282fbbe2737b6dd2cee1cf3da3ee8624512

パス全体ではなくbasenameキーとして使用しているのはなぜですか？

/ cc @flarnie

つまり、手動モックを使用する場合、モジュールのbasenameは、プロジェクト内でグローバルに一意である必要があります。 私のユースケースでは、次のようなことができないことを意味します。

import { MyWhatever } from 'models/MyWhatever/schema';
import { MyOtherWhatever } from 'models/MyOtherWhatever/schema';

同時に手動モックを使用します。 Jestは現在、それらをschemaを嘲笑していると見なし、文句を言います。

回避策は簡単ですが（s / schema / MyWhateverSchema /）、テスト以外のコードの名前を変更して再構築し、冗談を喜ばせるのはバグのようです🐞。

はい、これは確かにひどいです。 手動モックシステムは本当に良くありません、そして私たちがすべてのFBを壊さないことを確実にすることができると仮定して、状況を改善するPRを受け入れてうれしいです（しかし私はそれを世話することができます:)）

涼しい。 明日はパッチを作成する時間が見つかるかもしれませんが、約束はありません😅

@cpojerこの動作には特別な理由がありますか？

fbがモジュールに一意のファイル名を使用しているという事実と関係がありますか？ 同じ名前の2つのモックを許可しないことがどのように意味があるのか​​他の方法ではわかりません...

はい、モックも「グローバル」です。 残念ながら、これは私たちが一緒に暮らさなければならないひどいデザインです。 FBでは4000以上のモックファイルが間違った場所にあります（そして多くの場合、適切な場所さえありません）。 これは次の半分の早い段階で修正される可能性が高いため、Jestでは改善されるはずです。 オープンソース向けのJestの動作を改善するPRをサポートできることをうれしく思います。今のところ、FBでのJestの古い動作を維持できれば。

@cpojer旗はどうですか？ フラグでこれを有効/無効にするPRを受け入れますか？

ええ、それは設定オプションでなければなりません。 しかし、私は警告について話しているだけでなく、機能全般についても話しているのです。

@cpojer right-これは冗談のどの部分に触れますか？

解決コードはjest-runtimeから呼び出されます： https ：

@cpojerポインタをありがとう：+1：

@cpojerこの動作を切り替えるためのJEST_USE_BASENAME_FOR_CACHINGなどのグローバルオーバーライドはどうですか？

少なくとも、一意でないファイル名を楽しむことができ、FBでは何も壊れません。

もちろん、これは一時的な解決策です。

つまり、これはいくつかの/etc/profileまたは~/.bashrc

export JEST_USE_BASENAME_FOR_CACHING="true"

（またはenvを含むファイル）
その後

$ jest

またはこれ、envファイルの変更なし：

$ JEST_USE_BASENAME_FOR_CACHING="true" jest

あなたが思うこと？ それは一種のハックですか、それとも大丈夫ですか？ ：ウィンク：

2つのバージョンのjest（ ^15.0.0と^17.0.0 ）を使用して、新しいリポジトリを試してみました。後者は警告を表示しますが、テストは期待どおりに動作します。

@ColChここでの問題はキャッシュにあるとは思いません。おそらく、より適切な名前はJEST_USE_BASENAME_FOR_MOCKING可能性があります。

@cpojer FBコードで名前の一意性に制限がある場合、モックのマップのキーとしてフルパスを使用しても問題は発生しません。

私は正しいですか、それとも私が見ていないものがありますか？

私が見る2つの解決策は次のとおりです。

• getMockNameを変更して、ベース名またはフルパスを使用するオプションに対応します
• その機能を完全に削除します

@cpojerの回答を見るといいでしょう

みなさん、遅れてすみません、今はたくさんのものでかなりバックアップされています。

このシステムを改善するために必要なJestの重大な変更を行うことにした場合は、私は大丈夫だと思います。 手動のモックは本当にめちゃくちゃで、うまく機能しません。 私たちがやりたいことの1つは、 "haste_modules": ['path/a', 'path/b']"などの構成オプションを使用して「ヘイストモジュール」（内部FBモジュールシステム）の範囲を制限し、この奇妙なモックを含め、これらのフォルダー内のヘイストモジュールのみを確認することです。動作。 誰かがこの変更を加えたいのなら、それは驚くべきことです。

次に理解すべきことの1つは、これです。 __mocks__/a.jsがa.jsにマップされるように、すべての手動モックがローカルである場合、node_moduleモックをどのように処理しますか？ これにはいくつかの方法があります。

• 新しい__node_modules_mocks__フォルダーを導入しますが、それは醜いです。
• rootDir （プロジェクトルート）から見た最上位の__mocks__フォルダーは、グローバルフォルダーとして機能する可能性があります。

要約すると：

• Jestで手動モックを修正しましょう！
• 急いでモジュールに名前空間を付けて、特定のフォルダー/正規表現に制限しましょう。
• 急いで動作させるために特定のフォルダをホワイトリストに登録する必要がある場合でも、現在のモック動作がFBでも機能することを確認してください（今のところ["<rootDir>"]ように見えると思います）
• それでもノードモジュールをモックできるようにする方法を理解してください。

どう思いますか？

順番に：

• Jestで手動モックを修正しましょう！

HURRAY：smile ：： tada：

• 急いでモジュールに名前空間を付けて、特定のフォルダー/正規表現に制限しましょう。
• 急いで動作させるために特定のフォルダをホワイトリストに登録する必要がある場合でも、現在のモック動作がFBでも機能することを確認してください（[""]今のところ、私は推測します）

急いでニーズを理解できるかわかりません。
「これらのモジュールは速攻モジュールです」と言う可能性を与えるということですか？
4つのモジュールがある場合： /path_1/a 、 /path_1/b 、 /path_2/a 、 /path_2/c 、設定は

"haste_modules:" ["/path_1/a", "/path_2/c"]

/path_1/aと/path_1/bのみが/path_1にのみ存在するように制限されているため、 /path_2/cは有効であり、 /path_2/aはエラー/警告を発生させます。

シングル/ダブル*場合でも、ターゲットは特定のファイルやディレクトリ全体である可能性があります。

• それでもノードモジュールをモックできるようにする方法を理解してください。

私は現在の動作を維持し

モックしているモジュールがノードモジュール（例：fs）の場合、モックはnode_modulesフォルダーと同じ親ディレクトリに配置する必要があります。

私の考え：

速攻モジュール：

haste_modulesはいいと思います、それはcollectCoverageFromや他のオプションと同じようにフィットします：グロブの配列
すべてのsrcを_haste_モジュールとして持っていて、1つのディレクトリだけが急いでいない場合：

haste_modules: [
  "src",
  "!src/foo"
]

node_modules

@EnoahNetzach誰かがアプリモジュールとnode_modulesのモジュールに同じ名前を持っている場合はどうなりますか？

急いでそれを機能させるために...うーん、私はそれが次のように説明できると思います：

ノードモジュールproject/node_modules/react与えられると、モックはproject/__node_modules_mocks__/react.js内部になります
ファイルproject/react.jsがある場合は、 project/__mocks__/react.js使用します

（もちろん、 react.jsは例です。ここでは、 npmからインストールできるすべてのモジュールの中で任意のファイル名を使用できます）

本当に、 node_modulesモジュールをませんか？

node_modules内のモジュールを

さらに考えようとしています

私が気付いたように、 react-nativeプロジェクトの場合、 application modulesをモックし、 node_modulesのモジュールをlodash ）。

つまり、次のようになります。

• ダムコンポーネントごとに手動で作成されたモックコンポーネント（ダムコンポーネントはレイアウトコンポーネントです）
• すべてのテストファイルのjest.mock呼び出しの長いリスト

__言いたいこと__：いくつかのパスでモジュールを_自動モック_する機能があると非常に便利です。

これは、config内のよく知られたデータ構造array-of-jest-globsの周囲に実装でき、その上でモジュールをフィルタリングできます。

そのことを段階的に説明します

この構成エントリを指定します

"autoMockingPaths": [
  "src/components/dumb/**/*.js",
]

そしてこのコードはsrc/screens/app.jsます：

import _ from 'lodash';
import Button from '../../components/dumb/button.js';

// blah blah AppScreen implementation skipped

そして、 src/screens/__tests__/app-test.js画面のこのテストコード：

import AppScreen from '../app.js';

describe('AppScreen', () => /* testing app screen */);

app-test.jsコンテキストで、この状況になります。

• AppScreenは嘲笑されていません
• lodashは嘲笑されていません
• Buttonによって要求され、 AppScreen 、嘲笑されます

...答えることができます、 automockエントリでどのように再生されますか？

簡単に言うと、 automock: trueは次と同等です。

"autoMockingPaths": [
  "<rootDir>"
]

自動モック...待って！

automock特別な価値を導入するだけかもしれませんか？ 少なくともそれは人々の設定を壊すことはありません

たとえば、次の設定エントリを使用します。

automock: "app"

jestはすべてのアプリケーションモジュールを自動モックし、モジュールの実際のバージョンをnode_modulesから残します

アプリレベルのモジュールの自動モッキング、 @ cpojerについてどう思いますか？ 私の特定のケースでは非常に効率的だと思います。

"haste_modules"に完全に同意します。

私たちは個人的にオートモッキングをあまり使用しないので、何が良いかは言えません。私の大げさな推測では、 "autoMockingPaths"変数は十分に便利で弾力性があると思います。
それどころか、私は"automock": "app"が硬すぎると感じています（冗談はすでにデフォルトで自動モックを無効にしています）。

__node_modules_mocks__はオプションかもしれません、私は希少性が醜さを補うことに同意します（私の特定のケースでは、 node_modulesあざけることはめったになく、それをしなければならないときはjest.mock(...)を使用します
唯一の注意点は次のとおりです。ネストされたnode_modulesフォルダー（例： src/node_modules ）がある場合、そのモジュールをグローバル__node_modules_mocks__からモックする必要がありますか？それ、または通常は__mocks__同じ場所にありますか？

誰かがnode_modulesとapp modules同じモジュール名を持っている場合、単にスローされる可能性があります

例えば

アプリモジュールとしてapp/express.js （電車のゲームをしている可能性があります）
npmからのWebサーバーとしてのapp/node_modules/express
throw new Error("can't mock express.js file - it duplicates one from node_modules")

この場合、 __mocks__はnode_modulesに使用できますが、開発者はそのような衝突で独自のモジュールの名前を変更する必要があります

いや...これは__node_modules_mocks__より醜いですよね？

つまり、 npm install edモジュールx以降がある場合、コードベースのより深いところに、ネストされたnode_modulesフォルダーにモジュールxを定義します。 ？

ネーミングの衝突は通常、最も近いものを優先することによってノードで処理されますが、これがどのように急いで機能するかはわかりません。

Create React Appのようなプロジェクトがそれを使用しているか、近い将来使用するので、私はこれを取り上げてい

ちなみに、 問題に何らかの形で関連していますか？

これを速攻の仕組みの変更に焦点を合わせ続けましょう（デフォルトではなくホワイトリスト/ブラックリスト）。 <rootDir>/__mocks__をノードモジュールモックのデフォルトにする必要があることを維持したいと思います。 これを構成オプションにすることもできます。デフォルトは<rootDir>/__mocks__ 「globalMocks」です。 誰かがこれに取り組む気がありますか？

私は次の週末までにこれに取り組むことができるはずです。

私はこの日曜日にPRに取り組むことができます、私はちょっと自由です

@cpojer要約するだけです-デフォルト値<rootDir>/__mocks__ globalMocksエントリを作成します。 このオプションは、パスを指定することにより、 jest内でのnode-haste使用を規制しますか？ それともパスの配列になりますか？

これらはこれを解決するためのいくつかの大きな変更だと思いますが、単一のglobalMocksオプション（文字列または文字列の配列）とhasteModulesオプション（速攻モジュールのパスの配列）の両方が必要だと思います。 このコードのほとんどは、jest-haste-mapとjest-resolveにあります。 適切なソリューションがどのようになるかはまだ100％わかりません。

投稿者：マックスSysoev [email protected]
送信日：2016年12月9日金曜日8:18:44 AM
宛先：facebook / jest
Cc：Christoph Pojer; 言及する
件名：Re：[facebook / jest] [バグ]別のディレクトリで重複した手動モックが見つかりました（＃2070）

私はこの日曜日にPRに取り組むことができます、私はちょっと自由です

@cpojerhttps ：//github.com/cpojer要約するだけです-デフォルト値のglobalMocks構成エントリを作成します/ __モック__。 このオプションは、パスを指定することにより、jest内でのノードヘイストの使用を規制しますか？ それともパスの配列になりますか？

-
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/facebook/jest/issues/2070#issuecomment-265958606で表示するか、スレッドをミュートしますhttps://github.com/notifications/unsubscribe-auth/AAA0KAMFc34iKqBDLHZzgaGHqyc3WkAzks5rGQ7kgaJp

申し訳ありませんが、私のワークステーションが壊れてしまい、数か月（1〜2か月）で動作させる方法がないようです。 私もこのPRで私のプロジェクトを失いました:(だから、責任を取って申し訳ありません。

getMockName動作を変更するための設定オプション

jestの内部についてはあまり詳しくありませんが、FBのjestを壊さずに問題を修正するための最も簡単な解決策のようです。

これは私が当初思っていたよりも複雑になるでしょう。 私にとって、手動モックは、最も近いファイルも置き換える必要があります。 このようなもの：

{ 'aws-sdk': '/Users/project/__mocks__/aws-sdk.js',
  'slack': '/Users/project/__mocks__/slack.js',
  '/Users/project/db/index': '/Users/project/db/__mocks__/index.js',
  '/Users/project/slack/index': '/Users/projects/slack/__mocks__/index.js' }

require('aws-sdk')は/Users/project/__mocks__/aws-sdk.js解決されるはずです。これはnode_moduleモックです。

require('./db') （またはdbへのパス）は次のように解決されます： /Users/project/db/__mocks__/index.js 。

jest手動モックをセットアップする方法についての私の理解（そして上記のようなものが使用されている場合はおそらくより多くのドキュメントがあるはずです）は、それらが__mocks__ディレクトリ内のモックされているファイルにできるだけ近いはずであるということ

手動モックは、モジュールのすぐ隣の__mocks __ /サブディレクトリにモジュールを書き込むことによって定義されます。 （https://facebook.github.io/jest/docs/manual-mocks.html）

それを考えると、上記の動作は私にとって最も理にかなっています。

考え？

これは、上記のようなものを実装するための最初のパスです： https ：

次のような純粋な「名前付き」モックが許可されなくなったため、jestユニットテストの大部分が失敗します： https ：

IMO、 createRuntimeようなものは、test utilsフォルダーにあり、それを必要とするテストにインポートされる必要があるテストユーティリティです。 手動モックとして実装する方法は、保存する必要があるものとして私にはあまり意味がありません。

1つのオプションは、既存の動作と上記の変更のクリーンアップバージョンを切り替える構成変数を追加することです。 しかし、それが何と呼ばれるべきかはよくわかりません。

Facebookでは非常に大きく依存しているため、現在の動作を破ることはできません。

@cpojer同意します。 コードを読んだ後、私はこのコメントを本当に理解していませんでした： https ：//github.com/facebook/jest/issues/2070#issuecomment-265027510。 現在の動作に解決されるディレクトリのリストをホワイトリストに登録することをサポートできるでしょうか。

2つの新しい構成オプションについてはどうでしょうか。

• fullPathMockResolution （既存の動作を維持するためにデフォルトでfalse ）
  と相まって：
• namedMockDirectories ： fullPathMockResolutionが有効になっている場合、その配列内のすべてのディレクトリは既存の動作で解決されます。 FBのユースケースの場合、これは上記のように[<rootDir>]になります。

これにより、開発者はフルパス解決を選択できるため、既存のjestインストールによる変更が不要になり、必要に応じて特定のディレクトリの既存の動作も有効になります。

cc @voideanvalueこれはあなたが考えなければならないことかもしれません（新しい速攻実装の一部としての名前空間手動モック）。

+1、これを修正する方法はありますか？

+1

この問題を修正する方法に関する更新はありますか？ このような構造に従うと、これは本当に苦痛であることがわかります。

project/
├── models
│   ├── index.js
│   ├── __mocks__/
│   │   ├── index.js/
├── challenges
│   ├── index.js
│   ├── __mocks__/
│   │   ├── index.js/

現在、パスを考慮する必要があるため、実際には競合する名前がない場合でも、「競合する」名前の2つを使用している場合は、テストでモジュールを手動でモックする必要があります。

乾杯、
ドミニク

@cpojerここに更新はありますか？ 回避策はありますか？

私にとってのちょっとした回避策は、requireでモジュールをモックすることです

jest.mock('models/index', () => require('models/index/_mocks_/index'));

jestがファイルをキャッチしないように、 __mocks__フォルダー名を_mocks_た。

これが機能するある日、 _mocks_名前を__mocks__ 、jest.mockからrequire部分を削除します。

まず、素晴らしい仕事をありがとう。
第二に：これは本当に、かなりイライラします。 モックされたファイルが、同じくモックされるコードベース全体の他のファイルと名前を共有している場合、テストファイルでjest.mockを使用することを余儀なくされています。 巻き上げでは実際のモックもインポートできないため、ファイルをモックする必要がある2つのテストでモックを複製する必要があり、テストスイートの脆弱性が増します。 これに対処することを検討していますか？ FBはこれを使用しますか？ はいの場合、どのように？ 😞

これらの警告を見るのは非常にイライラします。 修正を待つことはできません。

私が抱えている問題は関連していると思います：

jest.mock（ 'src / utils / history'）がある場合、 'history'node_moduleも誤ってモックします。

https://github.com/cwmoo740/jest-manual-mocks-node-modules

みんな更新はありますか？

@masoudcsこれは警告を取り除いたと思います：

package.json

"jest": {
  /* other settings ... */
  "modulePathIgnorePatterns": ["<rootDir>/node_modules/react-native/Libraries/Core/__mocks__"]
}

modulePathIgnorePatterns配列に「duplicate」フォルダを追加すると、警告が消えます

ありがとう@brunolm

だからそれはただの警告ですよね？！
これが何か悪いことが起こらないようにしたいだけです。つまり、複数のディレクトリでindex.jsをモックします。
src/app/modules/module1/__mocks__/index.jsおよびsrc/app/modules/module2/__mocks__/index.js

それが重要かどうかはわかりませんが、私が実行しているとき、それは他のものだけを選ぶと言っていました、そして私がリストしたこれはどちらの方法でも無視されます。

ですから、無視するように言ってもいいと思います。とにかく使っていませんでした。

はい、あなたが言ったように、私たちは今まで何の問題にも直面していませんでした。
うまくいけば、それはそれがしなければならないことをやっています！ :)
ありがとう

この最後の2つのコミットが示唆することを試しましたが、警告は削除されませんでした。

jest.mock('dir/index', () => require('dir/__mocks_/index'));

構成にtestPathIgnorePatterns: ['/_book/', ...otherStuff]があるのに、GitBook（ ./_bookディレクトリ）を使用しているため、この警告が表示されます。 この問題をざっと見てみると、明確な回避策は見当たりません。 警告が表示されないようにしたいだけです。助けていただければ幸いです。

+1

これに関する更新はありますか？

また、上記で提案されたより汚い方法を使用するのではなく、定期的にテストファイルをインポートできるようにするための修正を探しています。

jest.mock('models/index', () => require('models/index/_mocks_/index'));

ディレクトリ構造は、ここで参照されている@dkundelと同じように見えますhttps://github.com/facebook/jest/issues/2070#issuecomment -301332202モデルとコンポーネントは独自の名前空間にあり、デフォルトはindex.jsです。書き出す。

警告を消音したり、すべてのモックをフラットディレクトリにスローしたりしないことをお勧めします。 一部のモックは深くネストされており、提案された回避策は次のようになります。
jest.mock('pages/index/components/Component', () => require('pages/index/components/Component/_mocks_/index'));
私たちの構造で。

何か言葉は？

@karomancer構成を使用して警告を削除できるPR＃6037を送信しました。 現在のところ、統合されていません。 寄稿者からの返信をお待ちしております。

この問題は非常に苛立たしいものですが、よりクリーンな命名規則をもたらす優れた回避策を見つけたと思います。

package.json

{
  "jest": {
    "setupFiles": [
      "<rootDir>/test.mocks.ts"
    ]
  }
}

/* test.mocks.ts */

// modules mocked before every test
// use `jest.unmock(...)` to undo for any single test case
const mockedModules = [
    "./path/to/module1/index.ts",
    "./path/to/module2/index.ts",
];

mockedModules.forEach((path) => {
    const mockPath = path.replace(/\.ts$/g, ".mock.ts");
    jest.mock(path, () => require(mockPath));
});

これにより、兄弟anything.mock.tsを作成し、トップレベルのtest.mocksのmockedModules配列に元のパスを追加することで、 anything.tsをモックすることができます。

この問題が拡張としてタグ付けされているのはなぜですか？

これは私にとってはうまくいくようです。 jest.config.js内：

module.exports = {
  // ...
  modulePathIgnorePatterns: ["<rootDir>/.*/__mocks__"]
};

私は小さなプロジェクトを持っているので、この変更の範囲や影響についてはよくわかりません。

@amccloudありがとう！ これで私の問題は解決しました！ 詳細は以下をご覧ください。

プロジェクトのルートディレクトリにモジュールhelpersがあります。 ヘルパーは関数parseNodeFromStringエクスポートしています。
他のモジュールローカルファイルhelpers作成しました。 それから私は私のテストの1つのためにそれをあざけりました。 そして、関数parseNodeFromStringを使用するすべてのテストは、次のエラーで失敗し始めました。

FAIL  src/some_dir/bla/tests/SomeClass.test.js
  ● Test suite failed to run

    TypeError: (0 , _helpers.parseNodeFromString) is not a function

この問題はどうですか？ @amccloudソリューションは正しいよう

modulePathIgnorePatterns: ["<rootDir>/.*/__mocks__"]

このソリューションは機能しますが、ノードモジュールのトップレベルのモックが失敗しました。 そこで、ルート__mock__フォルダーを"modulePathIgnorePatterns": ["<rootDir>/src/react/.*/__mocks__"],無視しないように変更しました。 それでも、モックがルートからのフルパスに基づいて一意であるだけではないことは非常に奇妙です。 users/helper.js ＆ posts/helper.jsがあるのはかなり一般的です。 警告にはかなりのスペースが必要であり、実際の警告を完全に非表示にしたくありません。

では、PRの現状はどうなっているのでしょうか。 適切な解決策やハックはありますか？

私の場合、モックモジュールはビルドごとにDistdirにコピーされました。

これは、typescriptがより深いdir構造に属するパス/パターンを除外できないという問題のようです。 それはまだ「typescript@^3.4.5」の問題です。

これを修正するために、すべてのテストを実行する前に、「rimrafdist」を使用してDistディレクトリのクリーニングを開始しました。

"test:unit": "npm run clean && stencil test --spec --snapshot",

私はそのハックを知っていますが、機能します。

ねえ、私はこれをここで解決しました、そして多分それはあなたがこれを複製するのを助けることができます。

3つのソリューションまたはシナリオ：

1、テキストエディターでアプリを2回編集していました。つまり、2つの異なるウィンドウからポッドのインストール/更新とreact-nativerun-iosを実行していました。 このエラーが発生しました。Xcodeとアプリで重複フ​​ァイルを検索しようとしましたが、見つかりませんでした。 だから私は単にシミュレーターからアプリを削除し、react-native run-iosを再実行しました、そしてそれは機能しました、2つのnode_modulesがそのように複製されたことがわかりました：私のscrファイルのnode_modulesとnode_modules0。

2、Macでランダムキーを押すと、たとえばSRCフォルダーにnode_modulesが複製されることがあるので、これも当てはまります。したがって、node_modulesの重複がないかフォルダーを確認するのは理にかなっています。

3、同じシミュレーターで別のアプリを起動して終了し、複製を使用してアプリを再起動するまでアプリを起動できませんでした。その後、エラーなしで起動しました。

まだ何もありませんか？ CRAでmodulePathIgnorePatternsを使用できません

3年10ヶ月

または、警告だけでなく、この問題が発生したときにJestにエラーをスローさせることができれば便利です。 警告は簡単に無視されます。 私のプロジェクトでは、エラーがスローされることを望んでいるので、それを導入した開発者はそれに対処する必要があります。