Jest: [bug] duplication manuelle de la maquette trouvée dans des répertoires séparés

+1

Dans mon cas, après avoir effacé les cacheDirectory / var / folders / dm / vt920lmd6tzdq_709zkykwx40000gn / T / jest et réinstaller les dépendances npm, ces messages ont disparu.

Voici le code incriminé:

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

Mais il semble que le comportement puisse être explicitement souhaité car un test le confirme:

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

Qui a été ajouté dans:

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

Je me demande pourquoi nous utilisons basename plutôt que le chemin complet comme clé?

/ cc @flarnie

Cela signifie que les basename s pour les modules doivent être globalement uniques dans un projet lors de l'utilisation de simulations manuelles. Pour mon cas d'utilisation, cela signifie que je ne peux pas faire quelque chose comme:

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

et utilisez des simulations manuelles en même temps. Jest les verra actuellement tous les deux se moquer de schema et se plaindra.

Bien que la solution de contournement soit triviale (s / schema / MyWhateverSchema /), cela ressemble à un bogue pour renommer et restructurer le code non-test pour rendre la plaisanterie heureuse

Oui, c'est vraiment nul. Le système de moquage manuel n'est vraiment pas bon et je suis heureux d'accepter les PR qui amélioreront la situation, en supposant que nous puissions nous assurer de ne pas casser tout FB (mais je peux m'en occuper :))

Cool. Je trouverai peut-être du temps demain pour préparer un patch, mais pas de promesses 😅

@cpojer y a-t-il une raison particulière à ce comportement ?

Cela pourrait-il avoir quelque chose à voir avec le fait que fb utilise des noms de fichiers uniques pour les modules? Je ne vois pas autrement comment ne pas autoriser deux simulacres avec le même nom a du sens ...

Oui, les simulacres sont également «globaux». C'est une conception terrible avec laquelle nous devons vivre, malheureusement. Chez FB, nous avons plus de 4000 fichiers simulés au mauvais endroit (et souvent, il n'y a même pas un emplacement approprié). Il est probable que nous réglerons ce problème au début de la prochaine moitié, donc cela devrait s'améliorer dans Jest. Je suis heureux de soutenir les PR qui améliorent le comportement de Jest pour l'open source - si nous pouvons conserver l'ancien comportement de Jest chez FB pour le moment.

@cpojer et un drapeau? Accepteriez-vous un pr qui active / désactive cela avec un drapeau?

Ouais, ça devrait être une option de configuration. Mais je ne parle pas seulement de l'avertissement, je parle aussi de la fonctionnalité en général.

@cpojer à droite - quelles parties de la plaisanterie cela touche-t-il?

Le code de résolution est appelé à partir de jest-runtime: https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js et est quelque part dans jest-resolution et jest-resolution-dependencies .

@cpojer merci pour les pointeurs: +1:

@cpojer qu'en est-il d'un remplacement global, comme JEST_USE_BASENAME_FOR_CACHING , pour changer ce comportement?

Au moins, nous pouvons profiter de noms de fichiers non uniques, et cela ne cassera rien dans FB.

Bien sûr, c'est une solution temporaire.

Je veux dire, c'est dans quelque /etc/profile ou ~/.bashrc

export JEST_USE_BASENAME_FOR_CACHING="true"

(ou un fichier avec env)
et alors

$ jest

ou celui-ci, sans modifications du fichier env:

$ JEST_USE_BASENAME_FOR_CACHING="true" jest

Ce que tu penses? C'est une sorte de hack ou c'est ok? :clin d'œil:

Je viens d'essayer avec un nouveau dépôt , en utilisant deux versions de jest ( ^15.0.0 et ^17.0.0 ) et, bien que ce dernier donne l'avertissement, le test se comporte comme prévu.

@ColCh Je ne pense pas que le problème ici soit avec le cache, probablement un nom plus approprié pourrait être JEST_USE_BASENAME_FOR_MOCKING .

@cpojer si le code FB a la restriction sur l'unicité des noms, l'utilisation du chemin complet comme clé pour la carte des mocks ne devrait pas poser de problèmes.

Ai-je raison ou il y a quelque chose que je ne vois pas?

Les deux solutions que je vois sont:

• modifier getMockName pour accepter l'option d'utiliser le nom de base ou le chemin complet
• supprimer complètement cette fonction

ce serait bien de voir @cpojer répondre là-dessus

Salut tout le monde, désolé pour le retard, je suis plutôt sauvegardé avec une tonne de trucs en ce moment.

Je pense que je vais bien si vous décidez de faire tout changement de rupture dans Jest qui est nécessaire pour améliorer ce système. La moquerie manuelle est vraiment gâchée et ne fonctionne pas bien. Une chose que nous voulons faire est de limiter la portée des "modules de précipitation" (système de module FB interne) en utilisant une option de configuration, comme "haste_modules": ['path/a', 'path/b']" , puis de ne regarder que les modules de précipitation dans ces dossiers, y compris cette moquerie étrange comportement. Si quelqu'un veut faire ce changement, ce serait incroyable.

Une chose à comprendre est alors la suivante: si toutes les simulations manuelles sont locales, comme __mocks__/a.js mappe à a.js , que faisons-nous avec les simulations node_module? Pour cela, il existe plusieurs façons:

• Introduisez un nouveau dossier __node_modules_mocks__ mais c'est moche.
• Le dossier de niveau supérieur __mocks__ vu de rootDir (racine du projet) pourrait agir comme un dossier global.

Donc pour résumer:

• Corrigeons les simulations manuelles dans Jest!
• Laissons les modules de hâte aux espaces de noms et limitons-les à certains dossiers / regex.
• Assurez-vous que le comportement moqueur actuel fonctionne toujours pour FB, même si cela signifie que nous devons mettre certains dossiers sur liste blanche pour accélérer le travail (cela ressemblerait simplement à ["<rootDir>"] pour nous pour le moment, je suppose)
• Découvrez comment toujours pouvoir simuler des modules de nœuds.

Qu'est-ce que tu penses?

En ordre:

• Corrigeons les simulations manuelles dans Jest!

HURRAY: sourire:: tada:

• Laissons les modules de hâte aux espaces de noms et limitons-les à certains dossiers / regex.
• Assurez-vous que le comportement moqueur actuel fonctionne toujours pour FB, même si cela signifie que nous devons ajouter certains dossiers à la liste blanche pour accélérer le travail (cela ressemblerait simplement à [""] pour nous pour l'instant, je suppose)

Je ne suis pas sûr de comprendre les besoins à la hâte.
Que voulez-vous dire, c'est donner la possibilité de dire "ces modules sont des modules de précipitation"?
Si nous avons quatre modules: /path_1/a , /path_1/b , /path_2/a , /path_2/c , et le paramètre est

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

seuls /path_1/a et /path_1/b sont limités pour exister uniquement dans /path_1 , donc /path_2/c est valide et /path_2/a génère une erreur / un avertissement.

Je dirais que les cibles peuvent facilement être des fichiers spécifiques et des répertoires entiers, même avec un simple / double * .

• Découvrez comment toujours pouvoir simuler des modules de nœuds.

Je maintiendrais le comportement actuel :

Si le module dont vous vous moquez est un module de nœud (par exemple: fs), la maquette doit être placée dans le même répertoire parent que le dossier node_modules.

Mes pensées:

modules de hâte:

Je pense que haste_modules est sympa, il convient exactement comme collectCoverageFrom et d'autres options: tableau de globs
Dans le cas, si vous avez tous les src comme modules _haste_, et qu'un seul répertoire n'est pas hâte:

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

node_modules

@EnoahNetzach et si quelqu'un avait les mêmes noms pour le module d'application et le module de node_modules?

Pour le faire fonctionner sans hâte ... hm, je pense que cela peut être décrit comme:

module de nœud donné project/node_modules/react , la simulation sera à l'intérieur de project/__node_modules_mocks__/react.js
si vous avez un fichier project/react.js , utilisez project/__mocks__/react.js

(bien sûr, react.js est un exemple. Ici peut être n'importe quel nom de fichier parmi tous les modules, qui peuvent être installés à partir de npm )

Vraiment, la moquerie du module node_modules ?

Quelqu'un se moque- t-il souvent des modules à l'intérieur de

que penser de plus

comme je l'ai remarqué, pour les projets réaction , nous devons souvent nous moquer de application modules et laisser les modules de node_modules débloqués (par exemple lodash )

cela signifie que nous avons:

• composant fictif créé manuellement pour chaque composant muet (les composants muets sont des composants de mise en page)
• une longue liste d'appels jest.mock dans chaque fichier de test

__ce que je veux dire__: ce serait très bien d'avoir la possibilité de _auto mock_ des modules sur certains chemins.

Il peut être implémenté autour de la structure de données bien connue array-of-jest-globs dans config, et des modules de filtrage dessus.

Je décrirai cela étape par étape

Compte tenu de cette entrée de configuration

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

et ce code à src/screens/app.js :

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

// blah blah AppScreen implementation skipped

et ce code de test pour écran à src/screens/__tests__/app-test.js :

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

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

Nous arrivons à cette situation, dans le contexte de app-test.js :

• AppScreen n'est pas moqué
• lodash n'est pas moqué
• Button , qui est requis par AppScreen , est moqué

... Vous pouvez répondre, comment il jouera avec l'entrée de configuration automock ?

dire simplement, automock: true équivaut à:

"autoMockingPaths": [
  "<rootDir>"
]

moquerie automatique ... attendez!

peut-être simplement introduire une valeur spéciale pour automock ? au moins ça ne cassera pas les configs des gens

par exemple, avec cette entrée de configuration:

automock: "app"

jest se moquera automatiquement de tous les modules d'application et laissera les versions réelles des modules à partir de node_modules

que pensez-vous du verrouillage automatique des modules au niveau de l'application, @cpojer ? Je trouve cela très efficace pour mon cas particulier.

Je suis entièrement d'accord avec "haste_modules" .

Personnellement, nous n'utilisons pas beaucoup le verrouillage automatique, donc je ne peux pas dire ce qui est mieux, je suppose que le var "autoMockingPaths" pourrait être utile et suffisamment élastique.
Au contraire , je trouve "automock": "app" trop raide (plaisanterie automocking déjà désactivé par défaut).

Le __node_modules_mocks__ pourrait être une option, je suis d'accord que la rareté compense la laideur (dans mon cas particulier, nous nous moquons rarement de node_modules , et quand nous devons le faire, nous utilisons jest.mock(...) ).
La seule mise en garde est: que se passe-t-il lorsque vous avez un dossier node_modules imbriqué (par exemple src/node_modules ), devez-vous vous moquer de ses modules du global __node_modules_mocks__ , une version imbriquée de ou normalement avec __mocks__ co-localisé?

peut être simplement jeté, si quelqu'un a le même nom de module dans node_modules et app modules

par exemple

app/express.js comme module d'application (peut-être que je fais un jeu de train)
et app/node_modules/express comme serveur Web à partir de npm
throw new Error("can't mock express.js file - it duplicates one from node_modules")

dans ce cas, __mocks__ peut être utilisé pour node_modules , mais les développeurs doivent renommer leurs propres modules sur de telles collisions

non ... c'est plus moche que __node_modules_mocks__ , n'est-ce pas?

Ce que je voulais dire, c'est: que se passe-t-il si vous avez un module npm install ed x et plus tard, plus profondément dans votre base de code définir un module x dans un dossier node_modules imbriqué ?

La collision de dénomination est généralement gérée dans le nœud en préférant le plus proche, mais je ne sais pas comment cela fonctionne à la hâte.

J'en parle parce que des projets comme Create React App l' utilisent ou le feront dans un proche avenir.

Sur une note de côté, @cpojer est cette question liée en quelque sorte?

Gardons cela concentré sur le changement du fonctionnement de la hâte (liste blanche / liste noire plutôt que activée par défaut). Je pense que je préférerais maintenir que <rootDir>/__mocks__ devrait être la valeur par défaut pour les simulations de modules de nœuds. Nous pourrions également en faire une option de configuration: "globalMocks" qui vaut par défaut <rootDir>/__mocks__ . Quelqu'un est-il prêt à travailler là-dessus?

Je devrais pouvoir y travailler au plus tôt le week-end prochain.

Je peux travailler sur les relations publiques ce dimanche, je suis un peu libre

@cpojer juste pour récapituler - créez globalMocks entrée de configuration <rootDir>/__mocks__ . Cette option régule l'utilisation de node-haste dans jest en spécifiant path? Ou ce sera un tableau de chemins?

Je pense que ce sont des changements plus importants sur la manière de résoudre ce problème, mais je pense que nous avons besoin à la fois de l'option singulière globalMocks (qui peut être une chaîne ou un tableau de chaînes) et de l'option hasteModules qui serait un tableau de chemins de modules hâte. La plupart de ce code vit dans jest-haste-map et jest-resolution. Je ne sais pas encore à 100% à quoi ressemblera la bonne solution.

De: Max Sysoev [email protected]
Envoyé: vendredi 9 décembre 2016 08:18:44
À: facebook / jest
Cc: Christoph Pojer; Mention
Sujet: Re: [facebook / jest] [bug] duplicate manuel simulé trouvé dans des répertoires séparés (# 2070)

Je peux travailler sur les relations publiques ce dimanche, je suis un peu libre

@cpojer https://github.com/cpojer juste pour récapituler - créez une entrée de configuration globalMocks avec la valeur par défaut de/ __ se moque__. Cette option régule l'utilisation de node-haste dans jest en spécifiant path? Ou ce sera un tableau de chemins?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub https://github.com/facebook/jest/issues/2070#issuecomment-265958606 , ou désactivez le fil https://github.com/notifications/unsubscribe-auth/AAA0KAMFc34iKqBDLHZzgaGHqycJ3WkAzk2

Désolé, mon poste de travail est devenu cassé, et apparemment aucun moyen de le faire fonctionner dans quelques mois (1-2 mois). J'ai même perdu mon projet sur ce PR: (Alors, désolé d'avoir pris des responsabilités.

Qu'en est-il juste une option de configuration pour changer le comportement de getMockName ?

Pas trop familier avec les éléments internes de jest, mais il semble que ce soit la solution la plus simple pour résoudre le problème sans casser la plaisanterie pour FB.

Cela va être plus compliqué que je ne le pensais au départ. Pour moi, les simulations manuelles devraient également remplacer le fichier dont elles sont les plus proches, à savoir. quelque chose comme ça:

{ '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') devrait se résoudre en /Users/project/__mocks__/aws-sdk.js c'est une simulation pour un node_module .

require('./db') (ou tout chemin vers db ) devrait se résoudre en: /Users/project/db/__mocks__/index.js .

Ma compréhension de la façon de configurer les simulations manuelles jest (et il devrait probablement y avoir plus de documentation si quelque chose comme ce qui précède est utilisé) était qu'ils devraient être aussi proches que possible du fichier simulé dans un répertoire __mocks__ .

Les simulations manuelles sont définies en écrivant un module dans un sous-répertoire __mocks __ / immédiatement adjacent au module. (https://facebook.github.io/jest/docs/manual-mocks.html)

Compte tenu de cela, le comportement ci-dessus est le plus logique pour moi.

Pensées?

Ceci est une première étape pour implémenter quelque chose comme ce qui précède: https://github.com/facebook/jest/compare/master...mhahn : issue-2070-new-mock-resolution

Il casse la majorité des tests unitaires de plaisanterie car il ne permet plus de pures simulations «nommées» comme celles-ci: https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/__mocks__/ createRuntime.js

IMO, quelque chose comme createRuntime est un utilitaire de test qui devrait être dans un dossier de test utils et importé dans les tests qui en ont besoin. La façon dont il est implémenté en tant que maquette manuelle n'a pas vraiment de sens pour moi comme quelque chose qui devrait être préservé.

Une option consiste à ajouter une variable de configuration qui basculera entre le comportement existant et la version nettoyée des modifications ci-dessus. Je ne sais pas vraiment comment cela devrait être appelé.

Nous ne pouvons pas casser le comportement actuel car nous nous en appuyons extrêmement sur Facebook.

@cpojer je suis d'accord. Je n'ai pas vraiment compris ce commentaire après avoir lu le code: https://github.com/facebook/jest/issues/2070#issuecomment -265027510. peut-être pourrions-nous soutenir la liste blanche d'une liste de répertoires qui résoudront le comportement actuel?

qu'en est-il de deux nouvelles options de configuration:

• fullPathMockResolution (par défaut à false pour conserver le comportement existant)
  associé à:
• namedMockDirectories : si fullPathMockResolution est activé, tous les répertoires de ce tableau seront résolus avec le comportement existant. Pour le cas d'utilisation FB, ce serait juste [<rootDir>] comme vous l'avez mentionné ci-dessus.

Cela permet aux développeurs d'opter pour la résolution de chemin complet afin qu'elle ne nécessite pas de modifications par les installations jest existantes et active également le comportement existant pour des répertoires spécifiques s'ils le souhaitent.

cc @voideanvalue vous devrez peut-être penser à cela (le manuel de l'espace de noms se moque dans le cadre de la nouvelle implémentation hâte).

+1, y a-t-il un moyen de résoudre ce problème?

+1

Des mises à jour sur la façon de résoudre ce problème? Cela s'avère vraiment douloureux si vous suivez une structure comme celle-ci:

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

À l'heure actuelle, je dois moquer manuellement un module dans le test si j'en utilise deux avec un nom `` en conflit '' même s'ils n'ont en fait pas de noms en conflit, car le chemin doit être pris en compte.

À votre santé,
Dominik

@cpojer Des mises à jour ici les gars? Y at-il un travail autour?

Une petite solution de contournement pour moi est de se moquer des modules avec require

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

J'ai renommé le nom du dossier __mocks__ en _mocks_ pour que la plaisanterie n'attrape pas les fichiers.

Un jour où cela fonctionnera, je renommerai _mocks_ en __mocks__ et supprimerai la partie requise de jest.mock

Premièrement: merci pour tout le travail formidable.
Deuxièmement: c'est vraiment très frustrant. Je me retrouve obligé d'utiliser jest.mock dans le fichier de test lorsque le fichier fictif partage un nom avec tout autre fichier dans l'ensemble de la base de code qui est également moqué. Le levage interdit également l'importation de la maquette réelle, ce qui vous oblige à dupliquer la maquette dans deux tests qui nécessitent que ce fichier soit simulé, ce qui ajoute à la fragilité de la suite de tests. Cherchons-nous à résoudre ce problème? Est-ce que FB utilise ce truc? Si oui, alors comment? 😞

+1 très frustrant de voir ces avertissements. J'ai hâte de trouver une solution.

Je pense que le problème que j'ai est lié:

si j'ai un jest.mock ('src / utils / history'), il se moque également incorrectement du node_module 'history'.

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

Les gars une mise à jour?

@masoudcs Je pense que cela a

package.json

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

Ajoutez les dossiers "duplicate" dans le tableau modulePathIgnorePatterns et l'avertissement disparaîtra

Merci @brunolm

C'est donc juste un avertissement, n'est-ce pas?!
Je veux juste m'assurer que cela ne provoquerait pas quelque chose de mauvais, c'est-à-dire se moquer de index.js dans plusieurs répertoires:
src/app/modules/module1/__mocks__/index.js et src/app/modules/module2/__mocks__/index.js

Je ne sais pas si cela compte, mais quand je courais, il disait qu'il ne choisirait que l'autre et que ce que j'ai énuméré serait ignoré de toute façon.

Je pense donc que c'est bien de lui dire d'ignorer, il ne l'utilisait pas de toute façon.

Oui, comme vous l'avez dit, et nous n'avons rencontré aucun problème jusqu'à présent.
Espérons qu'il fait ce qu'il a à faire! :)
Merci

J'ai essayé ce que ces deux derniers commits suggéraient mais je n'ai pas supprimé l'avertissement.

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

Je vois cet avertissement car j'utilise GitBook (répertoire ./_book ), même si j'ai testPathIgnorePatterns: ['/_book/', ...otherStuff] dans ma configuration. En parcourant ce problème, je ne vois pas de solution de contournement claire. Je veux juste arrêter de voir les avertissements - toute aide serait appréciée.

+1

Une mise à jour pour ceci?

Toujours à la recherche d'un correctif pour que mes fichiers de test puissent être importés de manière régulière, sans utiliser la méthode la plus sale qui a été suggérée ci-dessus.

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

Notre structure de répertoires ressemble à celle de @dkundel référencée ici https://github.com/facebook/jest/issues/2070#issuecomment -301332202 avec les modèles et les composants dans leurs propres espaces de noms avec index.js étant la valeur par défaut exportation.

Préfère ne pas faire taire les avertissements ou jeter tous les faux dans un répertoire plat. Certains de nos simulacres sont profondément imbriqués et la solution de contournement suggérée ressemblerait probablement à
jest.mock('pages/index/components/Component', () => require('pages/index/components/Component/_mocks_/index'));
dans notre structure.

N'importe quel mot?

@karomancer J'ai soumis le PR # 6037 qui vous permettra d'utiliser une configuration pour supprimer les avertissements. Pour l'instant, il n'a pas été fusionné; J'attends une réponse des contributeurs.

Ce problème est très frustrant, mais je pense avoir trouvé une bonne solution de contournement qui aboutit à une convention de dénomination plus claire.

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

Cela vous permettra de moquez anything.ts en créant un sibling anything.mock.ts et en ajoutant le chemin de l'original dans le haut niveau test.mocks s » mockedModules tableau.

Pourquoi ce problème est-il identifié comme une amélioration?

Cela semble fonctionner pour moi. dans jest.config.js:

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

Je ne suis pas sûr de la portée ou de l'impact de ce changement, car j'ai un petit projet.

@amccloud merci! Cela a résolu mon problème! Détails ci-dessous.

J'ai un module helpers dans le répertoire racine de mon projet. L'assistant exporte la fonction parseNodeFromString .
J'ai créé dans un autre module le fichier local helpers . Puis je me suis moqué de lui pour l'un de mes tests. Et tous les tests utilisant la fonction parseNodeFromString commencé à échouer avec l'erreur suivante:

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

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

Et ce problème? On dirait que la solution

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

Cette solution fonctionne bien qu'elle ait fait échouer mes simulations de haut niveau pour les modules de nœuds. Je l'ai donc changé pour ne pas ignorer mon dossier racine __mock__ avec: "modulePathIgnorePatterns": ["<rootDir>/src/react/.*/__mocks__"], . Pourtant, il est assez étrange que les simulacres ne soient pas seulement uniques en fonction du chemin complet depuis la racine. Il est assez courant d'avoir: users/helper.js & posts/helper.js . L'avertissement prend assez de place et je ne veux pas cacher complètement les avertissements réels.

Alors, quel est le statut actuel des relations publiques? Existe-t-il une solution appropriée ou juste quelques hacks?

Dans mon cas, le module fictif a été copié dans le répertoire Dist à chaque build.

On dirait que c'est un problème avec le typographie incapable d'exclure les chemins / modèles appartenant à une structure de répertoire plus profonde. C'est toujours un problème avec "typescript@^3.4.5".

Pour résoudre ce problème, j'ai commencé à nettoyer mon répertoire Dist avec "rimraf dist" avant chaque test.

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

Je sais que c'est un hack, mais ça marche.

Hé, j'ai résolu ce problème, voici ce qui s'est passé, et peut-être que cela peut vous aider à dupliquer cela.

trois solutions ou scénarios:

1, je modifiais deux fois mon application sur mon éditeur de texte, ce qui signifie que j'exécutais l'installation / la mise à jour du pod et le run-ios natif de réaction à partir de deux fenêtres différentes. et j'ai eu cette erreur, j'ai essayé de rechercher les fichiers en double dans Xcode et sur mon application mais je n'en ai trouvé aucun. J'ai donc simplement supprimé l'application du simulateur et relancé react-native run-ios et cela a fonctionné.Il s'est avéré que deux node_modules avaient été dupliqués en tant que tels: node_modules et node_modules0 dans mon fichier scr.

2, parfois lorsque j'appuie sur des touches aléatoires sur mon mac, les node_modules sont dupliqués par exemple dans le dossier SRC, donc c'est également le cas, il est donc logique de jeter un œil à vos dossiers pour toute duplication de node_modules.

3, je ne pouvais pas démarrer mon application tant que je n'avais pas lancé et arrêté une application différente sur le même simulateur, puis j'ai redémarré l'application avec la duplication qui s'est ensuite déclenchée sans aucune erreur.

Toujours rien? Impossible d'utiliser modulePathIgnorePatterns dans CRA

3 ans et 10 mois

Alternativement, ce serait bien si nous pouvions forcer Jest à générer une erreur lorsque ce problème survient, plutôt qu'un simple avertissement. Les avertissements sont facilement ignorés; sur mon projet, je préférerais qu'une erreur soit levée, donc le développeur qui l'a introduit doit s'en occuper.