Jest: Dukungan untuk RequireJS

Dibuat pada 15 Mei 2014  ·  84Komentar  ·  Sumber: facebook/jest

Jika saya memahaminya dengan benar, saat ini tidak ada cara untuk menggunakan ini dengan RequireJS daripada gaya CommonJS require(). Apakah ada rencana untuk menambahkan dukungan untuk RequireJS? Apakah itu bahkan layak?

Komentar yang paling membantu

babel-plugin-transform-AMD-to-commonjs terbukti berguna untuk memecahkan masalah Jest+AMD, terutama jika Anda sudah menggunakan sesuatu seperti babel-jest.

Saya telah menyiapkan proyek contoh yang menunjukkan bagaimana Anda dapat membuat Jest secara transparan membutuhkan file AMD dengan menjalankan transformasi di lingkungan pengujian.

Saya tidak yakin dengan detail pendekatan semacam itu dalam proyek aktual - khususnya pendekatan yang baik untuk berbagi konfigurasi antara Jest/RequireJS/Webpack/etc. Dukungan lelucon untuk file konfigurasi .js akan menjadi langkah menuju solusi yang lebih dapat digunakan kembali (lihat https://github.com/facebook/jest/issues/2140).

Semua 84 komentar

++

Ada di peta jalan kami untuk mendukung pengaya sistem modul untuk Jest (seperti require.js, modul es6, dll), tetapi sayangnya kami belum cukup sampai di sana.

Mari biarkan masalah ini terbuka untuk melacak kemajuan dalam hal ini -- saya pikir akan sangat berguna untuk mendukung pemuat require.js

@jeffmo webpack mendukung commonjs/es6/amd. Jika kita bisa membawa lelucon sebagai plugin, kita mungkin bisa mendapatkan semua itu secara gratis.

++

kami memiliki banyak proyek di organisasi besar dan berencana untuk menggunakan lelucon tetapi kami 100% membutuhkan. Adakah eta pada integrasi requirejs?

++

Saya juga ingin mencoba lelucon, tetapi proyek saya saat ini menggunakan RequireJS.

:+1:

Seseorang menyarankan menggunakan ini sebagai shim, apakah ada yang mencobanya?

https://github.com/Jakobo/redefinine

_Layak dengan peringatan_. Saya menerapkan sedikit build dengan nodefy di beberapa repo acak yang bisa melakukan trik sebagai stop-gap. Lihat scripts.cjs di bawah paket .

Tes lakmus: Alias ​​modul AMD Anda sejajar dengan modul yang sesuai di bawah node_modules . Jika tes lakmus gagal, tetapi Anda putus asa, Anda dapat membuat simpul modul AMD murni dan/atau menambahkan symlink ke node_modules, tetapi gagasan itu membuat saya sedih. Dari sudut pandang saya, eksternal yang saya gunakan cenderung menerapkan UMD dan menginstal dengan npm ke nama yang selaras dengan alias AMD saya--bukan masalah besar.

(Saya memeriksa uRequire sebelum nodefy, tetapi template CommonJS membuatnya secara fungsional setara dengan nodefy--Saya akan menggunakan alat yang ditargetkan. Saya juga memeriksa amdefine, tetapi bercanda menggunakan pencocokan regex pada 'require'--mungkin ada AMD anonim sudut? Selalu ada UMD, tetapi mengkode UMD dengan referensi document tersebar terdengar seperti perilaku yang buruk.)

+1

++

Kami menggunakan react, backbone, dan requirejs di semua kode sisi klien baru kami. Saya akan senang bisa menggunakan lelucon dan meringankan beberapa rasa sakit dari reaksi pengujian. Akan menyenangkan untuk menurunkan semuanya ke tingkat unit. Saat ini pengujian kami untuk kode reaksi sedang dilakukan dengan rspec dan webdriver. Meskipun ini berhasil, ini kurang ideal karena alasan yang jelas.

Apakah ada solusi praktis belum? Masalah utama yang saya hadapi adalah pernyataan define yang membungkus komponen reaksi.

+1

@petehunt Mengaktifkan saya ke Webpack, jadi ini adalah sesuatu yang perlu dipertimbangkan juga.

+1

Dapatkah seseorang mengarahkan saya ke contoh melati/webpack atau lelucon/webpack yang menjalankan tes browser dengan cakupan kode?

++

Kapan kami dapat mengharapkan dukungan untuk requirejs ?

+1

+1

+1

+1

+1

+1

Jika Anda menggunakan module.exports alih-alih kembali untuk panggilan definisi Anda, Anda dapat menambahkan ini ke praprosesor Anda.

Bekerja untuk saya :thumbup:

// preprocessor.js
var ReactTools = require('react-tools');
module.exports = {
  process: function(src) {
    if (/define\(.*?\{/.test(src)) {
      //Remove AMD ceremony for use without require.js or almond.js
      src = src.replace(/define\(.*?\{/, '')
        .replace(/(}\);|}\))$/,'');
    }

    return ReactTools.transform(src);
  }
};

++

+1

+1

+1 untuk dukungan RequireJS

+1

@charliedowler Maukah Anda mengilustrasikan lebih banyak pendekatan ini. Saya mencobanya dan mengalami beberapa masalah. Saya mulai dengan menambahkan

if (typeof(module) == 'object' && module.exports) { module.exports = <my_element>;  }

Namun, saya menggunakan return , jadi saya mendapatkan kesalahan parser dari pra-prosesor. Saya pikir saya bisa lolos dengan memperluas RegEx agar juga cocok dengan pengembalian terakhir. Tapi sepertinya tidak berfungsi sama sekali. Saya terus mendapatkan kesalahan "pernyataan pengembalian ilegal". Mungkin ada yang salah dengan ekspresinya, dan itu tidak menangkapnya.

if (/define\(.*?\{/.test(src)) {
  src = src.replace(/(define\(.*?\{|return.*[\s]}\);?$)/g,'');  
}

Apakah ada cara bagi saya untuk menulis src ke stdout? Console.log sederhana tidak berfungsi.

Dan terakhir, dengan asumsi saya mendapatkan semua ini untuk bekerja. Bagaimana Anda menangani dependensi? Seperti misalnya Bereaksi?

+1

Ah! Saya telah bermain dengan (dan sangat menikmati lelucon). Mencoba menariknya ke dalam proyek aktual hari ini dan tidak menemukan dukungan requireJS :sob: ... deal breaker untuk semua proyek "nyata" saat ini. Sedih memang. Itu pasti ide yang menarik!

:+1:

+1

+1

:+1:

:jempolan:

:+1:

:+1:

Jadi saya telah menyelesaikan ini dengan menggunakan webpack untuk mengkompilasi modul AMD saya dan menguji bersama. Ini memungkinkan saya untuk juga menggunakan semua jenis pemuat tambahan dengan pengujian saya. https://github.com/ninjapanzer/Backbone-Flux-React-Webpack

:+1:

+1

+1

+1

Terima kasih telah melaporkan masalah ini dan terima kasih atas kesabaran Anda. Kami telah memberi tahu tim inti untuk pembaruan tentang masalah ini. Kami sedang mencari tanggapan dalam 30 hari ke depan atau masalah ini mungkin sudah selesai.

+1

@facebook-github-bot-4 tolong lakukan!

+1

+1

++

Saya telah mengerjakan Jestpack yang merupakan pengganti 'HasteModuleLoader' Jest untuk mendukung Webpack. Hasilnya, Anda dapat menggunakan sistem modul apa pun yang didukung Webpack termasuk AMD.

Di samping catatan apakah ada yang tahu tentang proyek open source besar (ish) yang menggunakan Jest selain yang menggunakan modul tergesa-gesa gaya FB karena akan sangat berguna untuk menguji kinerja Jestpack?

Saya juga telah mengerjakan jest-requirejs yang lebih merupakan upaya praprosesor lelucon standar yang menganalisis file konfigurasi proyek main.js kemudian melakukan deamdify , yang menghapus define wrapper, menulis ulang jalur yang diperlukan berdasarkan detail dari baseUrl dan jalur yang ditentukan main.js, lalu meneruskan file yang diubah ke lelucon seperti biasa.

Masih mengerjakan sintaks plugin/loader, dan menulis ulang jalur jest.dontMock("") , jest.setMock("") dan require.requireActual("") di dalam lingkungan pengujian.

Hei teman-teman ini benar-benar luar biasa. Saya menyukai ide Jestpack dan saya bermaksud membuatnya lebih mudah untuk mendukung resolver modul tambahan. Akhirnya saya juga ingin mengubah situs web dan merekomendasikan solusi seperti Jestpack sebagai bagian dari panduan Memulai (yang ada di kepala saya :)). @richardscarrott dan @sterpe tolong beri tahu saya jika Anda butuh sesuatu.

Juga cc @mwolson dan @ColCh

(Kepada semua orang: tolong hentikan upvoting komentar, itu tidak membantu. Jika Anda menginginkan sesuatu yang dibuat untuk lelucon, silakan kirim permintaan tarik. Kode memenangkan argumen! Secara pribadi saya tidak dapat memprioritaskan fitur hanya karena orang-orang di komunitas membutuhkannya dan saya jangan gunakan _semua pemuat modul_ yang ada di luar sana sendiri.).

Jestpack menarik, meskipun saya tidak suka harus membuat satu titik masuk per tes. https://github.com/Ticketmaster/jest-webpack-alias memecahkan masalah sedikit lebih umum, dengan mengorbankan beberapa pra-pemrosesan, dan kemungkinan bug yang belum ditemukan karena mengimplementasikan kembali kode resolusi modul webpack.

Juga: Panduan Memulai mungkin harus menyebutkan bahwa merupakan ide bagus untuk membatasi file mana yang dijalankan oleh praprosesor Anda, jika Anda memilikinya, jika tidak, akan sangat memperlambat pengujian.

praprosesor hanya dijalankan sekali dan Anda dapat menyediakan fungsi kunci cache. lelucon tidak akan menjalankan kembali praprosesor Anda jika file tidak berubah.

Itu mungkin, tetapi bahkan menjalankan pertama sudah cukup untuk menambahkan sekitar ~10 detik untuk eksekusi rangkaian pengujian kami.

Setuju bahwa itu tidak cepat. Di FB, proses pertama memakan waktu hampir dua kali lebih lama dari proses berikutnya, tetapi secara pribadi saya tidak melihat yang lain untuk menyelesaikan ini – kami menggunakan babel dan transformasi khusus lainnya di FB; kami tidak dapat menjalankan tes tanpa preprosesor :)

Caching preprocessor menggigit saya saat mengembangkan preprocessor requirejs. Saya kebanyakan masih menggunakan [email protected] yang tidak memiliki caching, saya percaya?

Ini harus bekerja dengan baik dengan 0,5!

Webpack sangat cepat dalam mode dev-watch.

Karena:

  1. Webpack menyimpan runtime mereka di memori (tanpa memuat ulang)
  2. Kode sumber yang dikompilasi terletak di memori juga.

Jadi, di preprocessor Jest saya, saya hanya menerapkan (2) poin.

Singkatnya, sebuah paket ( Jestpack , benar ...) di atas Jest dan Webpack akan menyelesaikan semua masalah dengan kinerja - simpan saja runtime Jest dan Webpack di memori, kompilasi file di memori FS dan jalankan kasus uji di memori FS .

Itu sudut pandang saya...

Tapi kami memiliki masalah lain sekarang: Tidak mungkin untuk memasukkan memori FS ke Jest untuk saat ini.

Saya berpikir untuk menggunakan API cache Jest pribadi - untuk menyuntikkan sumber yang dikompilasi langsung ke cache. Mungkin ini peretasan, jadi saya salah di sini: jest-webpack/issues/4#issuecomment-98623189

Ah, saya harus menyebutkan, bahwa Karma dengan Webpack sebagai praprosesor juga bekerja sangat lambat. Jadi, saya pikir penurunan kinerja utama adalah karena runtime webpack memuat ulang antar file.

@cpojer Saya pikir itu adalah niat Anda untuk akhirnya membuat pemuat modul dapat dikonfigurasi karena sudah dipilih jadi saya pikir saya akan mencobanya dengan Jestpack. Satu-satunya masalah nyata yang saya hadapi adalah memahami logika untuk menemukan tiruan manual untuk node_modules https://github.com/facebook/jest/issues/509 , saya akhirnya hanya menggunakan solusi yang masuk akal bagi saya tetapi jika Anda ' Anda dapat memberikan wawasan apa pun tentang masalah itu, alangkah baiknya untuk menyelaraskan pemuat modul Jestpack dengan HasteModuleLoader.

@mwolson Alasan Jestpack menggunakan titik masuk terpisah per file pengujian adalah untuk memastikannya masih dapat memanfaatkan multi proses Jest.

moduleLoader sudah dapat ditentukan sebagai bagian dari konfigurasi.

++

Kami akan seperti ini juga. Jest tampak seperti perangkat lunak yang luar biasa tetapi tidak dapat menulis ulang semua yang harus kami pertanggungjawabkan tanpa dukungan RequireJS.

+1

Adakah dari komunitas yang tertarik untuk mengerjakan ini? Saya akan dengan senang hati mendukung orang melalui ini dan membuat plugin Jest resmi. Sepertinya kami tidak akan banyak berinvestasi dalam hal ini di FB dalam waktu dekat. Tim Jest sangat kecil (1,5 orang) dan sayangnya kami tidak dapat mengerjakan semua fitur ini.

Berdasarkan keadaan komunitas dan standar JavaScript saat ini, sepertinya require js sendiri tidak memiliki masa depan yang besar untuk membuat kode JavaScript. Kami sekarang memiliki sistem modul standar di ES2015. Babel dan Jest sekarang terintegrasi penuh dan bekerja sama dengan baik. Saya akan merekomendasikan siapa pun untuk beralih ke modul CommonJS atau ES2015, yang akan membuat lebih banyak perkakas tersedia untuk Anda di luar kotak.

memerlukan JS juga memiliki dokumen di sini tentang cara mengonversi CommonJS ke require.js yang dapat digunakan untuk penyebaran produksi, lihat: http://requirejs.org/docs/commonjs.html

Secara pribadi saya tidak melihat keuntungan dalam penulisan kode menggunakan JS yang dibutuhkan. Saya juga akan dengan senang hati membantu menulis codemod yang dapat membantu mengubah basis kode JS yang diperlukan ke CommonJS. Tantangan lainnya adalah menulis plugin babel requireJS ke CommonJS dan mengambilnya ke dalam preprosesor Jest.

@cpojer Saya agak berhasil dengan pendekatan praprosesor di sini https://github.com/sterpe/jest-requirejs/blob/master/index.js tetapi sejauh ini hanya mengimplementasikan transformasi untuk !text/ plugins. Tim kami pindah dari requirejs sepenuhnya jadi saya tidak punya alasan untuk melanjutkan jalan itu.

Saya setuju, saya melihat sedikit nilai dalam menggunakan RequireJS untuk membuat kode. Masuk akal bagi saya untuk mengkompilasi kode modul CommonJS/ES2015 ke requirejs untuk produksi, tetapi sepertinya tidak bagus untuk menulis kode dengan gaya ini secara manual.

Saya baru saja melakukan migrasi dari RequireJS ke webpack. Ada lebih dari 300 komponen dalam basis kode kami. Seluruh proses itu sangat mudah dan tidak menyakitkan.

Alat yang saya gunakan adalah https://github.com/Skookum/recast-to-cjs untuk mengonversi kode dari AMD ke gaya CommonJS.

Juga dengan bantuan https://github.com/facebook/jscodeshift , kami memigrasikan basis kode kami dari React 0.11 ke 0.14 dalam beberapa hari.

Semoga ini bisa membantu seseorang dalam situasi yang sama.

@tendan bagus! Itulah yang saya bicarakan sebelumnya :) Senang itu bekerja dengan baik untuk Anda.

Karena ini ditutup, apakah itu berarti Facebook tidak akan menambahkan dukungan untuk ini?

Jika yang Anda maksud dengan Facebook adalah saya, maka ya, kecil kemungkinan akan ada dukungan "resmi". Itu seharusnya tidak mencegah Anda berkontribusi pada Jest dan memasukkan fitur ini, tetapi saya yakin kebanyakan orang telah beralih ke modul ES atau CommonJS hari ini.

Ya aku tahu. Sayangnya, saya tidak dapat beralih dari dependensi ini karena ini untuk pekerjaan.

babel-plugin-transform-AMD-to-commonjs terbukti berguna untuk memecahkan masalah Jest+AMD, terutama jika Anda sudah menggunakan sesuatu seperti babel-jest.

Saya telah menyiapkan proyek contoh yang menunjukkan bagaimana Anda dapat membuat Jest secara transparan membutuhkan file AMD dengan menjalankan transformasi di lingkungan pengujian.

Saya tidak yakin dengan detail pendekatan semacam itu dalam proyek aktual - khususnya pendekatan yang baik untuk berbagi konfigurasi antara Jest/RequireJS/Webpack/etc. Dukungan lelucon untuk file konfigurasi .js akan menjadi langkah menuju solusi yang lebih dapat digunakan kembali (lihat https://github.com/facebook/jest/issues/2140).

@msrose ini luar biasa. Terima kasih banyak telah berbagi ini.

Saya mengerti ini adalah masalah lama. Transformasi sederhana dapat berhasil:

exports.process = function (content) {
  return 'function define(name, deps, body) { module.exports = body.apply(undefined, deps.map(require)); }' + content;
}

Saya pikir transformasi AMD -> CJS dapat dilakukan dengan berbagai cara, misalnya deamdify , pembungkus yang disuntikkan, dll. Masalahnya, masih belum terpecahkan, adalah sintaksis pemuat/plugin gaya yang dibutuhkan. Itu hal-hal seperti fooTemplate = require('tpl!foo.tpl') dan barJson = require('json!bar.json') (sebagai yang relatif umum). Tetapi ada cukup banyak dari ini dan proyek require-js dunia nyata dipenuhi dengan sintaks semacam ini.

Akan sangat bagus jika ada cara mudah untuk langsung menggunakan kembali plugin require-js di sistem transformasi yang pada akhirnya dimasukkan ke dalam pemuat modul jest |.

+1

ReferenceError: define is not defined

+1

GAGAL srcApp.test.js
● Test suite gagal dijalankan

ReferenceError: define is not defined

Anda harus menggunakan umd alih-alih amd. Jika itu tidak memungkinkan, Anda harus menambahkan transformasi (misalnya plugin babel yang ditautkan di atas).

Ketika datang ke sintaks loader! , kami tidak akan mendukungnya (kami juga tidak mendukungnya untuk Webpack). Solusinya adalah mengubah impor (menghapus loader) dan membiarkan Jest berubah menggunakan konfigurasi transform . Diskusi terkait: #4868

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

ticky picture ticky  ·  3Komentar

Secretmapper picture Secretmapper  ·  3Komentar

stephenlautier picture stephenlautier  ·  3Komentar

hramos picture hramos  ·  3Komentar

paularmstrong picture paularmstrong  ·  3Komentar