Jest: [bug] simulação manual duplicada encontrada em diretórios separados

+1

No meu caso, depois de limpar cacheDirectory / var / folders / dm / vt920lmd6tzdq_709zkykwx40000gn / T / jest e reinstalar as dependências npm, essas mensagens desapareceram.

Este é o código ofensivo:

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

Mas parece que o comportamento pode ser explicitamente desejado, pois há um teste que o confirma:

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

Que foi adicionado em:

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

Eu me pergunto por que estamos usando basename vez de todo o caminho como chave?

/ cc @flarnie

Isso significa que basename s para módulos precisam ser globalmente exclusivos em um projeto ao usar simulações manuais. Para meu caso de uso, significa que não posso fazer algo como:

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

e usar simulações manuais ao mesmo tempo. Jest atualmente verá os dois zombando de schema e reclamarão.

Embora a solução alternativa seja trivial (s / schema / MyWhateverSchema /), parece um bug para renomear e reestruturar o código que não é de teste para deixar a piada feliz 🐞.

Sim, isso é realmente uma merda. O sistema de mocking manual realmente não é bom e estou feliz em aceitar PRs que irão melhorar a situação, assumindo que podemos ter certeza de que não quebraremos todo o FB (mas eu posso cuidar disso :))

Legal. Eu posso encontrar algum tempo amanhã para preparar um patch, mas sem promessas embora 😅

@cpojer existe um motivo específico para esse comportamento ?

Isso poderia ter algo a ver com o fato de que o fb usa nomes de arquivos exclusivos para módulos? Não vejo de outra forma como não permitir dois mocks com o mesmo nome faz algum sentido ...

Sim, os mocks também são "globais". Este é um design terrível com o qual temos que conviver, infelizmente. No FB, temos mais de 4000 arquivos fictícios no local errado (e muitas vezes não há nem um local adequado). É provável que consertemos isso no início da próxima metade, então isso deve melhorar em Jest. Estou feliz em apoiar PRs que melhoram o comportamento de Jest para código aberto - se pudermos manter o antigo comportamento de Jest no FB por enquanto.

@cpojer que tal uma bandeira? Você aceitaria um pr que habilita / desabilita isso com um sinalizador?

Sim, deve ser uma opção de configuração. Mas não estou falando apenas do aviso, estou falando também do recurso em geral.

@cpojer certo - quais partes da brincadeira isso

O código de resolução é chamado de jest-runtime: https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js e está em algum lugar entre jest-resolve e jest-resolve-dependencies .

@cpojer, obrigado pelas dicas: +1:

@cpojer que tal alguma substituição global, como JEST_USE_BASENAME_FOR_CACHING , para mudar este comportamento?

Pelo menos, podemos desfrutar de nomes de arquivo não exclusivos e não vai quebrar nada no FB.

Claro, é uma solução temporária.

Quer dizer, isso está em algum /etc/profile ou ~/.bashrc

export JEST_USE_BASENAME_FOR_CACHING="true"

(ou algum arquivo com env)
e depois

$ jest

ou este, sem modificações no arquivo env:

$ JEST_USE_BASENAME_FOR_CACHING="true" jest

O que você acha? É uma espécie de hack ou está tudo bem? :piscadela:

Acabei de tentar com um novo repo , usando duas versões de jest ( ^15.0.0 e ^17.0.0 ) e, embora o último dê o aviso, o teste se comporta conforme o esperado.

@ColCh Não acho que o problema aqui seja com o cache, provavelmente um nome mais adequado seria JEST_USE_BASENAME_FOR_MOCKING .

@cpojer se o código FB tem restrição sobre a unicidade dos nomes, usar o caminho completo como chave para o mapa de mocks não deve trazer problemas.

Estou certo ou há algo que não estou vendo?

As duas soluções que vejo são:

• modifique getMockName para acomodar a opção de usar o nome de base ou o caminho completo
• remova essa função completamente

seria bom ver a resposta de @cpojer sobre isso

Olá a todos, desculpe pela demora, estou bastante sobrecarregado com uma tonelada de coisas agora.

Acho que estou bem se vocês decidirem fazer qualquer mudança significativa em Jest que seja necessária para melhorar este sistema. Simulação manual é realmente confusa e não funciona bem. Uma coisa que queremos fazer é limitar o escopo dos "módulos haste" (sistema de módulo FB interno) usando uma opção de configuração, como "haste_modules": ['path/a', 'path/b']" e, em seguida, olhar apenas os módulos aceleração nessas pastas, incluindo esta simulação estranha comportamento. Se alguém quiser fazer essa mudança, seria incrível.

Uma coisa a ser descoberta então, é o seguinte: Se todos os simuladores manuais são locais, como __mocks__/a.js mapeia para a.js , o que fazemos com os simuladores node_module? Para isso, existem algumas maneiras:

• Apresente uma nova pasta __node_modules_mocks__ mas ela é feia.
• A pasta __mocks__ nível superior, vista de rootDir (raiz do projeto), pode atuar como uma pasta global.

Então, para resumir:

• Vamos corrigir simulações manuais no Jest!
• Vamos atribuir nomes aos módulos de velocidade e limitá-los a certas pastas / regex qualquer.
• Certifique-se de que o comportamento de simulação atual ainda funcione para o FB, mesmo que isso signifique que temos que colocar certas pastas na lista de permissões para acelerar o trabalho (seria apenas ["<rootDir>"] para nós por enquanto, eu acho)
• Descubra como ainda ser capaz de simular módulos de nó.

O que você acha?

Em ordem:

• Vamos corrigir simulações manuais no Jest!

HURRAY: smile:: tada:

• Vamos atribuir nomes aos módulos de velocidade e limitá-los a certas pastas / regex qualquer.
• Certifique-se de que o comportamento de simulação atual ainda funcione para o FB, mesmo que isso signifique que tenhamos que colocar certas pastas na lista de permissões para acelerar o trabalho (seria apenas semelhante a [""] para nós por enquanto, eu acho)

Não tenho certeza se entendi as necessidades com pressa.
O que você quer dizer é dar a possibilidade de dizer "esses módulos são módulos acelerados"?
Se tivermos quatro módulos: /path_1/a , /path_1/b , /path_2/a , /path_2/c , e a configuração é

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

apenas /path_1/a e /path_1/b são restritos a existir apenas em /path_1 , então /path_2/c é válido e /path_2/a gera um erro / aviso.

Eu diria que os alvos podem facilmente ser arquivos específicos e diretórios inteiros, mesmo com * simples / duplos.

• Descubra como ainda ser capaz de simular módulos de nó.

Eu manteria o comportamento atual :

Se o módulo que você está simulando é um módulo de nó (por exemplo: fs), o modelo deve ser colocado no mesmo diretório pai da pasta node_modules.

Meus pensamentos:

módulos de pressa:

Eu acho que haste_modules é bom, ele se encaixa exatamente como collectCoverageFrom e outras opções: array de globs
No caso, se você tiver todos os src como módulos _haste_ e apenas um diretório não for precipitado:

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

node_modules

@EnoahNetzach e se alguém tiver os mesmos nomes para o módulo de aplicativo e o módulo de node_modules?

Para fazer funcionar sem pressa ... hm, acho que pode ser descrito como:

dado módulo de nó project/node_modules/react , a simulação estará dentro de project/__node_modules_mocks__/react.js
se você tiver um arquivo project/react.js , use project/__mocks__/react.js

(claro, react.js é um exemplo. Aqui pode ser qualquer nome de arquivo entre todos os módulos, que podem ser instalados a partir do npm )

Realmente, mocking node_modules module é um caso raro pela minha experiência, então ... pode ser _rareness_ pode compensar _ugliness_ no caso particular de mocking node_modules ?

Alguém está zombando de módulos dentro de node_modules frequentemente?

que tal pensar mais

como eu percebi, para projetos reagentes nativos , muitas vezes temos que simular application modules e deixar os módulos de node_modules desbloqueados (por exemplo, lodash )

isso significa que temos:

• componente mock criado manualmente para cada componente burro (componentes burros são componentes de layout)
• uma longa lista de jest.mock chamadas em cada arquivo de teste

__o que eu quero dizer__: seria muito bom ter a habilidade de _auto mock_ módulos em alguns caminhos.

Ele pode ser implementado em torno de uma estrutura de dados conhecida, array-of-jest-globs, na configuração e módulos de filtragem sobre ela.

Vou descrever isso passo a passo

Dada esta entrada de configuração

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

e este código em src/screens/app.js :

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

// blah blah AppScreen implementation skipped

e este código de teste para tela em src/screens/__tests__/app-test.js :

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

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

Chegamos a esta situação, no contexto de app-test.js :

• AppScreen não é ridicularizado
• lodash não é ridicularizado
• Button , que é exigido por AppScreen , é simulado

... Você pode responder, como vai jogar com a entrada de configuração automock ?

simplesmente dizendo, automock: true é equivalente a:

"autoMockingPaths": [
  "<rootDir>"
]

zombaria automática ... espere!

pode ser apenas introduzir um valor especial para automock ? pelo menos não vai quebrar as configurações das pessoas

por exemplo, com esta entrada de configuração:

automock: "app"

jest irá simular automaticamente todos os módulos do aplicativo e deixar as versões atuais para os módulos de node_modules

o que você acha sobre o bloqueio automático dos módulos no nível do aplicativo, @cpojer ? Acho muito eficiente para o meu caso particular.

Eu concordo totalmente com "haste_modules" .

Nós, pessoalmente, não usamos muito o automocking, então não posso dizer o que é melhor, meu palpite é que "autoMockingPaths" var pode ser útil e elástico o suficiente.
Pelo contrário, acho "automock": "app" muito rígido ( jest já desabilitou o bloqueio automático por padrão).

O __node_modules_mocks__ poderia ser uma opção, concordo que a raridade compensa a feiura (no meu caso particular, raramente zombamos de node_modules e, quando temos que fazer isso, usamos jest.mock(...) ).
A única ressalva é: o que acontece quando você tem uma pasta node_modules aninhada (por exemplo, src/node_modules ), você tem que simular seus módulos do global __node_modules_mocks__ , uma versão aninhada de ou normalmente com __mocks__ co-localizado?

pode ser apenas jogado, se alguém tiver o mesmo nome de módulo em node_modules e app modules

por exemplo

app/express.js como módulo de aplicativo (talvez eu esteja fazendo um jogo de trem)
e app/node_modules/express como servidor web de npm
throw new Error("can't mock express.js file - it duplicates one from node_modules")

neste caso, __mocks__ pode ser usado para node_modules , mas dev tem que renomear seus próprios módulos em tais colisões

nah ... isso é mais feio do que __node_modules_mocks__ , não é?

O que eu quis dizer é: e se você tiver um módulo npm install ed x e mais tarde, mais profundamente em sua base de código, defina um módulo x em uma pasta node_modules aninhada ?

A colisão de nomenclatura geralmente é tratada no nó, preferindo-se o mais próximo, mas não sei como isso funciona com pressa.

Estou mencionando isso porque projetos como o Create React App estão usando, ou o farão em um futuro próximo.

Em uma nota lateral, @cpojer é esse problema de alguma forma relacionado?

Vamos nos concentrar em mudar a forma como a pressa funciona (whitelist / blacklist em vez de por padrão). Acho que preferiria manter que <rootDir>/__mocks__ deve ser o padrão para simulações de módulo de nó. Poderíamos tornar esta uma opção de configuração também: "globalMocks" cujo padrão é <rootDir>/__mocks__ . Alguém está disposto a trabalhar nisso?

Devo ser capaz de trabalhar nisso antes do próximo fim de semana.

Eu posso trabalhar na RP neste domingo, estou meio livre

@cpojer apenas para recapitular - crie globalMocks config entrada com valor padrão de <rootDir>/__mocks__ . Esta opção regula o uso de node-haste em jest especificando o caminho? Ou será uma série de caminhos?

Acho que essas são algumas mudanças maiores no caminho para resolver isso, mas acho que precisamos da opção globalMocks singular (pode ser uma string ou matriz de strings) e da opção hasteModules que seria uma matriz de caminhos de módulos de haste. A maior parte desse código reside em jest-haste-map e jest-resolve. Ainda não tenho 100% de certeza de como será a solução certa.

De: Max Sysoev [email protected]
Enviado: sexta-feira, 9 de dezembro de 2016 às 8:18:44
Para: facebook / jest
Cc: Christoph Pojer; Menção
Assunto: Re: [facebook / jest] [bug] simulação manual duplicada encontrada em diretórios separados (# 2070)

Eu posso trabalhar na RP neste domingo, estou meio livre

@cpojer https://github.com/cpojer apenas para recapitular - crie uma entrada de configuração globalMocks com valor padrão de/ __ mocks__. Esta opção regula o uso de node-haste dentro de jest especificando o caminho? Ou será uma série de caminhos?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/facebook/jest/issues/2070#issuecomment-265958606 ou desative o tópico https://github.com/notifications/unsubscribe-auth/AAA0KAMFc34iKqBDLHZzgaWGHqyc3WkAzks5rGtGt7 .

Desculpe, minha estação de trabalho quebrou e aparentemente não há como fazê-la funcionar em alguns meses (1-2 meses). Eu até perdi meu projeto neste PR :( Então, desculpe por assumir responsabilidades.

Que tal apenas uma opção de configuração para alterar o comportamento de getMockName ?

Não estou muito familiarizado com os detalhes internos da piada, mas parece que essa é a solução mais simples para corrigir o problema sem quebrar a piada para o FB.

Isso vai ser mais complicado do que eu pensava originalmente. Para mim, os simuladores manuais devem substituir o arquivo que estão mais próximos também, ou seja, algo assim:

{ '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') deve resolver para /Users/project/__mocks__/aws-sdk.js esta é uma simulação para node_module .

require('./db') (ou qualquer caminho para db ) deve resolver para: /Users/project/db/__mocks__/index.js .

Meu entendimento sobre como configurar simulações manuais de jest (e provavelmente deve haver mais documentação se algo como o acima for usado) é que eles devem estar o mais próximo possível do arquivo que está sendo simulado dentro de um diretório __mocks__ .

Simulações manuais são definidas escrevendo um módulo em um subdiretório __mocks __ / imediatamente adjacente ao módulo. (https://facebook.github.io/jest/docs/manual-mocks.html)

Considerando isso, o comportamento acima faz mais sentido para mim.

Pensamentos?

Esta é uma passagem inicial para implementar algo como o acima: https://github.com/facebook/jest/compare/master...mhahn : issue-2070-new-mock-resolution

Ele quebra a maioria dos testes de unidade de jest porque não permite mais simulações puras "nomeadas" como o seguinte: https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/__mocks__/ createRuntime.js

IMO, algo como createRuntime é um utilitário de teste que deve estar em uma pasta de utils de teste e importado nos testes que precisam dele. A maneira como é implementado como uma simulação manual realmente não faz sentido para mim como algo que deve ser preservado.

Uma opção é adicionar uma variável de configuração que alternará entre o comportamento existente e a versão limpa das alterações acima. Não tenho certeza de como isso deve ser chamado.

Não podemos quebrar o comportamento atual, pois contamos com ele extremamente no Facebook.

@cpojer eu concordo. Eu realmente não entendi esse comentário depois de ler o código: https://github.com/facebook/jest/issues/2070#issuecomment -265027510. talvez pudéssemos oferecer suporte a whitelisting uma lista de diretórios que resolverá o comportamento atual?

que tal duas novas opções de configuração:

• fullPathMockResolution (padronizado para false para manter o comportamento existente)
  acompanhado de:
• namedMockDirectories : se fullPathMockResolution estiver habilitado, quaisquer diretórios dentro desse array serão resolvidos com o comportamento existente. Para o caso de uso do FB, seria apenas [<rootDir>] como você mencionou acima.

Isso permite que os desenvolvedores optem pela resolução de caminho completo, de forma que não exija alterações por instalações de jest existentes e também ativa o comportamento existente para diretórios específicos, se assim o desejarem.

cc @voideanvalue isso pode ser algo em que você terá que pensar (simulações manuais de namespace como parte da nova implementação de pressa).

+1, existe uma maneira de consertar isso?

+1

Alguma atualização sobre como corrigir esse problema? Isso acaba sendo muito doloroso se você seguir uma estrutura como esta:

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

No momento, tenho que simular manualmente um módulo no teste se estou usando dois com um nome 'conflitante', embora na verdade eles não tenham nomes conflitantes, pois o caminho deve ser considerado.

Felicidades,
Dominik

@cpojer Alguma atualização aqui, pessoal? Existe uma solução alternativa?

Uma pequena solução para mim é simular os módulos com require

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

Renomei o nome da pasta __mocks__ para _mocks_ para que o jest não pegue os arquivos.

Um dia, quando isso funcionar, vou renomear _mocks_ para __mocks__ e remover a parte necessária de jest.mock

Em primeiro lugar: Obrigado por todo o trabalho incrível.
Em segundo lugar: isso é realmente muito frustrante. Eu me vejo forçado a usar jest.mock no arquivo de teste quando o arquivo simulado compartilha um nome com qualquer outro arquivo em toda a base de código que também é simulado. O levantamento não permite que o mock real seja importado também, então força você a duplicar o mock em quaisquer dois testes que exijam que o arquivo seja simulado, aumentando a fragilidade do conjunto de testes. Estamos tentando resolver isso? O FB usa essas coisas? Se sim, como? 😞

1 muito frustrante ver esses avisos. Não posso esperar por uma correção.

Acho que o problema que estou tendo está relacionado:

se eu tiver um jest.mock ('src / utils / history'), ele também zomba incorretamente do node_module 'histórico'.

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

Galera alguma atualização?

@masoudcs Acho que isso

package.json

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

Adicione as pastas "duplicadas" no array modulePathIgnorePatterns e o aviso desaparecerá

Obrigado @brunolm

Então é só um aviso, correto ?!
Só quero ter certeza de que isso não fará com que algo ruim aconteça, ou seja, simular index.js em vários diretórios:
src/app/modules/module1/__mocks__/index.js e src/app/modules/module2/__mocks__/index.js

Não sei se isso importa, mas quando eu estava executando estava dizendo que escolheria apenas o outro e este que eu listei seria ignorado de qualquer maneira.

Então eu acho que é bom dizer para ignorar, não estava usando de qualquer maneira.

Sim, como você disse, e não enfrentamos nenhum problema até agora.
Esperançosamente, está fazendo o que tem que fazer! :)
obrigado

Eu tentei o que estes dois últimos commits sugeriam, mas não removi o aviso.

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

Estou vendo este aviso porque uso GitBook (diretório ./_book ), embora tenha testPathIgnorePatterns: ['/_book/', ...otherStuff] em minha configuração. Examinando este problema, não vejo uma solução alternativa clara. Eu só quero parar de ver os avisos - qualquer ajuda seria apreciada.

+1

alguma atualização disso?

Ainda estou procurando uma correção para que meus arquivos de teste possam ser importados de forma regular, não usando a forma mais suja que foi sugerida acima.

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

Nossa estrutura de diretório parece a mesma que @dkundel referenciada aqui https://github.com/facebook/jest/issues/2070#issuecomment -301332202 com modelos e componentes em seus próprios namespaces com index.js sendo o padrão exportar.

Prefere não silenciar os avisos ou jogar todas as simulações em um diretório simples. Alguns de nossos mocks estão profundamente aninhados, e a solução alternativa sugerida provavelmente se pareceria com
jest.mock('pages/index/components/Component', () => require('pages/index/components/Component/_mocks_/index'));
em nossa estrutura.

Qualquer palavra?

@karomancer Enviei o PR # 6037 que permitirá que você use uma configuração para remover os avisos. Até o momento, ele não foi mesclado; Estou esperando uma resposta dos colaboradores.

Esse problema é super frustrante, mas acho que encontrei uma boa solução alternativa que resulta em uma convenção de nomenclatura mais limpa.

Em 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));
});

Isso permitirá que você zombe de anything.ts criando um irmão anything.mock.ts e adicionando o caminho para o original na matriz test.mocks de nível superior mockedModules .

Por que esse problema foi marcado como aprimoramento?

Isso parece funcionar para mim. em jest.config.js:

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

Não tenho certeza do escopo ou impacto dessa mudança, porque tenho um pequeno projeto.

@amccloud obrigado! Isso resolveu meu problema! Detalhes abaixo.

Eu tenho um módulo helpers no diretório raiz do meu projeto. O auxiliar está exportando a função parseNodeFromString .
Eu criei em algum outro arquivo local do módulo helpers . Então eu zombei dele para um dos meus testes. E todos os testes que usam a função parseNodeFromString começaram a falhar com o seguinte erro:

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

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

E quanto a esse problema? Parece que a solução @amccloud está correta.

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

Esta solução funciona, embora tenha feito minhas simulações de nível superior para módulos de nó falharem. Então eu mudei para não ignorar minha pasta raiz __mock__ com: "modulePathIgnorePatterns": ["<rootDir>/src/react/.*/__mocks__"], . Ainda assim, é bastante estranho que os mocks não sejam apenas únicos com base no caminho completo desde a raiz. É muito comum ter: users/helper.js & posts/helper.js . O aviso ocupa algum espaço e não quero ocultar completamente os avisos reais.

Então, qual é a situação atual do RP? Existe alguma solução adequada ou apenas alguns hacks?

No meu caso, o módulo mock foi copiado para Dist dir com cada build.

Parece que este é um problema com o texto datilografado incapaz de excluir caminhos / padrões que pertencem a uma estrutura dir mais profunda. Ainda é um problema com "typescript@^3.4.5".

Para corrigir isso, comecei a limpar meu Dist dir com "rimraf dist" antes de cada teste.

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

Eu sei que é um hack, mas funciona.

Ei, resolvi isso aqui é o que aconteceu, e talvez isso possa ajudá-lo a duplicar isso.

três soluções ou cenários:

1, eu estava editando meu aplicativo no meu editor de texto duas vezes, ou seja, estava executando pod install / update e react-native run-ios em duas janelas diferentes. e recebi este erro, tentei pesquisar os arquivos duplicados no Xcode e no meu aplicativo, mas não consegui encontrar nenhum. então eu simplesmente excluí o aplicativo do simulador e executei novamente o run-ios react-native e funcionou. Acontece que dois node_modules foram duplicados como tais: node_modules e node_modules0 em meu arquivo scr.

2, às vezes, quando pressiono teclas aleatórias no meu mac, os node_modules são duplicados, por exemplo, na pasta SRC, então esse também é o caso, então faz sentido dar uma olhada em suas pastas para ver se há duplicações de node_modules.

3, não consegui fazer meu aplicativo iniciar até que iniciei e encerrei um aplicativo diferente no mesmo simulador e reiniciei o aplicativo com a duplicação, que então foi iniciado sem erros.

Nada ainda? Não é possível usar modulePathIgnorePatterns no CRA

3 anos e 10 meses

Como alternativa, seria bom se pudéssemos forçar Jest a lançar um erro quando esse problema surgir, em vez de apenas advertir. Os avisos são facilmente ignorados; no meu projeto, prefiro que ocorra um erro, para que o desenvolvedor que o introduziu tenha que lidar com isso.