Jest: [bug] tiruan manual duplikat ditemukan di direktori terpisah

+1

Dalam kasus saya, setelah menghapus cacheDirectory / var / folder / dm / vt920lmd6tzdq_709zkykwx40000gn / T / jest dan menginstal ulang dependensi npm, pesan-pesan ini telah menghilang.

Berikut kode yang melanggar:

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

Tapi sepertinya perilaku tersebut mungkin secara eksplisit diinginkan karena ada pengujian yang mengonfirmasi:

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

Yang ditambahkan di:

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

Saya bertanya-tanya mengapa kita menggunakan basename daripada seluruh path sebagai kuncinya?

/ cc @flarnie

Ini berarti basename s untuk modul harus unik secara global dalam sebuah proyek saat menggunakan tiruan manual. Untuk kasus penggunaan saya, ini berarti saya tidak dapat melakukan sesuatu seperti:

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

dan menggunakan ejekan manual pada saat bersamaan. Jest saat ini akan melihat mereka berdua mengejek schema dan mengeluh.

Meskipun solusinya sepele (s / schema / MyWhateverSchema /), rasanya seperti bug untuk mengganti nama dan menyusun ulang kode non-tes untuk membuat lelucon menyenangkan 🐞.

Ya, ini memang menyebalkan. Sistem ejekan manual benar-benar tidak baik dan saya senang menerima PR yang akan memperbaiki situasi, dengan asumsi kami dapat memastikan bahwa kami tidak merusak semua FB (tapi saya bisa mengurusnya :))

Keren. Saya mungkin menemukan waktu besok untuk memasak tambalan, tetapi tidak ada janji 😅

@cpojer adakah alasan khusus untuk perilaku ini ?

Mungkinkah ada hubungannya dengan fakta bahwa fb menggunakan nama file unik untuk modul? Saya tidak melihat sebaliknya bagaimana tidak membiarkan dua olok-olok dengan nama yang sama masuk akal ...

Ya, ejekan juga bersifat "global". Sayangnya, ini adalah desain yang mengerikan yang harus kita jalani. Di FB kami memiliki 4000+ file tiruan di lokasi yang salah (dan seringkali bahkan tidak ada lokasi yang tepat). Kemungkinan kami akan memperbaikinya awal paruh berikutnya, jadi ini akan membaik di Jest. Saya senang mendukung PR yang meningkatkan perilaku di Jest untuk open source - jika kita dapat mempertahankan perilaku lama Jest di FB untuk saat ini.

@cpojer bagaimana dengan sebuah bendera? Apakah Anda menerima pr yang mengaktifkan / menonaktifkan ini dengan sebuah bendera?

Ya, itu harus menjadi opsi konfigurasi. Tapi saya tidak hanya berbicara tentang peringatan, saya juga berbicara tentang fitur secara umum.

@cpojer right - bagian lelucon mana yang disentuh ini?

Kode resolusi dipanggil dari jest-runtime: https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js dan berada di suatu tempat di jest-menyelesaikan dan jest-menyelesaikan-dependensi .

@cpojer terima kasih atas petunjuknya: +1:

@cpojer bagaimana dengan beberapa override global, seperti JEST_USE_BASENAME_FOR_CACHING , untuk mengubah perilaku ini?

Setidaknya, kita bisa menikmati nama file yang tidak unik, dan tidak akan merusak apapun di FB.

Tentu saja, ini solusi sementara.

Maksud saya, ini ada di sekitar /etc/profile atau ~/.bashrc

export JEST_USE_BASENAME_FOR_CACHING="true"

(atau beberapa file dengan env)
lalu

$ jest

atau yang ini, tanpa modifikasi file env:

$ JEST_USE_BASENAME_FOR_CACHING="true" jest

Apa yang Anda pikirkan? Ini semacam peretasan atau tidak apa-apa? :mengedipkan:

Saya baru saja mencoba dengan repo baru , menggunakan dua versi jest ( ^15.0.0 dan ^17.0.0 ) dan, meskipun yang terakhir memberi peringatan, pengujian berperilaku seperti yang diharapkan.

@ColCh Saya tidak berpikir masalah di sini adalah dengan cache, mungkin nama yang lebih cocok adalah JEST_USE_BASENAME_FOR_MOCKING .

@cpojer jika kode FB memiliki batasan pada keunikan nama, menggunakan path lengkap sebagai kunci untuk peta tiruan seharusnya tidak membawa masalah.

Apakah saya benar atau ada sesuatu yang tidak saya lihat?

Dua solusi yang saya lihat adalah:

• modifikasi getMockName untuk mengakomodasi opsi untuk menggunakan nama dasar atau path lengkap
• hapus fungsi itu sama sekali

alangkah baiknya melihat jawaban @cpojer di atasnya

Hai semuanya, maaf atas keterlambatannya, saya cukup didukung dengan banyak hal sekarang.

Saya pikir saya baik-baik saja jika kalian memutuskan untuk melakukan perubahan apa pun di Jest yang diperlukan untuk meningkatkan sistem ini. Ejekan manual benar-benar kacau dan tidak berfungsi dengan baik. Satu hal yang ingin kami lakukan adalah membatasi cakupan "modul tergesa-gesa" (sistem modul FB internal) menggunakan opsi konfigurasi, seperti "haste_modules": ['path/a', 'path/b']" dan hanya melihat modul tergesa-gesa di folder tersebut, termasuk ejekan aneh ini tingkah laku. Jika ada yang ingin membuat perubahan ini, itu akan luar biasa.

Satu hal yang harus dipikirkan, adalah ini: Jika semua tiruan manual bersifat lokal, seperti __mocks__/a.js dipetakan ke a.js , apa yang kita lakukan dengan node_module tiruan? Untuk ini ada beberapa cara:

• Perkenalkan folder __node_modules_mocks__ tapi itu jelek.
• Folder __mocks__ tingkat atas seperti yang terlihat dari rootDir (akar proyek) dapat bertindak sebagai folder global.

Jadi untuk meringkas:

• Mari perbaiki ejekan manual di Jest!
• Mari kita buru modul namespace dan membatasinya ke folder / regex tertentu apa pun.
• Pastikan bahwa perilaku mengejek saat ini masih berfungsi untuk FB, meskipun itu berarti kita harus memasukkan folder tertentu ke daftar putih agar tergesa-gesa (sepertinya ["<rootDir>"] untuk kita saat ini, kurasa)
• Cari tahu bagaimana untuk tetap bisa membuat tiruan modul node.

Bagaimana menurut anda?

Dalam urutan:

• Mari perbaiki ejekan manual di Jest!

HURRAY: smile:: tada:

• Mari kita buru modul namespace dan membatasinya ke folder / regex tertentu apa pun.
• Pastikan perilaku mengejek saat ini masih berfungsi untuk FB, meskipun itu berarti kami harus memasukkan folder tertentu ke daftar putih agar tergesa-gesa (akan terlihat seperti [""] untuk kita sekarang, kurasa)

Saya tidak yakin saya memahami kebutuhan dengan tergesa-gesa.
Apa yang Anda maksud adalah memberikan kemungkinan untuk mengatakan "modul-modul itu adalah modul tergesa-gesa"?
Jika kita memiliki empat modul: /path_1/a , /path_1/b , /path_2/a , /path_2/c , dan pengaturannya adalah

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

hanya /path_1/a dan /path_1/b dibatasi hanya ada di /path_1 , jadi /path_2/c berlaku, dan /path_2/a memunculkan kesalahan / peringatan.

Menurut saya, target dapat dengan mudah berupa file tertentu dan seluruh direktori, bahkan dengan single / double * .

• Cari tahu bagaimana untuk tetap bisa membuat tiruan modul node.

Saya akan mempertahankan perilaku saat ini :

Jika modul yang Anda olok adalah modul node (misalnya: fs), tiruan harus ditempatkan di direktori induk yang sama dengan folder node_modules.

Pikiran saya:

modul tergesa-gesa:

Saya pikir, haste_modules itu bagus, itu pas seperti collectCoverageFrom dan opsi lain: array globs
Dalam kasus ini, jika Anda memiliki semua src sebagai modul _haste_, dan hanya satu direktori yang tidak tergesa-gesa:

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

node_modules

@EnoahNetzach bagaimana jika seseorang memiliki nama yang sama untuk modul aplikasi dan modul dari node_modules?

Untuk membuatnya bekerja tanpa tergesa-gesa ... hm, saya rasa bisa digambarkan seperti:

diberikan modul node project/node_modules/react , tiruan akan berada di dalam project/__node_modules_mocks__/react.js
jika Anda memiliki file project/react.js , gunakan project/__mocks__/react.js

(tentu saja, react.js adalah contoh. di sini dapat nama file apa saja di antara semua modul, yang dapat diinstal dari npm )

Sungguh, mengejek modul node_modules adalah kasus yang jarang terjadi menurut pengalaman saya, jadi ... mungkin _rareness_ dapat mengkompensasi _ugliness_ dalam kasus tertentu mengejek node_modules ?

Adakah yang sering mengejek modul di dalam

bagaimana memikirkan lebih jauh

seperti yang saya perhatikan, untuk proyek react-native , kita sering kali harus mengejek application modules dan membiarkan modul dari node_modules tidak dicopot (misalnya lodash )

ini berarti, kami memiliki:

• komponen tiruan yang dibuat secara manual untuk setiap komponen bodoh (komponen bodoh adalah komponen tata letak)
• daftar panjang panggilan jest.mock di setiap file pengujian

__apa yang ingin saya katakan__: akan sangat menyenangkan memiliki kemampuan untuk _auto mock_ modul di beberapa jalur.

Ini dapat diimplementasikan di sekitar struktur data terkenal array-of-jest-globs di config, dan modul pemfilteran di atasnya.

Saya akan menjelaskan langkah demi langkah itu

Diberikan entri konfigurasi ini

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

dan kode ini di src/screens/app.js :

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

// blah blah AppScreen implementation skipped

dan kode tes ini untuk layar pada src/screens/__tests__/app-test.js :

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

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

Kami sampai pada situasi ini, dalam konteks app-test.js :

• AppScreen tidak dipermainkan
• lodash tidak dipermainkan
• Button , yang dibutuhkan oleh AppScreen , diejek

... Anda bisa menjawab, bagaimana itu akan bermain dengan entri config automock ?

hanya mengatakan, automock: true sama dengan:

"autoMockingPaths": [
  "<rootDir>"
]

otomatis mengejek ... tunggu!

mungkin hanya memperkenalkan nilai khusus untuk automock ? setidaknya itu tidak akan merusak konfigurasi orang

misalnya, dengan entri konfigurasi ini:

automock: "app"

lelucon akan otomatis mengejek semua modul aplikasi, dan meninggalkan versi sebenarnya untuk modul dari node_modules

apa pendapat Anda tentang penguncian otomatis modul tingkat aplikasi, @cpojer ? Saya merasa sangat efisien untuk kasus khusus saya.

Saya setuju sepenuhnya dengan "haste_modules" .

Kami pribadi tidak terlalu banyak menggunakan penguncian otomatis, jadi saya tidak bisa mengatakan mana yang lebih baik, tebakan liar saya adalah bahwa "autoMockingPaths" var bisa berguna dan cukup elastis.
Sebaliknya saya menemukan "automock": "app" terlalu kaku ( lelucon sudah menonaktifkan automocking secara default).

__node_modules_mocks__ bisa menjadi pilihan, saya setuju bahwa kelangkaan mengkompensasi keburukan (dalam kasus khusus saya, kami jarang mengejek node_modules , dan ketika kami harus melakukannya, kami menggunakan jest.mock(...) ).
Satu-satunya peringatan adalah: apa yang terjadi ketika Anda memiliki folder node_modules bersarang (misalnya src/node_modules ), apakah Anda harus meniru modulnya dari __node_modules_mocks__ global, versi bertingkat dari itu, atau biasanya dengan __mocks__ berada di lokasi yang sama?

mungkin hanya melempar, jika seseorang memiliki nama modul yang sama di node_modules dan app modules

misalnya

app/express.js sebagai modul aplikasi (mungkin saya melakukan permainan kereta api)
dan app/node_modules/express sebagai server web dari npm
throw new Error("can't mock express.js file - it duplicates one from node_modules")

dalam hal ini, __mocks__ dapat digunakan untuk node_modules , tetapi dev harus mengganti nama modul sendiri pada tabrakan seperti itu

nah ... ini lebih jelek dari __node_modules_mocks__ , bukan?

Yang saya maksud adalah: bagaimana jika Anda memiliki modul npm install ed x dan kemudian, lebih dalam di basis kode Anda tentukan modul x dalam folder node_modules bersarang ?

Tabrakan penamaan biasanya ditangani dalam node dengan memilih yang terdekat, tetapi saya tidak tahu bagaimana ini bekerja dengan tergesa-gesa.

Saya mengungkit ini karena proyek seperti Create React App sedang menggunakannya, atau akan dilakukan dalam waktu dekat.

Di samping catatan, @cpojer apakah masalah ini terkait?

Mari kita tetap fokus pada mengubah cara kerja tergesa-gesa (daftar putih / daftar hitam daripada aktif secara default). Saya pikir saya lebih suka mempertahankan bahwa <rootDir>/__mocks__ harus menjadi default untuk modul node tiruan. Kita bisa menjadikan ini opsi konfigurasi juga: "globalMocks" yang defaultnya ke <rootDir>/__mocks__ . Apakah ada yang mau mengerjakan ini?

Saya harus bisa mengerjakan ini paling cepat dari akhir pekan depan.

Saya bisa mengerjakan PR minggu ini, saya agak bebas

@cpojer hanya untuk rekap - buat entri config globalMocks dengan nilai default <rootDir>/__mocks__ . Opsi ini mengatur penggunaan node-haste dalam lelucon dengan menentukan path? Atau itu akan menjadi larik jalur?

Saya pikir ini adalah beberapa perubahan yang lebih besar dalam perjalanan untuk menyelesaikan ini tetapi saya pikir kita memerlukan opsi globalMocks tunggal (bisa berupa string atau array string) dan opsi hasteModules yang akan menjadi array jalur modul tergesa-gesa. Sebagian besar kode ini hidup dalam peta-lelucon dan penyelesaian-lelucon. Saya belum 100% yakin seperti apa solusi yang tepat nantinya.

Dari: Max Sysoev [email protected]
Dikirim: Jumat, 9 Desember 2016 08.18.44
Untuk: facebook / jest
Cc: Christoph Pojer; Menyebut
Subjek: Re: [facebook / jest] [bug] tiruan manual duplikat ditemukan di direktori terpisah (# 2070)

Saya bisa mengerjakan PR minggu ini, saya agak bebas

@cpojer https://github.com/cpojer hanya untuk rekap - buat entri konfigurasi globalMocks dengan nilai default/ __ mengolok-olok__. Opsi ini mengatur penggunaan node-haste dalam jest dengan menentukan jalur? Atau itu akan menjadi larik jalur?

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub https://github.com/facebook/jest/issues/2070#issuecomment-265958606 , atau nonaktifkan utas https://github.com/notifications/unsubscribe-auth/AAA0KAMFc34iKqBDLHZzgaGHqyc3WkAzks5rGQ7kga

Maaf, workstation saya rusak, dan sepertinya tidak ada cara untuk membuatnya berfungsi dalam beberapa bulan (1-2 bulan). Saya bahkan kehilangan proyek saya pada PR ini :( Jadi, maaf telah mengambil tanggung jawab.

Bagaimana dengan opsi konfigurasi untuk mengubah perilaku getMockName ?

Tidak terlalu akrab dengan internal lelucon, tetapi sepertinya itu adalah solusi paling sederhana untuk memperbaiki masalah tanpa merusak lelucon untuk FB.

Ini akan menjadi lebih rumit dari yang saya kira. Bagi saya, tiruan manual harus menggantikan file terdekat mereka juga, yaitu. sesuatu seperti ini:

{ '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') harus menyelesaikan ke /Users/project/__mocks__/aws-sdk.js ini adalah tiruan untuk node_module .

require('./db') (atau path ke db ) harus diselesaikan ke: /Users/project/db/__mocks__/index.js .

Pemahaman saya tentang cara men-setup olok-olok manual lelucon (dan mungkin harus ada lebih banyak dokumentasi jika sesuatu seperti di atas digunakan) adalah bahwa mereka harus sedekat mungkin dengan file yang diejek sebanyak mungkin dalam direktori __mocks__ .

Mock manual didefinisikan dengan menulis modul dalam subdirektori __mocks __ / yang berbatasan langsung dengan modul. (https://facebook.github.io/jest/docs/manual-mocks.html)

Mengingat hal itu, perilaku di atas paling masuk akal bagi saya.

Pikiran?

Ini adalah langkah awal dalam mengimplementasikan sesuatu seperti di atas: https://github.com/facebook/jest/compare/master...mhahn : issue-2070-new-mock-resolution

Ini merusak sebagian besar pengujian unit lelucon karena tidak lagi memungkinkan untuk tiruan "bernama" murni seperti berikut: https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/__mocks__/ createRuntime.js

IMO, sesuatu seperti createRuntime adalah utilitas pengujian yang harus ada di folder test utils dan diimpor dalam pengujian yang membutuhkannya. Cara penerapannya sebagai tiruan manual tidak terlalu masuk akal bagi saya sebagai sesuatu yang harus dipertahankan.

Salah satu opsinya adalah menambahkan variabel config yang akan beralih antara perilaku yang ada dan versi yang dibersihkan dari perubahan di atas. Saya tidak begitu yakin apa yang harus disebut.

Kami tidak dapat menghentikan perilaku saat ini karena kami sangat mengandalkannya di Facebook.

@cpojer saya setuju. saya tidak terlalu memahami komentar ini setelah membaca kode: https://github.com/facebook/jest/issues/2070#issuecomment -265027510. mungkin kami dapat mendukung daftar putih direktori yang akan menyelesaikan perilaku saat ini?

bagaimana dengan dua opsi konfigurasi baru:

• fullPathMockResolution (default ke false untuk mempertahankan perilaku yang ada)
  ditambah dengan:
• namedMockDirectories : jika fullPathMockResolution diaktifkan, semua direktori di dalam array itu akan diselesaikan dengan perilaku yang ada. Untuk kasus penggunaan FB, ini hanya akan menjadi [<rootDir>] seperti yang Anda sebutkan di atas.

Ini memungkinkan pengembang memilih resolusi jalur penuh sehingga tidak memerlukan perubahan dengan pemasangan lelucon yang ada dan juga mengaktifkan perilaku yang ada untuk direktori tertentu jika mereka menginginkannya.

cc @voideanvalue ini mungkin sesuatu yang harus Anda pikirkan (manual ruang nama mengolok-olok sebagai bagian dari implementasi tergesa-gesa baru).

+1, apakah ada cara untuk memperbaikinya?

+1

Adakah pembaruan tentang cara memperbaiki masalah ini? Ini ternyata sangat menyakitkan jika Anda mengikuti struktur seperti ini:

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

Saat ini saya harus mengejek modul secara manual dalam pengujian jika saya menggunakan dua modul dengan nama yang 'bertentangan' meskipun sebenarnya tidak memiliki nama yang bertentangan karena jalurnya harus dipertimbangkan.

Bersulang,
Dominik

@cpojer Ada pembaruan di sini guys? Apakah ada solusinya?

Solusi kecil bagi saya adalah mengejek modul dengan keperluan

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

Saya mengganti nama folder __mocks__ menjadi _mocks_ sehingga lelucon tidak menangkap file.

Suatu hari ketika ini akan berhasil saya akan mengganti nama _mocks_ menjadi __mocks__ dan menghapus bagian yang diperlukan dari jest.mock

Pertama: Terima kasih untuk semua pekerjaan yang luar biasa.
Kedua: Ini benar-benar membuat frustrasi. Saya mendapati diri saya terpaksa menggunakan jest.mock di file pengujian ketika file yang diejek tersebut berbagi nama dengan file lain di seluruh basis kode yang juga diejek. Pengangkat melarang tiruan yang sebenarnya untuk diimpor juga, sehingga memaksa Anda untuk menduplikasi tiruan tersebut dalam dua pengujian mana pun yang memerlukan file tersebut untuk diejek, yang menambah kerapuhan rangkaian pengujian. Apakah kita sedang berusaha mengatasi ini? Apakah FB menggunakan barang ini? Jika ya, lalu bagaimana caranya? 😞

+1 sangat frustasi melihat peringatan tersebut. Tidak sabar menunggu perbaikan.

Saya pikir masalah yang saya alami terkait:

jika saya memiliki jest.mock ('src / utils / history'), itu juga salah mengolok-olok 'history' node_module.

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

Teman-teman update?

@masoudcs Saya pikir ini menghilangkan peringatan:

package.json

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

Tambahkan folder "duplikat" dalam array modulePathIgnorePatterns dan peringatan akan hilang

Terima kasih @brunol

Jadi itu hanya peringatan, benar ?!
Saya hanya ingin memastikan ini tidak menyebabkan sesuatu yang buruk terjadi, yaitu mengejek index.js di beberapa direktori:
src/app/modules/module1/__mocks__/index.js dan src/app/modules/module2/__mocks__/index.js

Saya tidak tahu apakah itu penting, tetapi ketika saya menjalankannya, ia mengatakan itu hanya akan memilih yang lain dan ini yang saya daftarkan akan diabaikan.

Jadi saya pikir tidak apa-apa untuk mengatakannya untuk diabaikan, itu tidak menggunakannya.

Ya seperti yang Anda katakan, dan kami tidak menghadapi masalah apa pun sampai sekarang.
Mudah-mudahan, itu melakukan apa yang harus dilakukannya! :)
Terima kasih

Saya mencoba apa yang disarankan oleh dua komitmen terakhir ini tetapi tidak menghapus peringatan.

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

Saya melihat peringatan ini karena saya menggunakan GitBook (direktori ./_book ), meskipun saya memiliki testPathIgnorePatterns: ['/_book/', ...otherStuff] dalam konfigurasi saya. Melihat sekilas masalah ini, saya tidak melihat solusi yang jelas. Saya hanya ingin berhenti melihat peringatan - bantuan apa pun akan dihargai.

+1

Ada pembaruan tentang ini?

Juga masih mencari perbaikan agar file test saya bisa diimport secara biasa, bukan dengan cara yang lebih kotor seperti yang disarankan di atas.

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

Struktur direktori kami terlihat sama dengan @dkundel yang dirujuk di sini https://github.com/facebook/jest/issues/2070#issuecomment -301332202 dengan model dan komponen dalam namespace mereka sendiri dengan index.js sebagai default ekspor.

Lebih suka untuk tidak membungkam peringatan atau membuang semua ejekan ke dalam direktori datar. Beberapa dari tiruan kami sangat bersarang, dan solusi yang disarankan kemungkinan akan terlihat seperti
jest.mock('pages/index/components/Component', () => require('pages/index/components/Component/_mocks_/index'));
dalam struktur kami.

Kata apapun?

@karomancer Saya telah mengirimkan PR # 6037 yang memungkinkan Anda menggunakan konfigurasi untuk menghapus peringatan. Sampai sekarang, ini belum digabungkan; Saya menunggu tanggapan dari kontributor.

Masalah ini sangat membuat frustrasi, tetapi saya pikir saya telah menemukan solusi yang bagus yang menghasilkan konvensi penamaan yang lebih bersih.

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

Ini akan memungkinkan Anda untuk membuat tiruan anything.ts dengan membuat saudara kandung anything.mock.ts dan menambahkan path ke aslinya dalam array test.mocks mockedModules .

Mengapa masalah ini ditandai sebagai peningkatan?

Sepertinya ini berhasil untuk saya. di jest.config.js:

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

Saya tidak yakin dengan cakupan atau dampak dari perubahan ini, karena saya memiliki proyek kecil.

@ amccloud terima kasih! Ini memecahkan masalah saya! Detail di bawah.

Saya memiliki modul helpers di direktori root proyek saya. Pembantu sedang mengekspor fungsi parseNodeFromString .
Saya telah membuat di beberapa file lokal modul lain helpers . Kemudian saya mengejeknya untuk salah satu ujian saya. Dan semua pengujian yang menggunakan fungsi parseNodeFromString mulai gagal dengan kesalahan berikut:

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

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

Bagaimana dengan masalah ini? Sepertinya solusi @amccloud sudah benar.

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

Solusi ini berfungsi meskipun itu membuat tiruan tingkat atas saya untuk modul node gagal. Jadi saya mengubahnya untuk tidak mengabaikan folder root __mock__ saya dengan: "modulePathIgnorePatterns": ["<rootDir>/src/react/.*/__mocks__"], . Masih cukup aneh bahwa tiruan tidak hanya unik berdasarkan jalur lengkap dari root. Sangat umum untuk memiliki: users/helper.js & posts/helper.js . Peringatan itu membutuhkan cukup banyak ruang, dan saya tidak ingin menyembunyikan peringatan sebenarnya.

Lalu bagaimana status PR saat ini? Apakah ada solusi yang tepat atau hanya beberapa peretasan?

Dalam kasus saya, modul tiruan disalin ke dir Dist dengan setiap build.

Sepertinya ini adalah masalah dengan skrip ketikan yang tidak dapat mengecualikan jalur / pola yang termasuk dalam struktur dir yang lebih dalam. Ini masih masalah dengan "typescript@^3.4.5".

Untuk mengatasinya, saya mulai membersihkan direktori Dist saya dengan "rimraf dist" sebelum setiap pengujian dijalankan.

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

Saya tahu ini hack, tapi berhasil.

Hei saya memecahkan ini di sini adalah apa yang terjadi, dan mungkin itu dapat membantu Anda menduplikasi ini.

tiga solusi atau skenario:

1, Saya mengedit aplikasi saya di editor teks saya dua kali yang berarti, saya menjalankan pod install / update dan react-native run-ios dari dua jendela berbeda. dan saya mendapat kesalahan ini, saya mencoba mencari file duplikat di Xcode dan di aplikasi saya tetapi saya tidak dapat menemukannya. jadi saya hanya menghapus aplikasi dari simulator dan menjalankan kembali react-native run-ios dan berhasil, Ternyata dua node_modules telah diduplikasi seperti: node_modules dan node_modules0 di file scr saya.

2, kadang-kadang ketika saya menekan tombol acak pada mac saya node_modules diduplikasi misalnya di folder SRC jadi ini juga menjadi kasusnya, jadi masuk akal untuk melihat folder Anda untuk setiap duplikasi node_modules.

3, Saya tidak dapat menjalankan aplikasi hingga saya meluncurkan dan menghentikan aplikasi yang berbeda pada simulator yang sama, lalu saya mem-boot ulang aplikasi dengan duplikasi yang kemudian dijalankan tanpa kesalahan.

Tetap tidak ada? Tidak dapat menggunakan modulePathIgnorePatterns di CRA

3 tahun 10 bulan

Atau, alangkah baiknya jika kita bisa memaksa Jest untuk membuat kesalahan saat masalah ini muncul, daripada hanya memberi peringatan. Peringatan mudah diabaikan; pada proyek saya, saya lebih suka kesalahan dilemparkan, jadi pengembang yang memperkenalkannya harus menanganinya.