Pegjs: Fitur: Run-time membutuhkan file pegjs

Saya lebih suka tidak mengizinkan ini.

@ExE-Boss : Untuk kasus penggunaan kami, itu hanya untuk pengujian (juga, tidak yakin apakah Anda mencatat ini adalah repo pegjs.)

Saya tahu bahwa ini adalah repo PEG.js , itulah sebabnya saya menentang penerapan ini di sini.

Ok, keren... (Kadang-kadang saya bisa mengikuti tautan ke repo lain tanpa menyadari itu bukan masalah terpisah, jadi pastikan saja) :)

Tidak ada lagi fitur hingga dua baris 2017 yang memungkinkan kami menggunakan modul es6 dan panah keluar.

Juga, sepertinya yang sebenarnya kamu inginkan adalah pengujian

Anda tidak meletakkan kait cakupan di perpustakaan. Anda memasukkannya ke dalam file tes.

Jika Anda ingin cakupan, Anda dapat menginstal jest dan selesai. Ini otomatis mencakup semua yang Anda butuhkan dan tidak ada modifikasi yang perlu dilakukan ke perpustakaan. Alat liputan dirancang untuk ditambahkan dari luar, bukan dari dalam.

Generator parser ini tidak boleh tiba-tiba terikat dengan ekosistem paket node.js sebagai fitur internal.

Selain itu, cakupan adalah keinginan palsu untuk parser. Pertimbangkan hal berikut:

Food
    / "Peanuts"
    / "Shellfish"
    / "Rice"

Sekarang, tulis saja tes untuk nasi. peg akan mencoba Peanuts terlebih dahulu, kemudian ketika tidak berhasil peg akan mencoba Shellfish , kemudian peg akan mencoba Rice

Perhatikan bahwa Anda hanya menulis tes untuk Rice , tetapi Anda salah menampilkan cakupan untuk ketiganya

Cara kerja parser packrat (jujur, cara kerja parser yang pernah saya pikirkan) berarti cakupannya palsu

Jangan buang waktumu

Sejauh menempatkan kait cakupan di perpustakaan, biasanya seseorang menempatkannya dalam tes seseorang, ya, tetapi ketika parser dibuat secara otomatis dengan beberapa cabang yang relevan dan beberapa tidak, maka masuk akal bagi generator otomatis untuk menghasilkan ini sehingga proyek-proyek yang tidak ingin mengabaikan file parser mereka dapat melakukannya. Ini tidak terkait dengan cakupan pustaka pegjs (yang memiliki persyaratan cakupannya sendiri) tetapi dengan cakupan penggunaan tata bahasa parser yang dihasilkan.

Dalam contoh Anda, pengurai yang dihasilkan memiliki baris kode untuk memeriksa "Kacang", "Kerang" dan "Beras", dan jika tidak tercakup, mereka memang dapat dilaporkan.

Ini menjadi lebih menjadi pertanyaan terbuka apakah aturan seperti ruleA = ruleB / ruleC harus memeriksa bahwa "ruleA" memiliki kasus dengan "ruleB" dan "ruleC", atau apakah cukup untuk memeriksa "ruleA", "ruleB" itu , dan "ruleC" semuanya tercakup entah bagaimana (misalnya, jika ada ruleD = ruleB / ruleF , cakupan ruleB dapat dilihat oleh beberapa proyek sebagai cukup untuk menghindari kebutuhan untuk memeriksa apakah itu tercakup dalam "ruleA", terutama jika ada banyak alternatif dan kombinasi).

Sejauh masalah ini, mungkin ada file masuk yang menambahkan fitur, dan yang lain tidak.

@brettz9 - Saya akan mengatakan "Saya sedang berbicara dengan orang lain tentang hal yang sama" dan kemudian saya menyadari bahwa itu Anda, jadi, saya akan menghentikan contoh diskusi ini demi diskusi serupa yang kita lakukan memakai #633, jika menurutmu tidak apa-apa

Saya sedang menulis sesuatu yang panjang di sana saat ini