Pikiran awal dari atas kepala saya, sebelum melakukan penelitian lebih lanjut:

• Sepertinya saya ingat orang-orang Node secara khusus mengubah standar untuk memungkinkan kompatibilitas mundur dengan modul CommonJS. Jika itu (masih?) benar, maka saya berharap pada akhirnya itu akan didukung tanpa perlu melakukan apa pun dengan/ke Mocha. (Dan dengan "akhirnya" maksud saya "bahkan mungkin lebih cepat daripada perubahan Mocha", mengingat tingkat siklus rilis Node; lihat yang ditekankan, kedua dari belakang di bawah untuk penjelasan yang lebih rinci tentang ini.)
• Bisakah saya berasumsi bahwa ini dijalankan seperti node --experimental-modules node_modules/mocha/bin/_mocha ?
• Bagaimana tepatnya .jsx terlibat? Saya melihat bahwa contoh kesalahan yang ditampilkan mengacu pada .mjs ; tidak jelas dari apa yang telah diposting, di mana jsx itu.
• Saya juga samar-samar ingat pernah mendengar implementasi awal Node yang membutuhkan ekstensi file .mjs ; jika itu (masih?) benar, dan jika Anda mencoba menggunakan import / export dengan file .jsx (baik import dengan .jsx dalam file .mjs atau memuat file .jsx yang berisi import / export ), mungkinkah itu masalahnya daripada Mocha?
• Kami perlu menemukan cara untuk memastikan bahwa perubahan pada fitur eksperimental tidak memerlukan perubahan pada Mocha yang harus menunggu semver mayor -- jika tidak, Anda dapat kembali ke tempat kami sekarang kecuali menunggu lebih lama lagi (karena siklus rilis utama Mocha tidak dikunci hingga dua kali setahun seperti Node).
• Berbicara murni dari pendapat saya sendiri dan bukan atas nama tim, jika format modul baru tidak dapat beroperasi dengan format modul lama tanpa modifikasi pustaka yang ada yang ditulis dalam format lama, maka format modul baru belum siap .

Sepertinya saya ingat orang-orang Node secara khusus mengubah standar untuk memungkinkan kompatibilitas mundur dengan modul CommonJS. Jika itu (masih?) benar, maka saya berharap pada akhirnya itu akan didukung tanpa perlu melakukan apa pun dengan/ke Mocha. (Dan dengan "akhirnya" maksud saya "bahkan mungkin lebih cepat daripada perubahan Mocha", mengingat tingkat siklus rilis Node; lihat yang ditekankan, kedua dari belakang di bawah untuk penjelasan yang lebih rinci tentang ini.)

Dari penelitian saya (kecil) tampaknya setidaknya untuk saat ini diperbolehkan menggunakan require dari modul ECMAScript tetapi tidak import dari modul commonjs.

Bisakah saya berasumsi bahwa ini dijalankan seperti node --experimental-modules node_modules/mocha/bin/_mocha?
Bagaimana tepatnya .jsx terlibat? Saya melihat bahwa contoh kesalahan yang ditampilkan mengacu pada .mjs; ga jelas dari yg udah dipost, jsx nya dimana.

Ya, itu dijalankan dengan --experimental-modules . jsx salah ketik, maksud saya mjs , akan memperbarui posting awal.

Saya juga samar-samar ingat pernah mendengar implementasi awal Node yang membutuhkan ekstensi file .mjs; jika itu (masih?) benar, dan jika Anda mencoba menggunakan impor/ekspor dengan file .jsx (mengimpor file .jsx dalam file .mjs atau memuat file .jsx yang berisi impor/ekspor), bisakah itu menjadi masalah daripada Mocha?

Masalahnya tampaknya, dan saya mungkin kehilangan sesuatu di sini, bahwa moka menggunakan require untuk memuat tes (itu setidaknya asumsi saya saat ini karena saya bukan ahli moka, lebih dari pengguna) yang kemudian termasuk modul lain melalui import . Ini dalam hubungannya dengan poin pertama akan menjelaskan kesalahan.

Kami perlu menemukan cara untuk memastikan bahwa perubahan pada fitur eksperimental tidak memerlukan perubahan pada Mocha yang harus menunggu semver mayor -- jika tidak, Anda dapat kembali ke tempat kami sekarang kecuali menunggu lebih lama lagi (karena siklus rilis utama Mocha tidak terkunci dua kali setahun seperti Node).
Berbicara murni dari pendapat saya sendiri dan bukan atas nama tim, jika format modul baru tidak dapat beroperasi dengan format modul lama tanpa modifikasi pustaka yang ada yang ditulis dalam format lama, maka format modul baru belum siap.

Saya takut ini akan menjadi jawabannya dan saya mengerti bahwa ini bukan prioritas utama. Jika asumsi saya tentang penyebab kesalahan di atas benar, sesuatu seperti #956 dapat membantu karena titik masuk pengujian dapat berupa modul mjs daripada commonjs yang mungkin sulit dicapai sebaliknya. Tampaknya ada di peta jalan tim nodejs untuk mendukung import dari modul saat ini, namun tidak jelas tentang garis waktu.

Dari penelitian (kecil) saya, tampaknya setidaknya untuk saat ini diizinkan untuk menggunakan require dari modul ECMAScript tetapi tidak mengimpor dari modul commonjs.

Tampaknya ada di peta jalan tim nodejs untuk mendukung impor dari modul saat ini, namun tidak jelas tentang garis waktu.

Untuk memperjelas: mengingat bahwa dalam lingkungan "yang lebih lama" (dalam beberapa kasus saat ini non-eksperimental) import adalah kesalahan sintaks, yang tidak dapat dihindari dengan logika percabangan atau semacamnya, yang dibutuhkan Mocha bukanlah untuk dapat menggunakan import itu sendiri melainkan untuk dapat menggunakan require untuk memuat modul yang menggunakan (atau yang menggunakan modul yang menggunakan) format baru.

jsx salah ketik, maksud saya mjs , akan memperbarui posting awal.

Terima kasih, itu menghilangkan satu kemungkinan sudut!

Jika asumsi saya tentang penyebab kesalahan di atas benar, sesuatu seperti #956 dapat membantu karena titik masuk pengujian dapat berupa modul mjs daripada commonjs yang mungkin sulit dicapai sebaliknya.

Sayangnya, membuat Mocha tidak membuat variabel global tidak mungkin tanpa penulisan ulang ekstensif dari beberapa internal yang lebih misterius (saya mencoba dan tidak dapat menemukannya sendiri ); namun, menggunakan titik masuk JS Anda sendiri sekarang dimungkinkan melalui API "terprogram" (yang mungkin tidak didokumentasikan di luar halaman wiki lama dan komentar JSDoc di file sumber, tetapi didukung secara resmi):

// test.mjs
var Mocha = require('mocha'),
var mocha = new Mocha();

// your mission: create a file `example.mjs`
// in the `test` folder and have it `import` stuff
// as well as using `describe` and `it` to make tests
mocha.addFile("./test/example.mjs");

mocha.run(function(failures){
  process.on('exit', function () {
    process.exit(failures ? 1 : 0);
  });
});

node --experimental-modules test.mjs

Saya belum benar-benar mencobanya untuk melihat apakah itu membuat perbedaan (perlu mengambil Node versi terbaru terlebih dahulu), tetapi beri tahu saya jika itu berhasil untuk Anda ...

Pertama-tama terima kasih atas dukungan Anda dalam hal ini!

Saya mencoba ini

// runner.mjs
import Mocha from 'mocha';
var mocha = new Mocha();

// your mission: create a file `example.mjs`
// in the `test` folder and have it `import` stuff
// as well as using `describe` and `it` to make tests
mocha.addFile('./test/frontend/components/global/test.mjs');

mocha.run(function (failures) {
    process.on('exit', function () {
        process.exit(failures ? 1 : 0);
    });
});

Jadi pada dasarnya membuat titik masuk simpul sebagai modul ECMAScript.

Saya menjalankannya melalui node --experimental-modules --harmony ./runner.mjs

saya mendapat

(node:88620) ExperimentalWarning: The ESM module loader is experimental.
{ Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /.../test/frontend/components/global/test.mjs
    at Object.Module._extensions..mjs (module.js:658:11)
    at Module.load (module.js:545:32)
    at tryModuleLoad (module.js:508:12)
    at Function.Module._load (module.js:500:3)

apa yang dibutuhkan Mocha bukanlah untuk dapat menggunakan import itu sendiri melainkan untuk dapat menggunakan require untuk memuat modul yang menggunakan (atau yang menggunakan modul yang menggunakan) format baru.

Saya khawatir saat ini tidak memungkinkan di simpul, Anda hanya dapat menggunakan require dalam modul yang Anda impor melalui import . Apakah ada cara untuk menghindari mocha.addFile('./test/frontend/components/global/test.mjs'); dan sebagai gantinya mengimpor tes dan menambahkan skrip yang diimpor seperti ini

import test from './test';
mocha.addTest(test);

?

Tidak ada fungsi seperti itu di Mocha saat ini, tetapi Anda dapat melakukan sesuatu seperti itu. addFile hanya menambahkan file ke daftar yang kemudian require d oleh fungsi run . Fungsi run memanggil loadFiles ke require mereka:

https://github.com/mochajs/mocha/blob/1cc0fc0e6153bbd746b0c2da565363570432cdf7/lib/mocha.js#L220 -L235

Apa yang ingin Anda lakukan adalah untuk file apa pun yang perlu import ed alih-alih require d jangan panggil addFile (jadi Mocha tidak akan mencoba require pada run ) dan sebagai gantinya sebelum memanggil run panggil beberapa kode yang seperti apa yang ada di loadFiles tetapi menggunakan import alih-alih require . Saya tidak ingat dari atas kepala saya apakah ada batasan penggunaan import yang akan mencegah hal ini, tetapi jika memungkinkan maka saya membayangkan itu akan terlihat cukup dekat dengan:

modules.forEach(function (file) {
  file = path.resolve(file);
  mocha.suite.emit('pre-require', global, file, mocha);
  import fileExport from file; // fileExport is used by the exports interface, not sure if anything else; most interfaces act as a side effect of running the file
  mocha.suite.emit('require', fileExport, file, mocha);
  mocha.suite.emit('post-require', global, file, mocha);
});

Anda juga dapat melihat bagaimana https://github.com/mochajs/mocha/blob/master/bin/_mocha menggunakan API terprogram Mocha untuk memahami cara menyediakan opsi lain dan cara menggunakan hal-hal seperti fungsionalitas pencarian file Mocha. Ini tidak terorganisir dengan baik tetapi semua yang dilakukan antarmuka baris perintah ada di sana (baik secara langsung atau karena ada panggilan ke fungsi-fungsi di API program Mocha).

Saya dapat melangkah lebih jauh tetapi tes yang diimpor sekarang mengeluh tidak tahu tentang deskripsi ( ReferenceError: describe is not defined ). Bagaimana cara yang tepat untuk menyuntiknya? Jika aku melakukan

import Mocha from 'mocha';
const describe = Mocha.describe;

itu mengeluh TypeError: describe is not a function

Jadi, distro saya akhirnya mendapatkan NodeJS 8.5, dan saya memiliki kesempatan untuk bermain dengan ini dan mengkonfirmasi beberapa firasat yang saya miliki tetapi tidak ingin menyatakan sampai saya dapat memeriksa:

1. Saya tidak dapat menemukan cara untuk memuat modul ES tanpa hardcoding namanya dalam file skrip/modul. Itu berarti bahwa Mocha tidak dapat memuatnya melalui antarmuka baris perintah apa pun yang kami lakukan dan terlepas dari semantik ES vs. CommonJS lainnya. Jika dan kapan itu berubah, saya rasa kami ingin tahu. (Jika itu berubah sedemikian rupa sehingga modul ES dapat dimuat melalui variabel require kita mungkin tidak perlu mengubah apa pun, tetapi saya rasa kita tidak dapat mengatakan apa pun tentang cara kerja modul dengan pasti sampai itu terjadi .)
2. Sedangkan Mocha mengatur antarmuka dalam emisi peristiwa pre-require (bukan ketika modul pertama kali dimuat; antarmuka yang dipilih khusus untuk instance new Mocha ), sistem modul baru sebenarnya mem-parsing pohon ketergantungan dan memuat dependensi sebelum modul yang bergantung padanya, jadi alasan describe tidak ditentukan adalah karena Mocha tidak mengaturnya sampai setelah modul uji dimuat. Itu berarti akan berbelit-belit untuk membuat ini terjadi sama sekali (sekali lagi, kecuali dan sampai require(file) diizinkan dan memuat ketergantungan pada baris tertentu, lebih disukai secara sinkron sehingga kami tidak perlu mengubah apa pun ).

Namun, saya menemukan bahwa saya dapat membuatnya bekerja dengan memanfaatkan fakta bahwa modul import ed dimuat dalam urutan panggilan import . (Ini akan menjadi jauh lebih berlebihan jika Anda menggunakan antarmuka Ekspor atau reporter yang membutuhkan nama setiap file individual, seperti yang dijelaskan dalam kode yang akan saya tautkan, tetapi pada prinsipnya itu berfungsi.) Jika fakta itu benar untuk berubah tanpa salah satu dari fakta-fakta di atas berubah, maka ini pun tidak akan mungkin sama sekali. Tapi untuk saat ini saya pikir inilah yang harus Anda lakukan.

https://Gist.github.com/anonymous/caba0883254a2349c5615df8e9286665

node --experimental-modules ./run.mjs

Sayangnya, saya cukup yakin itulah yang terbaik yang dapat kami lakukan mengingat cara kerja modul ES dan apa yang diizinkan oleh Node saat ini.

Pikirkan dengan cara lain:

• import adalah sintaks.
• require adalah sebuah fungsi.

Anda tidak dapat secara dinamis import apa pun, sama seperti Anda tidak dapat menjalankan kode secara dinamis tanpa menggunakan, misalnya, eval() .

Ada proposal tahap 3 yang memungkinkan perilaku ini, tetapi saya tidak yakin apakah ada runtime yang mengirimkannya.

Dengan demikian, tidak ada cara bagi Mocha untuk mengimpor file .mjs saat dijalankan melalui mocha tanpa mungkin menambahkan @std/esm dan menggunakan implementasi require untuk file dengan .mjs ekstensi. Itu mungkin solusi yang layak dan sesuatu yang dapat kami pertimbangkan untuk didukung, tetapi diskusi (dan PR semacam itu) mungkin perlu datang dari komunitas, setidaknya sampai perilaku ini tidak ada di belakang bendera.

import describe from 'mocha' cukup rendah pada daftar prioritas, sayangnya, karena kesulitan yang melekat pada hal semacam ini (#956). Terbaik untuk dijalankan dengan node dan tetap menggunakan global.

Sebenarnya, terpikir oleh saya bahwa kami dapat memuat tes dan memanfaatkan vm.runInContext , dengan asumsi hal seperti itu mendukung modul. Karena perilaku pemuatan Node terkait dengan ekstensi .mjs , dan vm.runInContext mengharapkan string , jangan lihat bagaimana itu bisa--dan tidak ada yang disebutkan tentang ini di dokumen. Mungkin masalah di suatu tempat?

(sekali lagi, ini mungkin persis seperti yang dilakukan @std/esm !)

Saya memiliki tes moka yang berfungsi tanpa transpiler di browser . Mungkin itu membantu untuk masalah ini.

itu tidak terkait karena Anda tidak menggunakan moka sebagai modul, melainkan skrip ...

maaf bingung sendiri. itu berbeda di browser.

Saya ingin mempertimbangkan dengan suara dukungan untuk melakukan sesuatu untuk memungkinkan Mocha menjalankan tes yang terletak di Modul ES. Saya mendarat di sini setelah mencoba menulis tes semacam itu dan mendapatkan kesalahan aneh dari pemuat modul Node.js. Saya menggunakan Node.js 9.5, yang secara native mendukung modul ES6.

Seperti yang ada saat ini, Node.js 9.5 tidak mengizinkan modul CommonJS untuk membutuhkan() modul ES6. Mungkin mereka bekerja ke arah yang memungkinkan itu, saya tidak tahu.

Saya menulis tes sebagai modul ES6 dengan ekstensi .mjs dan mencoba menjalankannya. Mendapat kesalahan dari pemuat -- Saya berasumsi bahwa perintah mocha menghasilkan penggunaan require() dan itulah mengapa gagal.

Ulangi pengujian dengan ekstensi .js dan coba gunakan require() untuk memuat modul yang akan diuji. Itu juga mendapat kesalahan dari loader.

Saya berpendapat bahwa dunia Node.js perlu mempertimbangkan bagaimana mereka akan pindah dan mendukung modul ES6. Karena Mocha adalah alat yang sangat populer di dunia ini, sebaiknya tim Mocha mempertimbangkan cara mendukung modul ES6.

Untuk menindaklanjuti ... Setelah beberapa pemikiran dan pencarian saya bisa mendapatkan urutan ini untuk bekerja sebagai solusi.

Beri nama skrip pengujian dengan ekstensi .js (menjadikannya skrip CommonJS)

Kemudian tambahkan ini di skrip pengujian:

require = require("@std/esm")(module,{"esm":"js"});

Kemudian saya dapat require() modul ES sebagai berikut:

const model = require('../models/notes');

@robogeek Atau mungkin lebih baik menggunakan @std/esm preloader dari commandline, jadi Anda tidak perlu mengacaukan file spesifikasi Anda dengan solusi, dan dapat memiliki ekstensi .mjs .

mocha -r @std/esm spec.mjs

Impor dinamis dikirimkan dengan node v9.6 di belakang flag --harmony-dynamic-import . Impor dinamis memungkinkan moka memuat tes yang terkandung dalam modul es6 tanpa memerlukan transpiler.

@harrysarson Ini tidak akan berhasil. Mocha menggunakan modul cjs dan require , Anda harus menulis file uji menggunakan cjs, dengan beberapa kode lem tambahan untuk menangani sifat asinkron import . Atau apakah saya melewatkan sesuatu?

Saya adalah bot yang mengawasi masalah karena tidak aktif.
Masalah ini tidak memiliki aktivitas terbaru, dan saya melabelinya stale . Dalam 14 hari, jika tidak ada komentar atau aktivitas lebih lanjut, saya akan menutup masalah ini.
Terima kasih telah berkontribusi untuk Mocha!

Masalah ini masih relevan tetapi bergantung pada dukungan asli untuk ESM. Browser memilikinya, Node belum.

Saya hanya bermain-main, membiasakan diri dengan ESM/.mjs dan memutuskan bahwa saya memerlukan tes untuk mainan saya. Menyadari moka belum secara resmi mendukung file .mjs , saya bersama-sama melalui modul sementara cepat (sampai seseorang memiliki waktu untuk menambahkan dukungan penuh ke moka):

https://www.npmjs.com/package/mocha-esm
Selamat datang PR/Masalah: https://github.com/stefanpenner/mocha-esm

Mungkin ada sesuatu yang lebih baik di luar sana, tapi itu menyenangkan untuk dilalui bersama. jadi \o/

Saya memutuskan untuk melakukan fork mocha sendiri untuk mendukung impor dinamis (berdasarkan beberapa ide di atas, tetapi saya tidak dapat menjalankannya dengan cara lain).

Ini berarti Anda dapat menjalankan menggunakan misalnya node --experimental-modules --harmony-dynamic-import test.mjs

Kemudian di test.mjs :

import 'should';
import Mocha from 'mocha';

const mocha = new Mocha();

mocha.addFile(() => import("./some-module.spec.mjs"));

mocha.run(failures => {
  process.on('exit', function () {
    process.exit(failures ? 1 : 0);
  });
});

Saya menyimpan perubahan di mocha untuk mendukung minimal ini , dan saya tidak punya waktu untuk mengintegrasikan ini dengan benar untuk PR potensial saya juga tidak menambahkan modul npm khusus, tetapi Anda dapat menginstal garpu ini dari github langsung "mocha": "git+https://[email protected]/odolha/mocha" .

Perhatikan bahwa Anda dapat menggunakan pendekatan ini untuk memuat file dengan cara asinkron apa pun yang Anda inginkan, tidak hanya melalui impor dinamis, karena moka mengharapkan fungsi yang menyediakan Promise.

EDIT

Saya lupa menyebutkan bahwa pengujian Anda tidak boleh bukan skrip murni dengan pendekatan ini, karena kami tidak dapat menyuntikkan konteks, jadi Anda harus:

// some-module.psec.mjs
export const test = ({ describe, it }) => {
  describe('Something', () => {
    it('works', () => {
      ...
}

@odolha
Terima kasih telah menautkan garpu Anda.
Sudah ada PR untuk mendukung ESM asli tetapi ditutup karena dukungan modul masih eksperimental.

Implementasi Anda menghibur saya bahwa menambahkan dukungan untuk ini seharusnya mudah. Kami banyak yang menunggu dengan penuh semangat untuk fitur ini :)

@demurgos :no_mouth: ya... Saya baru lihat PR itu setelah saya melakukan hal saya sendiri, d'oh .

@harrysarson @boneskull
Paket esm (sebelumnya bernama @std/esm ) menjatuhkan dukungan .mjs file dalam komit ini .
Artinya tidak mungkin lagi menggunakannya dengan Mocha untuk menguji file .mjs . Ini dibahas dalam masalah ini .

Saya masih ingin dapat menguji modul ES sehingga saya dapat menjalankannya dengan aman di Node atau browser.

Mengenai diskusi modul saat ini, ada konsensus bahwa .mjs harus tersedia di hasil akhir (mungkin bukan sebagai satu-satunya solusi, tetapi setidaknya tersedia) dan bahwa import("./foo.mjs") akan mengembalikan janji untuk ruang nama ES yang sesuai. Fakta bahwa modul CJS dikonversi ke modul dengan ekspor default yang sesuai dengan module.exports lebih diperdebatkan, tetapi tampaknya merupakan asumsi yang aman.

Apakah mungkin untuk mempertimbangkan kembali untuk menambahkan dukungan ES asli menggunakan import dinamis ke Mocha? Bendera fitur dapat diubah namanya menjadi --experimental-es-modules (dari #3253) menjadi sinyal yang lebih baik bahwa ini bergantung pada kemajuan dukungan Node saat ini.
Menurut tenggat waktu, spesifikasi akhir tidak akan mendarat sampai Node 12 sehingga implementasi saat ini akan tetap ada untuk beberapa waktu (dan merupakan bagian yang relatif aman dari proposal akhir).

@demurgos Saya pribadi lebih suka menunggu ini sedikit lebih lama sebelum melakukan implementasi kode apa pun di moka. Tapi mungkin @boneskull atau @ScottFreeCode tidak setuju?

@demurgos

Paket esm (sebelumnya bernama @std/esm) menghapus file .mjs dukungan dalam komit ini.

esm loader tidak menghentikan dukungan untuk .mjs . Kami cukup mengikuti implementasi --experimental-modules saat ini dan membuat kesalahan saat mencoba memuat .mjs dengan require . Pengguna masih dapat menggunakan file .js untuk file entri pengujian mereka yang menggunakan sintaks ESM atau import() dinamis untuk memuat file pengujian berikutnya .mjs atau .js , banyak seperti yang dilakukan esm untuk pengujiannya sendiri .

Menurut tenggat waktu, spesifikasi akhir tidak akan mendarat hingga Node 12 sehingga implementasi saat ini akan tetap ada untuk beberapa waktu

Tidak ada waktu yang ditetapkan untuk --experimental-modules untuk mendarat tanpa bendera. Harapannya adalah bahwa itu dapat mendarat di siklus dukungan Node 10 _(jadi beberapa waktu dalam 2 tahun ke depan)_ tetapi tidak ada yang ditetapkan.

(dan merupakan bagian yang relatif aman dari proposal akhir).

Implementasi --experimental-modules saat ini mungkin tidak kompatibel dengan proposal akhir. Ada beberapa diskusi seputar seperti apa dukungan ESM di Node. Beberapa arah yang diusulkan tidak kompatibel dengan implementasi eksperimental saat ini. Bergantung pada bagaimana hal-hal mengguncang kode yang Anda tulis hari ini untuk --experimental-modules mungkin tidak berfungsi dengan apa pun bentuk akhirnya.

Pemuat esm tidak menjatuhkan dukungan untuk .mjs.

Maksud saya adalah esm tidak lagi memungkinkan membutuhkan .mjs sehingga Anda tidak lagi dapat menggunakan penemuan pengujian Mocha untuk .mjs . Tapi Anda benar, itu tidak didokumentasikan jadi itu bukan perubahan besar bahkan jika orang lain mengandalkannya.

Mengenai tenggat waktu, saya mengacu pada masalah ini . Tampaknya ada upaya untuk Node 11 dan implementasi akhir untuk Node 12 sehingga dapat di-porting ke Node 10 LTS. Beberapa berharap itu akan terjadi lebih cepat, yang lain memperingatkan untuk tidak terburu-buru.

Proposisi saya adalah menggabungkan #3253. Ini hanya menawarkan mekanisme keikutsertaan untuk menggunakan import(...) alih-alih require untuk memuat kasus uji. Karena saya berharap sebagian besar diterapkan untuk .mjs dalam konteks --experimental-modules , saya masih berpikir itu aman. (impor dinamis .mjs mengembalikan janji namespace kemungkinan akan tetap ada). Tetapi saya akan membiarkan Anda memutuskan apakah Anda dapat menggabungkannya dan menghindari terlalu banyak mendorongnya.

Sekali lagi, alasan utama untuk PR ini adalah karena tanpanya, Anda tidak lagi dapat menggunakan penemuan pengujian Mocha tetapi harus menggunakan solusi yang dijelaskan di atas oleh @jdalton. ( .js titik masuk dan impor manual)

Proposisi saya adalah menggabungkan #3253.

3253 memiliki beberapa kekurangan yang adil jelas bukan ide yang baik untuk menggabungkannya apa adanya.

Mengikuti contoh @jdalton , saya telah menyiapkan alur kerja kecil untuk menguji ESM asli tanpa paket esm (Node + Mocha murni).
Saya menggunakan definisi pengujian asinkron (menggunakan --delay ) dan --experimental-modules .

Saat ini, _mocha_ hanya dapat mengimpor CJS, dan CJS hanya dapat mengimpor ESM menggunakan fungsi semu import() dinamis. Jadi saya membuat titik masuk CJS berikut (namanya diakhiri dengan .js ) yang mengimpor file spesifikasi dan memicu eksekusi pengujian:

tes.esm.js :

(async () => {
  await import("./test/a.spec.mjs");
  await import("./test/b.spec.mjs");
  run();
})();

(Saya membuat titik masuk dengan daftar impor pada waktu pembuatan, tetapi Anda dapat menulisnya secara manual atau menggunakan glob di sana.)

Saya kemudian menjalankannya dengan perintah berikut:

NODE_OPTIONS="--experimental-modules" mocha --delay build/test/test.esm.js

Saya harus melewati NODE_OPTIONS karena flag tidak dikenali oleh mocha.

Saya masih berharap mocha akan memberikan dukungan yang lebih baik untuk ESM eksperimental, tetapi setidaknya senang mengetahui bahwa ada cara untuk menggunakannya hari ini tanpa alat lain.

@demurgos ini adalah solusi kecil yang bagus yang Anda temukan :+1:.

Adalah baik untuk melihat bahwa memang mungkin (jika tidak mudah) untuk menggunakan modul es dengan mocha : smile:.

@demurgos Masalah ini adalah tentang mendukung tes gaya ES6 tanpa penggunaan transpiler . Apa itu "waktu pembuatan"? Kode yang Anda gunakan untuk menghasilkan titik masuk pengujian adalah transpiler, hanya yang khusus.

@rulatir
Saya menyebutkan bahwa saya menggunakan alat build, tetapi itu bukan level yang dibahas dalam masalah ini: Mocha berjalan dengan ESM asli, bukan ESM yang diturunkan ke CJS oleh transpiler.

Lihat pesan saya:

Saya membuat titik masuk dengan daftar impor pada waktu pembuatan, tetapi Anda dapat menulisnya secara manual atau menggunakan glob di sana.

Saya menggunakan langkah build karena saya ingin impor saya (1) didefinisikan secara statis dan (2) tidak mempertahankan daftar itu sendiri.

Jika Anda hanya memiliki beberapa file spesifikasi, menjatuhkan (2) tidak masalah: cukup minta titik masuk untuk mengimpor 1-2 file spesifikasi Anda.
(1) sudah menjadi persyaratan khusus untuk file pengujian, jadi sebagian besar hanya "bagus untuk dimiliki" dan Anda dapat menggunakan glob saat runtime (alih-alih membangun waktu seperti saya). Ini hanya detail yang tidak penting pada akhirnya setelah Anda memahami ide intinya.

Jika Anda hanya menginginkan sesuatu seperti solusi salin-tempel sederhana yang menemukan file spesifikasi mjs saat runtime, berikut adalah contohnya:

const {sync: globSync} = require("glob");

(async () => {
  const matches = globSync("**/*.spec.mjs");
  for (const match of matches) {
    await import(match);
  }
  run();
})();

Jalankan dengan NODE_OPTIONS="--experimental-modules" mocha --delay test.esm.js .
Seperti yang Anda lihat, tidak ada build sama sekali, tetapi sedikit lebih banyak noise dalam kode.

Saya adalah bot yang mengawasi masalah karena tidak aktif.
Masalah ini tidak memiliki aktivitas terbaru, dan saya melabelinya stale . Dalam 14 hari, jika tidak ada komentar atau aktivitas lebih lanjut, saya akan menutup masalah ini.
Terima kasih telah berkontribusi untuk Mocha!

Masalah ini masih berlaku dan tidak boleh ditutup.

Rilis mocha@6 yang akan datang akan memiliki flag --experimental-modules yang masuk daftar putih yang memungkinkan untuk bereksperimen dengan modul ES6 dengan lebih mudah. Apakah mungkin untuk memiliki rilis minor atau patch sebelum v6? Saat ini saya sedang menyelesaikan alat cakupan baru yang menggunakan debugger V8 alih-alih Istanbul dan ingin mengujinya dengan modul Mocha dan ES6 (tanpa harus menggunakan ketergantungan git di package.json saya).

@demurgos

Ketika saya mencoba seperti ini ...

const {sync: globSync} = require("glob");
(async () => {
    const matches = globSync("**/*.spec.mjs");
    for (const match of matches) {
        await import(match);
    }
    run();
})();

saya mendapat

(node:4632) UnhandledPromiseRejectionWarning: Error: Cannot find module test/Sanity.spec.mjs

Tapi saat aku berlari seperti ini...

const {sync: globSync} = require("glob");
(async () => {
    await import("./Sanity.spec.mjs");
    run();
})();

Ini berjalan sempurna apa yang saya lewatkan?

@demurgos Anda harus berkoordinasi dengan @bcoe; lihat https://github.com/bcoe/c8

@demurgos untuk memotong rilis kecil, kita perlu memilih semua perubahan yang tidak melanggar sejak v5.2.0 menjadi cabang dan mengompilasinya ke dalam CHANGELOG. jika Anda atau orang lain bersedia melakukan pekerjaan itu, maka kami dapat memotong rilisnya.

fwiw Saya merekomendasikan esm lebih dari --experimental-modules sampai Node.js memiliki cerita yang lurus. itu akan menjadi penantian yang cukup besar.

@boneskull
Haha terima kasih. Saya sudah mengerjakan c8 sejak Juli (saya membuka banyak PR dan masalah pada repo ini). Ada juga beberapa keputusan desain di mana kami tidak setuju sehingga kami mencoba untuk berbagi sebagian besar dependensi (misalnya saya menulis algoritme penggabungan) dan memutuskan bahwa saya akan menerbitkan alat lain: c88 . Saya membuatnya berfungsi akhir minggu ini dan sekarang saya mengujinya di perpustakaan saya. Saya dapat menggunakannya dengan ESM dan moka asli di CI. Saya masih perlu waktu untuk mendokumentasikan dan memperbaikinya tetapi seharusnya sudah siap pada bulan Januari).

@jrgleason
Saya menulis kode di atas bagian atas kepala saya. Tampaknya masalahnya di sini adalah globSync mengembalikan jalur relatif yang tidak dimulai dengan ./ atau ../ . Anda mungkin ingin menambahkannya dengan ./ : itu harus bekerja dengan jalur relatif sederhana.
Anda juga harus memperhatikan bahwa impor dinamis menggunakan URL relatif: # , ? dan karakter khusus lainnya dapat ditangani secara berbeda. Jika Anda menginginkan solusi yang solid, Anda harus menyelesaikan jalur absolut modul dan kemudian mengonversinya menjadi URL file. Sebagai bagian dari pekerjaan saya pada cakupan, saya menulis lib untuk mengkonversi antara jalur absolut dan URL: Anda mungkin ingin menggunakan fromSysPath dari furi . Konversi harus menangani segala jenis jalur (bahkan ruang nama Windows dan jalur UNC...).

Berikut adalah contoh lengkapnya:

const {fromSysPath} = require("furi");
const {sync: globSync} = require("glob");
const {resolve} = require("path");

(async () => {
    const matches = globSync("**/*.spec.mjs");
    for (const match of matches) {
        await import(fromSysPath(resolve(match)).href);
    }
    run();
})();

Maksud saya, bukankah mocha --require esm hanya berfungsi ? Apakah kita benar-benar membutuhkan deteksi otomatis? Kedengarannya sulit dan menambah overhead ...

@demurgos untuk memotong rilis kecil, kita perlu memilih semua perubahan yang tidak melanggar sejak v5.2.0 menjadi cabang dan mengompilasinya ke dalam CHANGELOG. jika Anda atau orang lain bersedia melakukan pekerjaan itu, maka kami dapat memotong rilisnya.

Terima kasih atas proposisinya. Masih mungkin untuk mendapatkan --experimental-modules dengan NODE_OPTIONS jadi itu bukan prioritas tinggi (dan mungkin memperumit pohon git untuk melakukan cherry-pick). Jika saya berhasil menyelesaikan masalah yang saya miliki dengan dependensi lain, saya akan melihat apakah saya dapat meluangkan waktu untuk ini. Sementara itu, saya hanya mengawasi pencapaian v6.

fwiw saya merekomendasikan esm lebih dari --experimental-modules sampai Node.js memiliki cerita yang lurus. itu akan menjadi penantian yang cukup besar.
Maksud saya, bukankah mocha --require esm berfungsi?

Saya sangat setuju bahwa ini adalah solusi terbaik saat ini: ini adalah solusi termudah untuk disiapkan dan telah keluar selama beberapa waktu: berhasil. Dalam kasus saya, saya memelihara alat build saya sendiri dan menangani ESM asli sebagai alternatif untuk build CJS klasik. Meskipun sangat menginginkan ESM asli, saya tetap menyarankan untuk tidak menggunakannya sebagai satu-satunya cara untuk menjalankan kode Anda: bagaimanapun juga ini eksperimental :stuck_out_ tongue:.

Sebagian besar pesan terakhir saya adalah tentang berbagi apa yang dapat dilakukan menggunakan ESM asli. Ini sebagian besar pekerjaan eksperimental dan saya berharap harus mengubahnya ketika ESM Node menjadi stabil. Jangka panjang ada keuntungan memiliki solusi yang tidak memerlukan paket esm . Berikut adalah alasan saya:

• Ini mengurangi jumlah alat yang dibutuhkan (kompleksitas lebih rendah, lebih sedikit konfigurasi untuk dipahami)
• Mungkin ada beberapa perbedaan antara ESM asli dan esm di sekitar kasus tepi (kesalahan evaluasi, siklus, kesalahan pemuatan, modul asinkron/dinamis, wasm, dll.). Saat menulis kode isomorfik, mungkin lebih aman untuk mengurangi kemungkinan sumber divergensi perilaku. Ini juga agak terkait dengan cakupan asli: dengan esm , V8 melihat output yang ditranspilasikan sehingga Anda harus berurusan dengan peta sumber (belum didukung oleh c8 , tapi saya sedang menyiapkan PR, mereka bekerja pada c88 ). Perbedaan lain mungkin juga muncul saat debugging.
• Ini menghindari keharusan untuk mengubah kode secara dinamis dan membantu meningkatkan kinerja.

Apakah kita benar-benar membutuhkan deteksi otomatis? Kedengarannya sulit dan menambah overhead ...

Saya tidak yakin deteksi otomatis mana yang Anda maksud. Apakah terkait dengan PR yang dikirimkan awal tahun ini?

Sunting : Saya juga menggunakan Node tooling Slack (kebanyakan aktif di saluran #c8 ) jika Anda ingin berdiskusi.

@demurgos Saya pikir saya agak bingung tentang apa yang diinginkan orang di sini. Bagaimanapun...

Jika NODE_OPTIONS=--experimental-modules berfungsi hingga --experimental-modules didukung di Mocha v6.0.0, lalu apakah ada pekerjaan lain yang harus dilakukan untuk masalah ini? Itulah yang saya lewatkan.

Saya berharap masalah ini akan tetap terbuka sampai ESM asli ("tes gaya ES6 tanpa penggunaan transpiler") bekerja di luar kotak / semudah CJS bekerja saat ini.

Solusi yang saya posting dengan --delay dan NODE_OPTIONS=--experimental-modules lebih merupakan solusi daripada dukungan yang tepat. Saya akan mempertimbangkan masalah ini diperbaiki setelah Anda dapat menjalankan mocha **/*.spec.mjs dan mendapatkan laporan.

Sayangnya, untuk saat ini saya merasa kita masih harus menunggu Node mengetahui dukungan ESM. Saya harus memeriksa, tetapi saya pikir PR tidak menggunakan deteksi otomatis tetapi cukup mengimpor setiap modul (CJS atau ESM) menggunakan impor dinamis. Implementasinya akan tergantung pada cerita interop untuk modul.

Sunting : Saya mengacu pada https://github.com/mochajs/mocha/pull/3253. Ini memungkinkan untuk memuat semua modul sebagai ESM (tidak ada deteksi otomatis).

Saya adalah bot yang mengawasi masalah karena tidak aktif.
Masalah ini tidak memiliki aktivitas terbaru, dan saya melabelinya stale . Dalam 14 hari, jika tidak ada komentar atau aktivitas lebih lanjut, saya akan menutup masalah ini.
Terima kasih telah berkontribusi untuk Mocha!

Node 12 harus menyertakan implementasi ESM baru. Ini akan menjadi kesempatan untuk memeriksa bagaimana mendukung modul ES di Mocha.

Saya menemukan bug GC saat menggunakan Mocha dan ESM, tetapi dilaporkan dan dikonfirmasi sehingga harus diperbaiki: https://github.com/nodejs/node/issues/27492 .

Selain bug ini, strategi yang dijelaskan dalam komentar saya di atas masih berfungsi untuk menggunakan Mocha dengan ESM.

Hai orang-orang Mocha, terima kasih telah membuat dan memelihara alat yang bagus!

Ini hanya komentar FYI. Selama beberapa bulan terakhir saya telah mengerjakan Mocha dan * -test.mjs , menggunakan patch seperti di bawah ini. Hampir tidak ada masalah untuk menjalankan mocha test/*.mjs (tanpa transpiler atau modul npm esm ).
https://Gist.github.com/tadd/756d21bad38933c179f10e59bddee6b4

Tentu saja tambalan ini tidak "siap produksi" untuk pembuat Mocha; ini hanya peretasan untuk pengguna Mocha yang ingin menggunakan ESM dalam kode uji sesegera mungkin.
Saya telah menggunakan Node.js v11 dengan opsi --experimental-modules . Saat ini saya menggunakan v12 dan juga berfungsi.

Ini adalah cerita lain, tetapi Node v12 memperkenalkan ekstensi .cjs dan bidang "type" di package.json . Tampaknya ini juga perlu dipertimbangkan.

Hai orang-orang Mocha, terima kasih telah membuat dan memelihara alat yang bagus!

Memang, dan saya juga ingin mengucapkan terima kasih

Saya mengambil pendekatan berbeda untuk membuat loadFiles tetap sinkron, lihat di bawah. Ini telah bekerja untuk saya sejak Februari. Tidak seperti beberapa peretasan lainnya, ini masih memungkinkan semua tanda, inspeksi/devtools, dan cakupan kode yang akurat menggunakan c8 . Fitur terakhir itulah mengapa saya sangat membutuhkan ESM asli, karena paket esm memiliki offset yang berbeda untuk setiap file. (Ekspor modul terdaftar dan membingungkan istanbul).

https://Gist.github.com/maxnordlund/a860dd67013beaf0f31ce776536f0a47

Halo! Ini juga diperlukan untuk menguji kode apa pun yang bergantung pada proyek ES6 asli, misalnya lit-element . Kalau tidak, itu melempar seperti ini:

node_modules/lit-element/lit-element.js:14
import { TemplateResult } from 'lit-html';
       ^

SyntaxError: Unexpected token {
    at Module._compile (internal/modules/cjs/loader.js:703:23)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:770:10)
    at Module.load (internal/modules/cjs/loader.js:628:32)
    at Function.Module._load (internal/modules/cjs/loader.js:555:12)
    at Module.require (internal/modules/cjs/loader.js:666:19)
    at require (internal/modules/cjs/helpers.js:16:16)
    ...

Saya tidak tahu apakah ada solusi untuk ini, tetapi saat ini saya tidak berpikir ada cara untuk menggunakan Mocha dengan kerangka kerja asli ES6.

@heruan Saya memposting solusi yang berfungsi sejak Node 8 di komentar di atas. Berikut adalah versi terbaru yang memerlukan Node 10.12 untuk konversi URL file asli:

Tambahkan file test.esm.js berikut:

const {pathToFileURL} = require("url");
const {sync: globSync} = require("glob");
const {resolve} = require("path");

(async () => {
    const matches = globSync("**/*.spec.mjs"); // Change the glob to match your test files
    for (const match of matches) {
        await import(pathToFileURL(resolve(match)).href);
    }
    run();
})();

Kemudian jalankan tes dengan mocha --experimental-modules --delay test.esm.js .

Kode ini bekerja dengan menggunakan test.esm.js sebagai jembatan commonjs untuk memuat tes ESM.

Node 12 memiliki masalah yang dilaporkan di mana IIAFE dikumpulkan oleh GC (nodejs/node#27492), itu harus diperbaiki di salah satu versi minor berikutnya (mungkin ada beberapa solusi tetapi saya belum memeriksanya). Saya sarankan untuk menggunakan versi Node 10 terbaru sampai diperbaiki.

Thar akan memicu peringatan UnhandledPromiseRejectionWarning jika ada kesalahan. Lebih baik untuk rantai console.error atau menangani kesalahan.

import glob from "glob"
import { pathToFileURL } from "url"
import { resolve } from "path"
import { promisify } from "util"

const globAsync = promisify(glob)

async function main() {
  const matches = await glob("test/**/*.mjs")

  for (const match of matches) {
    await import(pathToFileURL(resolve(match)).href)
  }

  run()
}

main().catch(console.error)

_Saya tahu ini menggunakan import lebih dari require , tetapi lihat Intisari saya untuk solusi yang memungkinkan Anda tetap di ESM land_

@demurgos Terima kasih atas potongan kode untuk Node 10.12 yang Anda posting sepuluh hari yang lalu!

Saya menjalankan Node 12.1 dan tampaknya berfungsi dengan baik. Apakah ini akan segera ditambahkan ke Mocha, atau adakah cara yang lebih mudah untuk melakukannya dengan Node 12? Juga, bagaimana saya menggunakan ini dalam mode --watch ?

https://github.com/standard-things/esm tampaknya bekerja di luar kotak dengan --require esm , tetapi alangkah baiknya untuk membuang ketergantungan lain :) Terima kasih.

Jika Mocha beralih ke ESM di sumber, Rollup dapat menyediakan file distribusi ESM serta CommonJS dan/atau UMD.

Keuntungan lain di sini adalah bahwa HTML browser tidak perlu dikotori dengan tag skrip tambahan untuk menarik Mocha. File pengujian (atau file pintu masuk pengujian utama) dapat melakukan pengimporan (dan menghindari "keajaiban" di dalam file pengujian sejauh mencari tahu dari mana variabel berasal--hanya perlu melacak jalur impor).

Seseorang dapat menggunakan plugin CSS untuk Rollup juga untuk memungkinkan penyuntikan mocha.css , yang selanjutnya meminimalkan kebutuhan akan kekacauan HTML.

Saya adalah bot yang mengawasi masalah karena tidak aktif.
Masalah ini tidak memiliki aktivitas terbaru, dan saya melabelinya stale . Dalam 14 hari, jika tidak ada komentar atau aktivitas lebih lanjut, saya akan menutup masalah ini.
Terima kasih telah berkontribusi untuk Mocha!

Saya pikir ini masih relevan.

Adakah yang bisa menjalankan Mocha dengan Modul ES6 di (edit: ~Travis~) Node >=12.11.0?
Pada 12.10.0 sepertinya, saya berhasil mengaturnya:
mocha-run.js

(async () => {
    await import("./tests.js");
    run();
})();

Kemudian mocha --experimental-modules --delay ./mocha-run.js bekerja seperti pesona.

Tetapi untuk beberapa alasan yang tidak diketahui, pada 12.11.0, ia berperilaku seolah-olah tidak akan ada parameter --delay :

>  mocha --experimental-modules --delay ./mocha-run.js

(node:6439) ExperimentalWarning: The ESM module loader is experimental.

internal/modules/cjs/loader.js:1007

      internalBinding('errors').triggerUncaughtException(

                                ^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /home/travis/build/Palindrom/Palindrom/mocha-run.js

@tomalec Saya menjalankan moka dengan modul ES pada node 12.11.1:

__mocha-run.js__

(async () => {
    await import("./tests.mjs");
    run();
})();

Namun, mode menonton tidak berfungsi. mocha menunggu perubahan file, tetapi tidak menjalankan uji coba lain setelah file diubah.

@vanslly Beruntung kamu ;)
Bagi saya dengan Node 12.12.0 (https://travis-ci.org/Palindrom/Palindrom/builds/597771311#L450) dan mocha-run.js seperti yang Anda sarankan di atas (https://github.com/Palindrom/ Palindrom/commit/49835962bdd61c849f115e271bbc6c3f82d30511#diff-24eabf03aee8844b2b4747aa95a6af7d),

mocha --experimental-modules --delay test/mocha-run.js https://travis-ci.org/Palindrom/Palindrom/builds/597771311#L643 , , masih menampilkan kesalahan yang sama

Bahwa ini masih merupakan masalah gila! ESM tidak lagi tersembunyi di balik --experimental-modules. Ini adalah masa depan.

err, sebenarnya itu baru diumumkan beberapa hari yang lalu...

Terlambat—kita semua telah beralih ke Jest.

Hei guys, hanya ingin memastikan ini tetap hidup. Tolong jadikan ini prioritas utama dan terima kasih untuk semua kerja bagusnya!

@luijar Ini sedang dikerjakan di #4038

Kami kemarin menerbitkan rilis eksperimental v7.0.0-esm1 : lihat catatan rilis .

Ini bagus untuk dilihat!

Bisakah saya bertanya - apakah kurangnya referensi ke browser berarti bahwa penggunaan ESM tidak tersedia di browser atau hanya Anda tidak perlu menentukan versi browser seperti pada Node.js. Saya pikir mungkin membantu untuk menyebutkan dalam catatan rilis status untuk browser (dan jika tidak didukung, apa rencana untuk dukungannya).

@brettz9
NodeJs ESM tidak memengaruhi browser Mocha dengan cara apa pun. Tes yang Anda jalankan di browser Anda tidak dimuat oleh NodeJs, Anda harus melakukannya sendiri dalam kode HTML Anda.

Jika saya ingat dengan baik, Anda harus mengatur tag $# <script> type="module" . Untuk kedua file pengujian Anda dan untuk skrip Mocha, untuk menjaga urutan pemuatan. ESM seharusnya bekerja dengan browser selama bertahun-tahun.

@juergba : ya, tentu, tetapi seseorang memerlukan file distribusi ekspor ESM sehingga dapat digunakan seperti import mocha from '../node_modules/mocha/mocha-esm.js'; tanpa kompilasi--dan bagi mereka yang menggunakan kompilasi (misalnya, agar dapat menggunakan import mocha from 'mocha'; ), mereka akan menginginkan module di package.json sehingga pembuat bundel dapat menemukan ESM build secara otomatis.

moka ditulis dalam commonjs; kami tidak dapat menempatkan bidang "modul" di package.json. Mocha akan mendukung pengujian yang berjalan di node yang ditulis dalam ESM.

Jika Anda tidak ingin memfaktorkan ulang untuk menggunakan ESM secara internal, Anda masih dapat menggunakan Rollup dengan plugin CommonJS-nya dan menunjukkan file target ESM untuk mendukung module (seperti penawaran Sinon dan sebagian besar paket perhatikan yang saya temui, jQuery menjadi satu-satunya pengecualian penting lainnya dan mereka telah melakukan refactoring untuk menggunakan ESM).

Saya telah membuat proyek sampel untuk menguji moka dengan ESM. Saya berhasil menjalankan tes, tetapi tidak (_yet_) dapat menjalankan cakupan dengan nyc/istanbul. Bantuan Anda akan diterima.

@concatime Sampai nyc dibuat kompatibel, Anda dapat menggunakan c8 : https://www.npmjs.com/package/c8

c8 --all --include=lib/**/*.js --reporter=lcovonly node_modules/.bin/mocha --recursive

@cedx Saya telah memperbarui repo templat saya., dan berhasil. Rapi!

Kami menerapkan dukungan ESM asli Node di Mocha v7.1.0.