Pegjs: फ़ीचर: रन-टाइम के लिए pegjs फ़ाइलों की आवश्यकता होती है

मैं इसके बजाय इसकी अनुमति नहीं दूंगा।

@ एक्सई-बॉस: हमारे उपयोग के मामले में, यह सिर्फ परीक्षण के लिए होगा (यह भी सुनिश्चित नहीं है कि आपने नोट किया है कि यह पेगज रेपो है।)

मुझे पता है कि यह पीईजी.जेएस रेपो है, यही वजह है कि मैं इसे यहां लागू करने का विरोध कर रहा हूं।

ठीक है, अच्छा ... (मैं कभी-कभी किसी अन्य रेपो के लिंक का अनुसरण कर सकता हूं, यह ध्यान दिए बिना कि यह एक अलग मुद्दा नहीं है, इसलिए बस सुनिश्चित करें) :)

2017 के दो-लाइनर तक कोई और सुविधाएँ नहीं हैं जो हमें es6 मॉड्यूल और तीर का उपयोग करने देती हैं।

साथ ही, ऐसा लगता है कि आप वास्तव में जो चाहते हैं वह परीक्षण है

आप लाइब्रेरी में कवरेज हुक नहीं लगाते हैं। आप उन्हें परीक्षण फ़ाइल में डाल दें।

यदि आप कवरेज चाहते हैं, तो आप jest इंस्टॉल कर सकते हैं और बस किया जा सकता है। इसमें आपकी जरूरत की सभी चीजें स्वतः शामिल हैं और पुस्तकालय में कोई संशोधन करने की आवश्यकता नहीं है। कवरेज टूल को अंदर से नहीं, बल्कि बाहर से जोड़ने के लिए डिज़ाइन किया गया है।

यह पार्सर जनरेटर एक आंतरिक विशेषता के रूप में अचानक node.js पैकेज पारिस्थितिकी तंत्र से बंधा नहीं होना चाहिए।

इसके अलावा, कवरेज एक पार्सर की झूठी इच्छा है। निम्न पर विचार करें:

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

अब, केवल चावल के लिए एक परीक्षण लिखें। peg Peanuts की कोशिश करने जा रहा है, फिर जब यह काम नहीं करता है तो peg कोशिश करेगा Shellfish , फिर peg कोशिश करेगा Rice

ध्यान दें कि आपने केवल Rice के लिए एक परीक्षण लिखा था, लेकिन आप गलत तरीके से तीनों के लिए कवरेज दिखा रहे हैं

जिस तरह से एक पैकेट पार्सर (ईमानदारी से जिस तरह से मैं सोच सकता हूं) काम करता है इसका मतलब है कि कवरेज नकली है

अपना समय बर्बाद मत करो

जहां तक ​​पुस्तकालय में कवरेज हुक लगाने की बात है, आम तौर पर कोई उन्हें अपने परीक्षणों में डालता है, हां, लेकिन जब एक पार्सर कुछ शाखाओं के साथ प्रासंगिक और कुछ के रूप में स्वतः उत्पन्न होता है, तो यह ऑटो-जनरेटर के लिए इसे उत्पन्न करने के लिए समझ में आता है ताकि वे प्रोजेक्ट जो अपनी पार्सर फाइल को नजरअंदाज नहीं करना चाहते, ऐसा कर सकें। यह pegjs लाइब्रेरी (जिसकी अपनी कवरेज आवश्यकताएं हैं) के कवरेज से संबंधित नहीं है, लेकिन व्याकरण के जेनरेटेड पार्सर के उपयोग के कवरेज से संबंधित है।

आपके उदाहरण में, जेनरेट किए गए पार्सर में "मूंगफली", "शेलफिश" और "चावल" की जांच के लिए कोड की रेखाएं होती हैं, और यदि वे कवर नहीं होते हैं, तो उन्हें वास्तव में रिपोर्ट किया जा सकता है।

यह एक खुला प्रश्न बन जाता है कि क्या ruleA = ruleB / ruleC जैसे नियम को यह जांचना चाहिए कि "नियम ए" में "नियम बी" और "नियम सी" दोनों के मामले हैं, या क्या यह "नियम ए", "नियम बी" की जांच करने के लिए पर्याप्त है। , और "नियम सी" सभी किसी न किसी तरह से कवर हो जाते हैं (उदाहरण के लिए, यदि कोई ruleD = ruleB / ruleF है, तो ruleB के इसके कवरेज को कुछ परियोजनाओं द्वारा देखा जा सकता है ताकि इसे जांचने की आवश्यकता से बचने के लिए पर्याप्त रूप से कवर किया जा सके। "नियम ए", खासकर यदि बहुत सारे विकल्प और संयोजन हैं)।

जहां तक ​​इस मुद्दे की बात है, एक प्रवेश फ़ाइल हो सकती है जिसमें सुविधा शामिल है, और दूसरी जो नहीं है।

@ ब्रेट्ज़ 9 - मैं कहने वाला था "मैं इसी चीज़ के बारे में किसी और से बात कर रहा हूं" और फिर मुझे एहसास हुआ कि यह आप हैं, इसलिए, मैं इस चर्चा के इस उदाहरण को उसी के पक्ष में समाप्त करने जा रहा हूं जो हम कर रहे हैं #633 पर होने पर, अगर यह आपको ठीक लगता है

मैं इस समय वहाँ कुछ लम्बा लिख ​​रहा हूँ