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 s для модулей должны быть глобально уникальными в проекте при использовании ручных макетов. В моем случае это означает, что я не могу делать что-то вроде:

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

и одновременно использовать ручные макеты. В настоящее время Jest увидит, что они оба насмехаются над schema и будет жаловаться.

Хотя обходной путь тривиален (s / schema / MyWhateverSchema /), переименование и реструктуризация не тестового кода, чтобы сделать шутку счастливой, кажется ошибкой.

Да, это действительно отстой. Система ручных издевательств действительно не годится, и я рад принять PR, которые улучшат ситуацию, при условии, что мы сможем убедиться, что мы не сломаем весь FB (но я могу об этом позаботиться :))

Круто. Завтра я найду время, чтобы приготовить патч, но никаких обещаний

@cpojer есть ли конкретная причина такого поведения ?

Может ли это иметь какое-то отношение к тому факту, что fb использует уникальные имена файлов для модулей? Я не вижу другого смысла в том, чтобы запретить использование двух моков с одним и тем же именем ...

Да, моки тоже «глобальны». Это ужасный дизайн, с которым, к сожалению, приходится жить. В FB у нас есть 4000+ фиктивных файлов в неправильном месте (а часто даже нет в правильном месте). Вероятно, мы исправим это в начале следующей половины, так что в Jest это должно улучшиться. Я счастлив поддерживать PR, которые улучшают поведение Jest для открытого исходного кода - если мы сможем пока сохранить старое поведение Jest в FB.

@cpojer как насчет флага? Вы бы приняли PR, который включает / отключает это с помощью флага?

Да, это должен быть вариант конфигурации. Но я говорю не только о предупреждении, я также говорю о функции в целом.

@cpojer right - каких частей шутки это касается?

Код разрешения вызывается из jest-runtime: https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js и находится где-то в jest-resolve и jest-resolve-dependencies .

@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

Что думаешь? Это что-то вроде хака или все нормально? : wink:

Я только что попробовал с новым репозиторием , используя две версии jest ( ^15.0.0 и ^17.0.0 ), и, хотя последний выдает предупреждение, тест ведет себя так, как ожидалось.

@ColCh Я не думаю, что проблема здесь в кэше, возможно, более подходящим именем могло бы быть JEST_USE_BASENAME_FOR_MOCKING .

@cpojer, если код FB имеет ограничение на уникальность имён, использование полного пути в качестве ключа для карты моков не должно вызывать проблем.

Я прав или чего-то не вижу?

Я вижу два решения:

• изменить getMockName чтобы можно было использовать базовое имя или полный путь
• полностью удалить эту функцию

было бы неплохо увидеть ответ @cpojer на это

Привет всем, извините за задержку, сейчас я неплохо подкреплен множеством вещей.

Думаю, я в порядке, если вы, ребята, решите внести в Jest все критические изменения, необходимые для улучшения этой системы. Ручной макет действительно запутан и не работает. Одна вещь, которую мы как бы хотим сделать, - это ограничить объем "модулей ускорения" (внутренняя система модулей FB) с помощью параметра конфигурации, например "haste_modules": ['path/a', 'path/b']" а затем смотреть только на модули ускорения в этих папках, включая этот странный издевательский поведение. Если кто-то захочет внести это изменение, это будет здорово.

Одна вещь, которую нужно выяснить, заключается в следующем: если все ручные макеты являются локальными, например, __mocks__/a.js сопоставляется с a.js , что нам делать с mocks node_module? Для этого есть несколько способов:

• Представьте новую папку __node_modules_mocks__ но это некрасиво.
• Папка верхнего уровня __mocks__ если смотреть из rootDir (корень проекта), может действовать как глобальная папка.

Итак, чтобы подвести итог:

• Исправим ручные моки в Jest!
• Давайте ускорим модули пространства имен и ограничим их определенными папками / регулярными выражениями.
• Убедитесь, что текущее насмешливое поведение по-прежнему работает для FB, даже если это означает, что мы должны внести определенные папки в белый список, чтобы ускорить работу (сейчас это будет выглядеть как ["<rootDir>"] , я думаю)
• Выясните, как можно по-прежнему имитировать модули узлов.

Что вы думаете?

В целях:

• Исправим ручные моки в Jest!

УРА: smile:: tada:

• Давайте ускорим модули пространства имен и ограничим их определенными папками / регулярными выражениями.
• Убедитесь, что текущее поведение насмешек по-прежнему работает для FB, даже если это означает, что мы должны внести определенные папки в белый список, чтобы ускорить работу (это будет просто выглядеть как [""] для нас пока, я думаю)

Я не уверен, что понимаю потребности поспешно.
Что вы имеете в виду, это дать возможность сказать «эти модули являются модулями ускорения»?
Если у нас есть четыре модуля: /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_, и только один каталог не спешит:

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 )

На самом деле, по моему опыту, mocking node_modules - редкий случай, так что ... может быть _rareness_ может компенсировать _ugliness_ в конкретном случае mocking node_modules ?

Кто- нибудь часто издевается над модулями внутри

что насчет того, чтобы думать дальше

как я заметил, для проектов, ориентированных на реакцию , нам часто приходится имитировать application modules и оставлять модули из node_modules разблокированными (например, lodash )

это означает, что у нас есть:

• вручную созданный макет компонента для каждого немого компонента (немой компонент - это компоненты макета)
• длинный список jest.mock call в каждом тестовом файле

__ что я хочу сказать__: было бы очень хорошо иметь возможность _автоматизировать_ модули на некоторых путях.

Он может быть реализован на основе хорошо известной структуры данных 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 config?

просто говоря, automock: true эквивалентно:

"autoMockingPaths": [
  "<rootDir>"
]

авто издевается ... погоди!

может быть просто ввести специальное значение для automock ? хоть конфиги людей не сломает

например, с этой записью конфигурации:

automock: "app"

jest автоматически смоделирует все модули приложения и оставит актуальные версии для модулей от node_modules

что вы думаете об автоматическом запуске модулей уровня приложения,

Я полностью согласен с "haste_modules" .

Мы лично не так часто используем автоматизацию, поэтому я не могу сказать, что лучше, я безумно догадываюсь, что "autoMockingPaths" var может быть полезным и достаточно гибким.
Напротив , я нашел "automock": "app" слишком жесткой (шутя уже отключил automocking по умолчанию).

__node_modules_mocks__ может быть вариантом, я согласен с тем, что редкость компенсирует уродство (в моем конкретном случае мы редко издеваемся над node_modules , а когда нам нужно это сделать, мы используем jest.mock(...) ).
Единственное предостережение: что происходит, когда у вас есть вложенная папка node_modules (например, src/node_modules ), вам нужно издеваться над ее модулями из глобального __node_modules_mocks__ , вложенной версии это, или обычно с __mocks__ совмещены?

может быть просто выброшено, если у кого-то одинаковое имя модуля в node_modules и app modules

например

app/express.js как модуль приложения (возможно, я занимаюсь обучением)
и app/node_modules/express качестве веб-сервера из npm
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 и более поздние версии, глубже в вашей кодовой базе определите модуль x во вложенной папке node_modules ?

Конфликт имен обычно обрабатывается в узле путем выбора ближайшего, но я не знаю, как это работает в спешке.

Я говорю об этом, потому что такие проекты, как Create React App , используют его или будут использовать в ближайшем будущем.

Кстати , проблемой ?

Давайте сосредоточимся на изменении того, как работает спешка (белый / черный список, а не по умолчанию). Я действительно думаю, что предпочел бы сохранить, что <rootDir>/__mocks__ должно быть значением по умолчанию для макетов модуля узла. Мы также можем сделать это параметром конфигурации: "globalMocks", который по умолчанию равен <rootDir>/__mocks__ . Кто-нибудь желает над этим работать?

Я смогу поработать над этим не раньше, чем в следующие выходные.

Я могу работать над пиаром в это воскресенье, я вроде как свободен

@cpojer просто напомним - создайте запись globalMocks config со значением по умолчанию <rootDir>/__mocks__ . Эта опция регулирует использование node-haste в шутке путем указания пути? Или это будет массив путей?

Я думаю, что это некоторые более крупные изменения на пути к разрешению этой проблемы, но я думаю, что нам нужна как единственная опция globalMocks (может быть строкой или массивом строк), так и опция hasteModules, которая будет массивом путей модулей ускорения. Большая часть этого кода живет в jest-haste-map и jest-resolve. Я еще не уверен на 100%, как будет выглядеть правильное решение.

От: Макс Сысоев [email protected]
Отправлено: пятница, 9 декабря 2016 г., 8:18:44
Кому: facebook / jest
Копия: Кристоф Пойер; Упоминание
Тема: Re: [facebook / jest] [ошибка] дубликат ручного макета найден в отдельных каталогах (# 2070)

Я могу работать над пиаром в это воскресенье, я вроде как свободен

@cpojer https://github.com/cpojer просто напомним - создайте запись конфигурации globalMocks со значением по умолчанию/ __ mocks__. Эта опция регулирует использование node-haste в шутке, указывая путь? Или это будет массив путей?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это электронное письмо напрямую, просмотрите его на GitHub https://github.com/facebook/jest/issues/2070#issuecomment-265958606 или отключите поток https://github.com/notifications/unsubscribe-auth/AAA0KAMFc34iKqBDLHZzgaGHqyc3JPGQA .

Извините, моя рабочая станция сломалась, и, по-видимому, невозможно заставить ее работать через пару месяцев (1-2 месяца). Я даже потерял свой проект на этом пиаре :( Так что извините за то, что взял на себя ответственность.

Как насчет просто опции конфигурации для изменения поведения getMockName ?

Не слишком знаком с внутренним устройством jest, но похоже, что это простейшее решение для решения проблемы без нарушения работы jest для FB.

Это будет сложнее, чем я думал изначально. На мой взгляд, ручные макеты также должны заменять ближайший к ним файл, т.е. что-то вроде этого:

{ '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 .

Насколько я понимаю, способ установки шутливых ручных макетов (и, вероятно, должно быть больше документации, если используется что-то подобное вышеупомянутому), заключалось в том, что они должны быть как можно ближе к макету файла в каталоге __mocks__ .

Ручные макеты определяются путем записи модуля в подкаталог __mocks __ /, непосредственно примыкающий к модулю. (https://facebook.github.io/jest/docs/manual-mocks.html)

Учитывая это, вышеупомянутое поведение имеет для меня наибольший смысл.

Мысли?

Это начальный этап реализации чего-то вроде приведенного выше: https://github.com/facebook/jest/compare/master...mhahn : issue-2070-new-mock-resolution

Он нарушает большинство юнит-тестов jest, поскольку больше не позволяет использовать чистые "именованные" имитации, подобные следующему: https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/__mocks__/ createRuntime.js

IMO, что-то вроде createRuntime - это тестовая утилита, которая должна быть в папке test utils и импортирована в тесты, которые в ней нуждаются. То, как это реализовано в виде ручного макета, не имеет для меня смысла как нечто, что следует сохранить.

Один из вариантов - добавить переменную конфигурации, которая будет переключаться между существующим поведением и очищенной версией описанных выше изменений. Я не совсем уверен, как это называть.

Мы не можем изменить нынешнее поведение, поскольку мы очень сильно полагаемся на него в Facebook.

@cpojer Я согласен. я действительно не понял этот комментарий после прочтения кода: https://github.com/facebook/jest/issues/2070#issuecomment -265027510. Может быть, мы могли бы поддержать внесение в белый список списка каталогов, которые будут соответствовать текущему поведению?

как насчет двух новых параметров конфигурации:

• fullPathMockResolution (по умолчанию false чтобы сохранить существующее поведение)
  в сочетании с:
• namedMockDirectories : если fullPathMockResolution включен, любые каталоги в этом массиве будут разрешены с существующим поведением. Для случая использования FB это будет просто [<rootDir>] как вы упомянули выше.

Это позволяет разработчикам выбирать полное разрешение пути, поэтому оно не требует изменений существующими установками jest, а также включает существующее поведение для определенных каталогов, если они этого хотят.

cc @voideanvalue, возможно, вам придется подумать об этом (ручные

+1, есть ли способ исправить это?

+1

Есть обновления о том, как решить эту проблему? Это окажется действительно болезненным, если вы будете следовать такой структуре:

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

Прямо сейчас мне нужно вручную имитировать модуль в тесте, если я использую два с «конфликтующими» именами, даже если у них на самом деле нет конфликтующих имен, поскольку следует учитывать путь.

Привет,
Доминик

@cpojer Здесь есть обновления, ребята? Есть ли обходной путь?

Небольшой обходной путь для меня - издеваться над модулями с помощью require

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

Я переименовал имя папки __mocks__ в _mocks_ чтобы шутка не перехватывала файлы.

Однажды, когда это сработает, я переименую _mocks_ в __mocks__ и удалю часть require из jest.mock.

Во-первых: спасибо за отличную работу.
Во-вторых: это действительно очень неприятно. Я вынужден использовать jest.mock в тестовом файле, когда имитируемый файл разделяет имя с любым другим файлом во всей кодовой базе, который также подвергается имитации. Подъем не позволяет импортировать и фактический макет, поэтому вынуждает дублировать макет в любых двух тестах, требующих фиксации этого файла, что увеличивает хрупкость набора тестов. Мы собираемся решить эту проблему? FB использует это? Если да, то как? 😞

+1 очень неприятно видеть эти предупреждения. Не могу дождаться исправления.

Я думаю, что проблема, с которой я столкнулся, связана:

если у меня есть jest.mock ('src / utils / history'), он также неправильно имитирует node_module 'history'.

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 и предупреждение исчезнет.

Спасибо @brunolm

Так это просто предупреждение, верно ?!
Я просто хочу убедиться, что это не вызовет чего-то плохого, например, насмешки над index.js в нескольких каталогах:
src/app/modules/module1/__mocks__/index.js и src/app/modules/module2/__mocks__/index.js

Я не знаю, имеет ли это значение, но когда я работал, он говорил, что выберет только другой, и то, что я перечислил, в любом случае будет проигнорировано.

Так что я думаю, что можно сказать, чтобы он игнорировал, он все равно не использовал его.

Да, как вы и сказали, и до сих пор мы не сталкивались с какими-либо проблемами.
Надеюсь, он делает то, что должен! :)
благодаря

Я попробовал то, что предлагали эти последние два коммита, но не удалил предупреждение.

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

Я вижу это предупреждение, потому что использую GitBook (каталог ./_book ), хотя в моей конфигурации есть testPathIgnorePatterns: ['/_book/', ...otherStuff] . Просматривая эту проблему, я не вижу четкого решения. Я просто хочу перестать видеть предупреждения - любая помощь приветствуется.

+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.ts , создав родственника anything.mock.ts и добавив путь к оригиналу в массиве mockedModules верхнего уровня test.mocks .

Почему эта проблема отмечена как улучшение?

Мне кажется, это работает. в jest.config.js:

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

Я не уверен в масштабах или влиянии этого изменения, потому что у меня небольшой проект.

@amccloud спасибо! Это решило мою проблему! Подробности ниже.

У меня есть модуль helpers в корневом каталоге моего проекта. Помощник экспортирует функцию parseNodeFromString .
Я создал в каком-то другом модуле локальный файл helpers . Затем я поиздевался над этим для одного из своих тестов. И все тесты с использованием функции 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__"], . Тем не менее, довольно странно, что mock-объекты уникальны не только на основе полного пути от корня. Довольно часто встречается: users/helper.js & posts/helper.js . Предупреждение занимает довольно много места, и я не хочу полностью скрывать настоящие предупреждения.

Так каков текущий статус PR? Есть какое-то правильное решение или просто какие-то хаки?

В моем случае макет модуля копировался в каталог Dist при каждой сборке.

Похоже, это проблема из-за того, что машинописный текст не может исключить пути / шаблоны, принадлежащие более глубокой структуре каталога. Это все еще проблема с "typescript@^3.4.5".

Чтобы исправить это, я начал чистить каталог Dist с помощью "rimraf dist" перед каждым тестовым запуском.

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

Я знаю, что это взлом, но работает.

Эй, я решил, что вот что произошло, и, возможно, это поможет вам продублировать это.

три решения или сценария:

1, я дважды редактировал свое приложение в текстовом редакторе, что означает, что я запускал установку / обновление модуля и выполнял запуск ios с собственной реакцией из двух разных окон. и я получил эту ошибку, я попытался найти повторяющиеся файлы в Xcode и в моем приложении, но не смог их найти. поэтому я просто удалил приложение из симулятора и повторно запустил run-ios с поддержкой реакции, и это сработало. Оказалось, что два node_modules были дублированы как таковые: node_modules и node_modules0 в моем файле scr.

2, иногда, когда я нажимаю случайные клавиши на своем Mac, node_modules дублируются, например, в папке SRC, так что это также имеет место, поэтому имеет смысл взглянуть на ваши папки на предмет любых дубликатов node_modules.

3, я не мог запустить свое приложение до тех пор, пока я не запустил и не завершил работу другого приложения на том же симуляторе, а затем перезагрузил приложение с дублированием, которое затем запустилось без каких-либо ошибок.

Еще ничего? Не могу использовать modulePathIgnorePatterns в CRA

3 года и 10 месяцев

В качестве альтернативы было бы неплохо, если бы мы могли заставить Jest выдавать ошибку, когда возникает эта проблема, а не просто предупреждение. Предупреждения легко игнорировать; в моем проекте я бы предпочел, чтобы возникла ошибка, поэтому разработчик, который ее представил, должен с ней справиться.