Jest: [error] se ha encontrado una simulación manual duplicada en directorios separados

+1

En mi caso, después de borrar las dependencias cacheDirectory / var / folders / dm / vt920lmd6tzdq_709zkykwx40000gn / T / jest y reinstalar las dependencias npm, estos mensajes han desaparecido.

Aquí está el código ofensivo:

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

Pero parece que el comportamiento podría ser explícitamente deseado ya que hay una prueba que lo confirma:

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

Que fue agregado en:

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

Me pregunto por qué estamos usando basename lugar de la ruta completa como clave.

/ cc @flarnie

Esto significa que basename s para módulos deben ser globalmente únicos en un proyecto cuando se utilizan simulaciones manuales. Para mi caso de uso, significa que no puedo hacer algo como:

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

y usar simulacros manuales al mismo tiempo. Jest actualmente los verá a ambos burlándose de schema y quejándose.

Aunque la solución es trivial (s / schema / MyWhateverSchema /), se siente como un error cambiar el nombre y reestructurar el código que no es de prueba para hacer feliz a broma 🐞.

Sí, esto es una mierda. El sistema de burla manual no es realmente bueno y estoy feliz de aceptar relaciones públicas que mejorarán la situación, asumiendo que podamos asegurarnos de no romper todo FB (pero puedo encargarme de eso :)

Frio. Podría encontrar algo de tiempo mañana para cocinar un parche, pero sin promesas 😅

@cpojer ¿hay alguna razón en particular para este comportamiento ?

¿Podría tener algo que ver con el hecho de que fb usa nombres de archivo únicos para los módulos? No veo de otra manera cómo no permitir dos simulacros con el mismo nombre tiene sentido ...

Sí, los simulacros también son "globales". Este es un diseño terrible con el que tenemos que vivir, desafortunadamente. En FB tenemos más de 4000 archivos simulados en la ubicación incorrecta (y a menudo ni siquiera hay una ubicación adecuada). Es probable que arreglemos esto a principios de la próxima mitad, por lo que debería mejorar en Jest. Me complace apoyar a las relaciones públicas que mejoran el comportamiento en Jest para el código abierto, si podemos mantener el antiguo comportamiento de Jest en FB por ahora.

@cpojer ¿qué tal una bandera? ¿Aceptarías un pr que habilita / deshabilita esto con una bandera?

Sí, debería ser una opción de configuración. Pero no me refiero solo a la advertencia, también me refiero a la función en general.

@cpojer , ¿qué partes de la broma toca esto?

El código de resolución se llama desde jest-runtime: https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js y está en algún lugar de jest-resolve y jest-resolve-dependencies .

@cpojer gracias por los consejos: +1:

@cpojer ¿qué pasa con una anulación global, como JEST_USE_BASENAME_FOR_CACHING , para cambiar este comportamiento?

Al menos, podemos disfrutar de nombres de archivo no únicos y no romperá nada en FB.

Por supuesto, es una solución temporal.

Quiero decir, esto es en algunos /etc/profile o ~/.bashrc

export JEST_USE_BASENAME_FOR_CACHING="true"

(o algún archivo con env)
y entonces

$ jest

o este, sin modificaciones del archivo env:

$ JEST_USE_BASENAME_FOR_CACHING="true" jest

¿Qué piensas? ¿Es una especie de truco o está bien? :guiño:

Intenté con un nuevo repositorio , usando dos versiones de jest ( ^15.0.0 y ^17.0.0 ) y, aunque este último da la advertencia, la prueba se comporta como se esperaba.

@ColCh No creo que el problema aquí sea con el caché, probablemente un nombre más adecuado podría ser JEST_USE_BASENAME_FOR_MOCKING .

@cpojer si el código FB tiene la restricción sobre la unicidad de los nombres, usar la ruta completa como clave para el mapa de simulacros no debería traer problemas.

¿Estoy en lo cierto o hay algo que no veo?

Las dos soluciones que veo son:

• modificar getMockName para acomodar la opción de usar el nombre base o la ruta completa
• eliminar esa función por completo

Sería bueno ver que @cpojer respondiera

Hola a todos, perdón por la demora, estoy bastante atascado con un montón de cosas en este momento.

Creo que estoy bien si ustedes deciden hacer cualquier cambio importante en Jest que sea necesario para mejorar este sistema. La burla manual es realmente un desastre y no funciona bien. Una cosa que queremos hacer es limitar el alcance de los "módulos de prisa" (sistema de módulo interno de FB) usando una opción de configuración, como "haste_modules": ['path/a', 'path/b']" y luego solo mirar los módulos de prisa en esas carpetas, incluida esta extraña burla comportamiento. Si alguien quiere hacer este cambio, sería asombroso.

Una cosa que hay que averiguar entonces es la siguiente: si todas las simulaciones manuales son locales, como __mocks__/a.js mapas a a.js , ¿qué hacemos con las simulaciones de node_module? Para esto hay un par de formas:

• Introduce una nueva carpeta __node_modules_mocks__ pero eso es feo.
• La carpeta de nivel superior __mocks__ vista desde rootDir (raíz del proyecto) podría actuar como una carpeta global.

Entonces, para resumir:

• ¡Arreglemos las simulaciones manuales en Jest!
• Vamos a apresurar el espacio de nombres de los módulos y limitarlos a determinadas carpetas / expresiones regulares.
• Asegúrese de que el comportamiento de burla actual todavía funcione para FB, incluso si eso significa que tenemos que incluir en la lista blanca ciertas carpetas para que funcione la prisa (supongo que por ahora se vería como ["<rootDir>"] )
• Descubra cómo seguir simulando módulos de nodo.

¿Qué piensas?

En orden:

• ¡Arreglemos las simulaciones manuales en Jest!

HURRAY: sonrisa:: tada:

• Vamos a apresurar el espacio de nombres de los módulos y limitarlos a determinadas carpetas / expresiones regulares.
• Asegúrese de que el comportamiento de burla actual todavía funcione para FB, incluso si eso significa que tenemos que incluir ciertas carpetas en la lista blanca para que funcione rápidamente (simplemente se vería como [""] para nosotros por ahora, supongo)

No estoy seguro de entender las necesidades con prisa.
¿Qué quieres decir con dar la posibilidad de decir "esos módulos son módulos de prisa"?
Si tenemos cuatro módulos: /path_1/a , /path_1/b , /path_2/a , /path_2/c , y la configuración es

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

solo /path_1/a y /path_1/b están restringidos a existir solo en /path_1 , por lo que /path_2/c es válido, y /path_2/a genera un error / advertencia.

Yo diría que los objetivos podrían ser fácilmente archivos específicos y directorios completos, incluso con * simples / dobles.

• Descubra cómo seguir simulando módulos de nodo.

Mantendría el comportamiento actual :

Si el módulo que está simulando es un módulo de nodo (por ejemplo: fs), el simulacro debe colocarse en el mismo directorio principal que la carpeta node_modules.

Mis pensamientos:

módulos de prisa:

Creo que haste_modules es bueno, encaja igual que collectCoverageFrom y otras opciones: matriz de globos
En caso de que tenga todos los src como módulos _haste_, y solo un directorio es sin prisa:

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

node_modules

@EnoahNetzach ¿qué

Para que funcione sin prisas ... hm, creo que se puede describir como:

dado el módulo de nodo project/node_modules/react , el simulacro estará dentro de project/__node_modules_mocks__/react.js
si tiene un archivo project/react.js , utilice project/__mocks__/react.js

(por supuesto, react.js es un ejemplo. Aquí puede haber cualquier nombre de archivo entre todos los módulos, que se pueden instalar desde npm )

Realmente, burlarse del módulo node_modules es un caso raro según mi experiencia, por lo que ... ¿puede ser que la _rareness_ pueda compensar la _feguridad_ en el caso particular de burlarse de los node_modules ?

¿Alguien se burla de los módulos dentro de node_modules a menudo?

que tal pensar mas

como noté, para proyectos nativos de application modules y dejar módulos de node_modules sin simular (por ejemplo, lodash )

esto significa que tenemos:

• Componente simulado creado manualmente para cada componente tonto (los componentes tontos son componentes de diseño)
• una larga lista de llamadas jest.mock en cada archivo de prueba

__lo que quiero decir__: sería muy bueno tener la capacidad de _auto mock_ módulos en algunas rutas.

Se puede implementar alrededor de una estructura de datos conocida array-of-jest-globs en config, y módulos de filtrado sobre ella.

Lo describiré paso a paso

Dada esta entrada de configuración

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

y este código en src/screens/app.js :

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

// blah blah AppScreen implementation skipped

y este código de prueba para la pantalla en src/screens/__tests__/app-test.js :

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

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

Llegamos a esta situación, en el contexto de app-test.js :

• AppScreen no se burlan
• lodash no se burlan
• Button , que es requerido por AppScreen , se burla

... Puede responder, ¿cómo funcionará con la entrada de configuración automock ?

simplemente diciendo, automock: true es equivalente a:

"autoMockingPaths": [
  "<rootDir>"
]

auto burlas ... espera!

puede ser simplemente introducir un valor especial para automock ? al menos no romperá las configuraciones de las personas

por ejemplo, con esta entrada de configuración:

automock: "app"

jest simulará automáticamente todos los módulos de la aplicación y dejará versiones reales para los módulos desde node_modules

¿Qué opinas sobre el automocking de módulos a nivel de aplicación, @cpojer ? Lo encuentro muy eficaz para mi caso particular.

Estoy totalmente de acuerdo con "haste_modules" .

Personalmente, no utilizamos tanto el transporte automático, así que no puedo decir qué es mejor, mi conjetura es que la "autoMockingPaths" var podría ser lo suficientemente útil y elástica.
Por el contrario, encuentro "automock": "app" demasiado rígido (la broma ya está desactivada por defecto).

El __node_modules_mocks__ podría ser una opción, estoy de acuerdo en que la rareza compensa la fealdad (en mi caso particular, rara vez nos burlamos de node_modules , y cuando tenemos que hacerlo, usamos jest.mock(...) ).
La única advertencia es: ¿qué sucede cuando tiene una carpeta node_modules anidada (por ejemplo, src/node_modules ), tiene que burlarse de sus módulos del __node_modules_mocks__ global, una versión anidada de o normalmente con __mocks__ coubicado?

puede ser simplemente arrojar, si alguien tiene el mismo nombre de módulo en node_modules y app modules

p.ej

app/express.js como módulo de aplicación (puede ser que estoy haciendo un juego de trenes)
y app/node_modules/express como servidor web de npm
throw new Error("can't mock express.js file - it duplicates one from node_modules")

en este caso, __mocks__ se puede usar para node_modules , pero el desarrollador debe cambiar el nombre de los módulos propios en tales colisiones

nah ... esto es más feo que __node_modules_mocks__ , ¿no?

Lo que quise decir es: ¿qué pasa si tienes un módulo npm install ed x y más adelante, más profundo en tu base de código define un módulo x en una carpeta node_modules anidada? ?

La colisión de nombres generalmente se maneja en el nodo prefiriendo el más cercano, pero no sé cómo funciona esto con prisa.

Menciono esto porque proyectos como Create React App lo están usando, o lo harán en un futuro cercano.

En una nota al margen , ¿ este problema está relacionado de alguna manera?

Mantengamos esto enfocado en cambiar cómo funciona la prisa (lista blanca / lista negra en lugar de activada por defecto). Creo que preferiría mantener que <rootDir>/__mocks__ debería ser el valor predeterminado para las simulaciones de módulos de nodo. Podríamos hacer de esta una opción de configuración también: "globalMocks" que por defecto es <rootDir>/__mocks__ . ¿Alguien está dispuesto a trabajar en esto?

Debería poder trabajar en esto antes del próximo fin de semana.

Puedo trabajar en relaciones públicas este domingo, soy un poco libre

@cpojer solo para recapitular: cree la entrada de configuración globalMocks con el valor predeterminado de <rootDir>/__mocks__ . Esta opción regula el uso de node-haste dentro de broma especificando la ruta? ¿O será una variedad de caminos?

Creo que estos son algunos cambios más importantes en la forma de resolver esto, pero creo que necesitamos tanto la opción singular globalMocks (podría ser una cadena o matriz de cadenas) como la opción hasteModules, que sería una matriz de rutas de módulos de aceleración. La mayor parte de este código vive en jest-haste-map y jest-resolve. Todavía no estoy 100% seguro de cuál será la solución correcta.

De: Max Sysoev [email protected]
Enviado: viernes 9 de diciembre de 2016 8:18:44 a.m.
Para: facebook / broma
Cc: Christoph Pojer; Mencionar
Asunto: Re: [facebook / jest] [bug] se ha encontrado un simulacro manual duplicado en directorios separados (# 2070)

Puedo trabajar en relaciones públicas este domingo, soy un poco libre

@cpojer https://github.com/cpojer solo para recapitular: cree la entrada de configuración globalMocks con el valor predeterminado de/ __ se burla__. Esta opción regula el uso de node-haste dentro de jest especificando path? ¿O será una variedad de caminos?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/facebook/jest/issues/2070#issuecomment-265958606 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AAA0KAMFc34iKqBDLHZzgaGHqyc3WkAzksga5rGQ7 .

Lo siento, mi estación de trabajo se rompió y aparentemente no hay forma de que funcione en un par de meses (1-2 meses). Incluso perdí mi proyecto en este PR :( Entonces, lo siento por asumir responsabilidades.

¿Qué tal solo una opción de configuración para cambiar el comportamiento de getMockName ?

No estoy muy familiarizado con los aspectos internos de la broma, pero parece que es la solución más simple para solucionar el problema sin romper la broma para FB.

Esto va a ser más complicado de lo que pensé originalmente. Para mí, las simulaciones manuales también deberían reemplazar el archivo al que están más cerca, es decir. algo como esto:

{ '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') debería resolverse en el /Users/project/__mocks__/aws-sdk.js esto es un simulacro para un node_module .

require('./db') (o cualquier ruta a db ) debería resolverse en: /Users/project/db/__mocks__/index.js .

Mi comprensión de la forma de configurar las simulaciones manuales de broma (y probablemente debería haber más documentación si se usa algo como lo anterior) era que deberían estar lo más cerca posible del archivo que se está simulando dentro de un directorio __mocks__ .

Los simulacros manuales se definen escribiendo un módulo en un subdirectorio __mocks __ / inmediatamente adyacente al módulo. (https://facebook.github.io/jest/docs/manual-mocks.html)

Dado eso, el comportamiento anterior tiene más sentido para mí.

Pensamientos?

Este es un paso inicial para implementar algo como lo anterior: https://github.com/facebook/jest/compare/master...mhahn : issue-2070-new-mock-resolution

Rompe la mayoría de las pruebas unitarias de broma porque ya no permite simulaciones "con nombre" puras como las siguientes: https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/__mocks__/ createRuntime.js

En mi opinión, algo como createRuntime es una utilidad de prueba que debe estar en una carpeta de utilidades de prueba e importarse en las pruebas que la necesiten. La forma en que se implementa como una simulación manual realmente no tiene sentido para mí como algo que debería conservarse.

Una opción es agregar una variable de configuración que cambiará entre el comportamiento existente y la versión limpia de los cambios anteriores. Sin embargo, no estoy realmente seguro de cómo debería llamarse.

No podemos romper el comportamiento actual ya que confiamos mucho en él en Facebook.

@cpojer estoy de acuerdo. Realmente no entendí este comentario después de leer el código: https://github.com/facebook/jest/issues/2070#issuecomment -265027510. ¿Quizás podríamos admitir la inclusión en la lista blanca de una lista de directorios que se resolverán con el comportamiento actual?

¿qué pasa con dos nuevas opciones de configuración:

• fullPathMockResolution (predeterminado en false para mantener el comportamiento existente)
  junto con:
• namedMockDirectories : si fullPathMockResolution está habilitado, cualquier directorio dentro de esa matriz se resolverá con el comportamiento existente. Para el caso de uso de FB, esto sería [<rootDir>] como mencionaste anteriormente.

Esto permite a los desarrolladores optar por la resolución de ruta completa para que no requiera cambios por las instalaciones de broma existentes y también habilita el comportamiento existente para directorios específicos si así lo desean.

cc @voideanvalue, esto puede ser algo en lo que tendrá que pensar (simulaciones manuales de espacio de nombres como parte de la nueva implementación de prisa).

+1, ¿hay alguna forma de solucionar este problema?

+1

¿Alguna actualización sobre cómo solucionar este problema? Esto resulta realmente doloroso si sigues una estructura como esta:

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

En este momento, tengo que simular manualmente un módulo en la prueba si estoy usando dos con un nombre 'en conflicto', aunque en realidad no tienen nombres en conflicto, ya que se debe considerar la ruta.

Salud,
Dominik

@cpojer ¿ Alguna actualización aquí chicos? ¿Existe alguna solución?

Una pequeña solución para mí es burlarse de los módulos con require

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

Cambié el nombre del nombre de la carpeta __mocks__ a _mocks_ para que la broma no capture los archivos.

Un día cuando esto funcione, cambiaré el nombre de _mocks_ a __mocks__ y eliminaré la parte requerida de jest.mock

En primer lugar: gracias por todo el increíble trabajo.
En segundo lugar: esto es realmente muy frustrante. Me veo obligado a usar jest.mock en el archivo de prueba cuando el archivo simulado comparte un nombre con cualquier otro archivo en todo el código base que también se burla. El levantamiento no permite que se importe también el simulacro real, por lo que le obliga a duplicar el simulacro en dos pruebas que requieran que ese archivo sea simulado, lo que aumenta la fragilidad del conjunto de pruebas. ¿Estamos pensando en abordar esto? ¿FB usa estas cosas? ¿Si es así, entonces cómo? 😞

+1 muy frustrante ver estas advertencias. No puedo esperar por una solución.

Creo que el problema que tengo está relacionado:

si tengo un jest.mock ('src / utils / history'), también se burla incorrectamente del node_module 'history'.

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

Chicos, ¿alguna actualización?

@masoudcs Creo que esto

package.json

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

Agregue las carpetas "duplicadas" en la matriz modulePathIgnorePatterns y la advertencia desaparecerá

Gracias @brunolm

Así que es solo una advertencia, ¿correcto?
Solo quiero asegurarme de que esto no cause que suceda algo malo, es decir, burlarse de index.js en varios directorios:
src/app/modules/module1/__mocks__/index.js y src/app/modules/module2/__mocks__/index.js

No sé si importa, pero cuando lo estaba ejecutando decía que elegiría solo el otro y esto que enumeré sería ignorado de cualquier manera.

Así que creo que está bien decirle que lo ignore, de todos modos no lo estaba usando.

Sí, como dijiste, y no hemos tenido problemas hasta ahora.
¡Con suerte, está haciendo lo que tiene que hacer! :)
Gracias

Intenté lo que sugirieron estas dos últimas confirmaciones, pero no eliminé la advertencia.

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

Veo esta advertencia porque uso GitBook (directorio ./_book ), aunque tengo testPathIgnorePatterns: ['/_book/', ...otherStuff] en mi configuración. Hojeando este problema, no veo una solución clara. Solo quiero dejar de ver las advertencias; cualquier ayuda sería apreciada.

+1

¿Algún avance en esto?

También sigo buscando una solución para que mis archivos de prueba se puedan importar de forma regular, no utilizando la forma más sucia que se sugirió anteriormente.

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

Nuestra estructura de directorio se ve igual que la de @dkundel a la que se hace referencia aquí https://github.com/facebook/jest/issues/2070#issuecomment -301332202 con modelos y componentes en sus propios espacios de nombres con index.js como predeterminado exportar.

Preferiría no silenciar las advertencias o arrojar todas las simulaciones a un directorio plano. Algunas de nuestras simulaciones están profundamente anidadas, y la solución alternativa sugerida probablemente se vería como
jest.mock('pages/index/components/Component', () => require('pages/index/components/Component/_mocks_/index'));
en nuestra estructura.

¿Cualquier palabra?

@karomancer He enviado PR # 6037 que le permitirá usar una configuración para eliminar las advertencias. Hasta el momento, no se ha fusionado; Estoy esperando una respuesta de los colaboradores.

Este problema es muy frustrante, pero creo que he encontrado una buena solución que da como resultado una convención de nomenclatura más limpia.

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

Esto le permitirá simular anything.ts creando un hermano anything.mock.ts y agregando la ruta al original en la matriz test.mocks nivel superior mockedModules .

¿Por qué este problema se etiquetó como mejora?

Esto parece funcionar para mí. en jest.config.js:

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

No estoy seguro del alcance o impacto de este cambio, porque tengo un proyecto pequeño.

@amccloud gracias! ¡Esto resolvió mi problema! Detalles abajo.

Tengo un módulo helpers en el directorio raíz de mi proyecto. El ayudante está exportando la función parseNodeFromString .
He creado en algún otro archivo local de módulo helpers . Luego me burlé de él para una de mis pruebas. Y todas las pruebas que usaban la función parseNodeFromString comenzaron a fallar con el siguiente error:

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

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

¿Qué pasa con este problema? Parece que la solución @amccloud es correcta.

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

Esta solución funciona aunque hizo que mis simulaciones de nivel superior para módulos de nodo fallaran. Así que lo cambié para no ignorar mi carpeta raíz __mock__ con: "modulePathIgnorePatterns": ["<rootDir>/src/react/.*/__mocks__"], . Aún así, es bastante extraño que los simulacros no sean únicos basados ​​en la ruta completa desde la raíz. Es bastante común tener: users/helper.js & posts/helper.js . La advertencia ocupa bastante espacio y no quiero ocultar completamente las advertencias reales.

Entonces, ¿cuál es el estado actual de las relaciones públicas? ¿Existe alguna solución adecuada o solo algunos trucos?

En mi caso, el módulo simulado se copió en el directorio Dist con cada compilación.

Parece que esto es un problema con el mecanografiado que no puede excluir rutas / patrones que pertenecen a una estructura de directorios más profunda. Sigue siendo un problema con "typescript@^3.4.5".

Para solucionar esto, comencé a limpiar mi directorio Dist con "rimraf dist" antes de cada ejecución de prueba.

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

Sé que es un truco, pero funciona.

Oye, resolví esto, esto es lo que sucedió, y tal vez pueda ayudarte a duplicar esto.

tres soluciones o escenarios:

1, estaba editando mi aplicación en mi editor de texto dos veces, estaba ejecutando pod install / update y react-native run-ios desde dos ventanas diferentes. y recibí este error, intenté buscar los archivos duplicados en Xcode y en mi aplicación, pero no pude encontrar ninguno. así que simplemente eliminé la aplicación del simulador y volví a ejecutar react-native run-ios y funcionó. Resultó que dos node_modules se habían duplicado como tales: node_modules y node_modules0 en mi archivo scr.

2, a veces, cuando presiono teclas aleatorias en mi mac, los node_modules se duplican, por ejemplo, en la carpeta SRC, por lo que este también es el caso, por lo que tiene sentido echar un vistazo a sus carpetas en busca de duplicaciones de node_modules.

3, no pude hacer que mi aplicación se iniciara hasta que inicié y terminé una aplicación diferente en el mismo simulador y luego reinicié la aplicación con la duplicación que luego se inició sin errores.

¿Todavía nada? No se puede usar modulePathIgnorePatterns en CRA

3 años y 10 meses

Alternativamente, sería bueno si pudiéramos obligar a Jest a lanzar un error cuando surja este problema, en lugar de solo advertir. Las advertencias se ignoran fácilmente; en mi proyecto, preferiría que se arrojara un error, por lo que el desarrollador que lo introdujo tiene que lidiar con él.