कोई और शोध करने से पहले, मेरे सिर के ऊपर से प्रारंभिक विचार:

• मुझे लगता है कि नोड लोगों को विशेष रूप से कॉमनजेएस मॉड्यूल के साथ पश्च संगतता की अनुमति देने के लिए मानक बदल गया है। अगर यह (अभी भी?) सच है, तो मैं उम्मीद करता हूं कि अंततः मोचा के साथ/कुछ भी करने की आवश्यकता के बिना इसे समर्थित किया जाएगा। (और "आखिरकार" से मेरा मतलब है "संभवतः मोचा परिवर्तनों से भी तेज", नोड के रिलीज चक्र की दर को देखते हुए; इसके बारे में अधिक विस्तृत विवरण के लिए नीचे जोर दिया गया है।)
• क्या मैं मान सकता हूं कि यह node --experimental-modules node_modules/mocha/bin/_mocha जैसा चलाया गया था?
• .jsx वास्तव में कैसे शामिल है? मैं देखता हूं कि दिखाया गया त्रुटि उदाहरण .mjs को संदर्भित करता है; यह स्पष्ट नहीं है कि क्या पोस्ट किया गया है, जहां jsx है।
• मुझे .mjs फ़ाइल एक्सटेंशन की आवश्यकता वाले नोड के प्रारंभिक कार्यान्वयन की सुनवाई भी अस्पष्ट रूप से याद है; यदि वह (अभी भी?) सत्य है, और यदि आप import / export का उपयोग .jsx फ़ाइल के साथ करने का प्रयास कर रहे हैं (या तो import एक .jsx में .mjs फ़ाइल या .jsx फ़ाइल लोड करना जिसमें import / export शामिल है), क्या यह मोचा के बजाय मुद्दा हो सकता है?
• हमें यह सुनिश्चित करने के लिए एक तरीके के साथ आने की आवश्यकता होगी कि प्रायोगिक सुविधा में बदलाव के लिए मोचा में बदलाव की आवश्यकता नहीं है, जिसके लिए एक सेवर मेजर की प्रतीक्षा करनी होगी - अन्यथा आप ठीक उसी जगह पर समाप्त हो सकते हैं जहां हम अभी हैं, केवल लंबे समय तक प्रतीक्षा करने के अलावा (चूंकि मोचा का प्रमुख रिलीज चक्र नोड की तरह साल में दो बार लॉक नहीं होता है)।
• विशुद्ध रूप से मेरी अपनी राय से और टीम की ओर से नहीं, यदि नया मॉड्यूल प्रारूप पुराने प्रारूप में लिखे गए मौजूदा पुस्तकालयों में संशोधन किए बिना पुराने मॉड्यूल प्रारूप के साथ इंटरऑपरेट नहीं कर सकता है, तो नया मॉड्यूल प्रारूप अभी तैयार नहीं है ।

मुझे लगता है कि नोड लोगों को विशेष रूप से कॉमनजेएस मॉड्यूल के साथ पश्च संगतता की अनुमति देने के लिए मानक बदल गया है। अगर यह (अभी भी?) सच है, तो मैं उम्मीद करता हूं कि अंततः मोचा के साथ/कुछ भी करने की आवश्यकता के बिना इसे समर्थित किया जाएगा। (और "आखिरकार" से मेरा मतलब है "संभवतः मोचा परिवर्तनों से भी तेज", नोड के रिलीज चक्र की दर को देखते हुए; इसके बारे में अधिक विस्तृत विवरण के लिए नीचे जोर दिया गया है।)

मेरे (छोटे) शोध से ऐसा लगता है कि कम से कम अभी के लिए इसे ईसीएमएस्क्रिप्ट मॉड्यूल से require का उपयोग करने की अनुमति है, लेकिन एक कॉमनज मॉड्यूल से import नहीं।

क्या मैं मान सकता हूँ कि यह नोड --प्रायोगिक-मॉड्यूल नोड_मॉड्यूल/मोचा/बिन/_मोचा की तरह चलाया गया था?
.jsx वास्तव में कैसे शामिल है? मैं देखता हूं कि दिखाया गया त्रुटि उदाहरण .mjs को संदर्भित करता है; यह अस्पष्ट है, जो पोस्ट किया गया है, जहां जेएसएक्स है।

हां, इसे --experimental-modules के साथ चलाया गया था। jsx एक टाइपो है, मेरा मतलब है mjs , प्रारंभिक पोस्ट को अपडेट करेगा।

मैं .mjs फ़ाइल एक्सटेंशन की आवश्यकता वाले नोड के प्रारंभिक कार्यान्वयन की सुनवाई को भी अस्पष्ट रूप से याद करता हूं; यदि यह (अभी भी?) सत्य है, और यदि आप .jsx फ़ाइल के साथ आयात/निर्यात का उपयोग करने का प्रयास कर रहे हैं (या तो .jsx फ़ाइल को .mjs फ़ाइल में आयात कर रहे हैं या आयात/निर्यात वाली .jsx फ़ाइल लोड कर रहे हैं), तो क्या ऐसा हो सकता है मोचा के बजाय मुद्दा हो?

ऐसा लगता है, और मुझे यहां कुछ याद आ रहा है, कि मोचा परीक्षण लोड करने के लिए require का उपयोग करता है (यह कम से कम मेरी वर्तमान धारणा है क्योंकि मैं एक मोचा विशेषज्ञ नहीं हूं, एक उपयोगकर्ता से अधिक) जो तब import के माध्यम से अन्य मॉड्यूल शामिल हैं। यह पहले बिंदु के संयोजन में त्रुटि की व्याख्या करेगा।

हमें यह सुनिश्चित करने के लिए एक तरीके के साथ आने की आवश्यकता होगी कि प्रायोगिक सुविधा में बदलाव के लिए मोचा में बदलाव की आवश्यकता नहीं है, जिसके लिए एक सेवर मेजर की प्रतीक्षा करनी होगी - अन्यथा आप ठीक उसी जगह पर समाप्त हो सकते हैं जहां हम अभी हैं, केवल लंबे समय तक प्रतीक्षा करने के अलावा (चूंकि मोचा का प्रमुख रिलीज चक्र नोड की तरह साल में दो बार लॉक नहीं होता है)।
विशुद्ध रूप से मेरी अपनी राय से बोलते हुए और टीम की ओर से नहीं, यदि नया मॉड्यूल प्रारूप पुराने प्रारूप में लिखे गए मौजूदा पुस्तकालयों में संशोधन किए बिना पुराने मॉड्यूल प्रारूप के साथ इंटरऑपरेट नहीं कर सकता है, तो नया मॉड्यूल प्रारूप अभी तैयार नहीं है।

मुझे डर था कि यह उत्तर होगा और मैं समझता हूं कि यह सर्वोच्च प्राथमिकता नहीं है। यदि उपरोक्त त्रुटि के कारण के बारे में मेरी धारणा सही है, तो #956 जैसी कोई चीज मदद कर सकती है क्योंकि परीक्षण का प्रवेश बिंदु सामान्य के बजाय mjs मॉड्यूल हो सकता है जो अन्यथा हासिल करना मुश्किल है। यह मौजूदा मॉड्यूल से import का समर्थन करने के लिए नोडज टीम के रोडमैप पर प्रतीत होता है, हालांकि समयसीमा के बारे में स्पष्ट नहीं है।

मेरे (छोटे) शोध से ऐसा लगता है कि कम से कम अभी के लिए इसे ईसीएमएस्क्रिप्ट मॉड्यूल से आवश्यकता का उपयोग करने की अनुमति है, लेकिन कॉमनज मॉड्यूल से आयात नहीं किया जाता है।

ऐसा लगता है कि यह मौजूदा मॉड्यूल से आयात का समर्थन करने के लिए नोडज टीम के रोडमैप पर है, हालांकि समयसीमा के बारे में स्पष्ट नहीं है।

स्पष्ट करने के लिए: यह देखते हुए कि "पुराने" (कुछ मामलों में वर्तमान गैर-प्रयोगात्मक) वातावरण import एक सिंटैक्स त्रुटि है, जिसे ब्रांचिंग लॉजिक या ऐसा कुछ भी नहीं टाला जा सकता है, जो मोचा की जरूरत नहीं है import का उपयोग करने में सक्षम होने के लिए बल्कि नए प्रारूप का उपयोग करने वाले मॉड्यूल (या उपयोग करने वाले मॉड्यूल का उपयोग करने वाले) को लोड करने के लिए require का उपयोग करने में सक्षम होने के लिए।

jsx एक टाइपो है, मेरा मतलब था mjs , प्रारंभिक पोस्ट को अपडेट करेगा।

धन्यवाद, यह एक संभावित कोण को समाप्त करता है!

यदि उपरोक्त त्रुटि के कारण के बारे में मेरी धारणा सही है, तो #956 की तरह कुछ मदद कर सकता है क्योंकि परीक्षण का प्रवेश बिंदु आम के बजाय एक एमजेएस मॉड्यूल हो सकता है जो अन्यथा हासिल करना मुश्किल है।

मोचा को वैश्विक चर नहीं बनाना दुर्भाग्य से कुछ अधिक रहस्यमय आंतरिकों के व्यापक पुनर्लेखन के बिना संभव नहीं है (मैंने कोशिश की और इसे स्वयं नहीं समझ सका 😿); हालाँकि, अपने स्वयं के JS प्रवेश बिंदु का उपयोग करना अब "प्रोग्रामेटिक" API के माध्यम से संभव है (जो पुराने विकी पृष्ठ के बाहर प्रलेखित नहीं हो सकता है और स्रोत फ़ाइलों में JSDoc टिप्पणियों का दस्तावेजीकरण नहीं किया जा सकता है, लेकिन आधिकारिक तौर पर समर्थित है):

// 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

मैंने वास्तव में यह देखने की कोशिश नहीं की है कि क्या इससे कोई फर्क पड़ता है (पहले नोड के नवीनतम संस्करण को हथियाने की आवश्यकता है), लेकिन मुझे बताएं कि क्या यह आपके लिए काम करता है ...

सबसे पहले इस पर आपके समर्थन के लिए धन्यवाद!

मैंने यह कोशिश की

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

तो मूल रूप से नोड एंट्री पॉइंट को ईसीएमएस्क्रिप्ट मॉड्यूल बना दिया।

मैं इसे node --experimental-modules --harmony ./runner.mjs . के माध्यम से चलाता हूं

मुझे मिला

(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)

मोचा को import का उपयोग करने में सक्षम होने की आवश्यकता नहीं है, बल्कि नए प्रारूप का उपयोग करने वाले (या उपयोग करने वाले मॉड्यूल का उपयोग करने वाले) मॉड्यूल को लोड करने की आवश्यकता का उपयोग करने में सक्षम होना चाहिए।

मुझे डर है कि वर्तमान में नोड में संभव नहीं है, आप केवल require का उपयोग मॉड्यूल में कर सकते हैं जिसे आपने आयात किया है import । क्या mocha.addFile('./test/frontend/components/global/test.mjs'); से बचने का कोई तरीका है और इसके बजाय परीक्षण आयात करें और इस तरह आयातित स्क्रिप्ट जोड़ें

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

?

इस समय मोचा में ऐसा कोई समारोह नहीं है, लेकिन आप उन पंक्तियों के साथ कुछ कर सकते हैं। addFile बस फ़ाइल को एक सूची में जोड़ता है जो बाद में run फ़ंक्शन द्वारा require d है। run फ़ंक्शन उन्हें loadFiles से require पर कॉल करता है:

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

आप जो करना चाहते हैं वह किसी भी फाइल के लिए है जिसे $#$7 require #$ के बजाय import एड होना चाहिए d addFile पर कॉल न करें (इसलिए मोचा require करने की कोशिश नहीं करेगा run पर) और इसके बजाय run पर कॉल करने से पहले कुछ कोड कॉल करें जो loadFiles में है लेकिन require के बजाय import का उपयोग करें require । मुझे अपने सिर के ऊपर से याद नहीं है कि क्या import के उपयोग पर कोई प्रतिबंध है जो इसे रोकेगा, लेकिन यदि यह संभव है तो मुझे लगता है कि यह बहुत करीब दिखाई देगा:

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

आप यह भी देख सकते हैं कि कैसे https://github.com/mochajs/mocha/blob/master/bin/_mocha अन्य विकल्पों की आपूर्ति करने के तरीके और Mocha की फ़ाइल लुकअप कार्यक्षमता जैसी चीज़ों का उपयोग करने का तरीका जानने के लिए Mocha के प्रोग्रामेटिक API का उपयोग करता है। यह बहुत अच्छी तरह से व्यवस्थित नहीं है लेकिन कमांडलाइन इंटरफ़ेस जो कुछ भी करता है वह वहां है (या तो सीधे या क्योंकि मोचा के प्रोग्रामेटिक एपीआई में कार्यों के लिए कॉल है)।

मैं एक कदम आगे आ सकता हूं लेकिन आयातित परीक्षण अब शिकायत करता है कि यह वर्णन ( ReferenceError: describe is not defined ) के बारे में नहीं जानता है। इंजेक्शन लगाने का सही तरीका क्या है? यदि मैं करता हूँ

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

यह शिकायत करता है TypeError: describe is not a function

तो, मेरे डिस्ट्रो को आखिरकार NodeJS 8.5 मिल गया, और मुझे इसके साथ खेलने का मौका मिला है और मेरे पास कुछ कूबड़ की पुष्टि करने का मौका है, लेकिन जब तक मैं जांच नहीं कर पाता, तब तक यह बताना नहीं चाहता था:

1. मुझे किसी स्क्रिप्ट/मॉड्यूल फ़ाइल में उसका नाम हार्डकोड किए बिना ES मॉड्यूल लोड करने का कोई तरीका नहीं मिल रहा है। इसका मतलब है कि मोचा उन्हें कमांडलाइन इंटरफेस के माध्यम से लोड नहीं कर सकता है चाहे हम कुछ भी करें और किसी भी अन्य ईएस बनाम कॉमनजेएस सेमेन्टिक्स की परवाह किए बिना। अगर और कब यह बदलता है, तो हम जानना चाहेंगे, मुझे लगता है। (यदि यह इस तरह बदलता है कि ES मॉड्यूल को एक चर require के माध्यम से लोड किया जा सकता है, तो हमें शायद कुछ भी बदलने की आवश्यकता नहीं होगी, लेकिन मुझे नहीं लगता कि हम इस बारे में कुछ भी कह सकते हैं कि मॉड्यूल कैसे निश्चित रूप से काम करते हैं जब तक ऐसा नहीं होता है। ।)
2. जबकि मोचा pre-require घटना उत्सर्जन में इंटरफ़ेस सेट करता है (जब मॉड्यूल पहली बार लोड नहीं होता है; चुना गया इंटरफ़ेस new Mocha उदाहरण के लिए विशिष्ट है), नया मॉड्यूल सिस्टम वास्तव में निर्भरता पेड़ को पार्स करता है और उन पर निर्भर मॉड्यूल से पहले निर्भरता लोड करता है, इसलिए कारण describe परिभाषित नहीं किया गया है कि मोचा परीक्षण मॉड्यूल लोड होने तक इसे स्थापित नहीं कर रहा है। इसका मतलब है कि यह सब कुछ होने के लिए जटिल होने जा रहा है (फिर से, जब तक कि require(file) की अनुमति नहीं है और उस विशिष्ट लाइन पर निर्भरता को लोड करता है, अधिमानतः समकालिक रूप से इसलिए हमें कुछ और बदलने की जरूरत नहीं है )

हालांकि, मुझे पता चला कि मैं इस तथ्य का फायदा उठाकर काम कर सकता हूं कि $ import कॉल के क्रम में import एड मॉड्यूल लोड किए गए हैं। (यदि आप निर्यात इंटरफ़ेस या एक रिपोर्टर का उपयोग करते हैं, जिसे प्रत्येक व्यक्तिगत फ़ाइल के नाम की आवश्यकता होती है, जैसा कि उस कोड में वर्णित है जिसे मैं लिंक करने वाला हूं, लेकिन सिद्धांत रूप में यह काम करता है, तो यह बहुत अधिक बेमानी हो जाएगा।) यदि वह तथ्य थे उपरोक्त किसी अन्य तथ्य को बदले बिना बदलना, तब भी यह संभव नहीं होगा। लेकिन अभी के लिए मुझे लगता है कि आपको यही करना होगा।

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

node --experimental-modules ./run.mjs

दुर्भाग्य से, मुझे पूरा यकीन है कि ES मॉड्यूल के काम करने के तरीके और वर्तमान समय में नोड क्या अनुमति देता है, इसे देखते हुए हम सबसे अच्छा कर सकते हैं।

इसे दूसरे तरीके से सोचें:

• import सिंटैक्स है।
• require एक फ़ंक्शन है।

आप गतिशील रूप से import कुछ भी नहीं कर सकते हैं, जैसे कि आप गतिशील रूप से कोड का उपयोग किए बिना नहीं चला सकते हैं, उदाहरण के लिए, eval() ।

यह चरण 3 प्रस्ताव है जो इस व्यवहार की अनुमति देगा, लेकिन मुझे यकीन नहीं है कि कोई रनटाइम इसे अभी तक भेज रहा है या नहीं।

जैसे, मोचा के लिए .mjs फ़ाइल आयात करने का कोई तरीका नहीं है जब mocha के माध्यम से चल रहा हो, शायद @std/esm को जोड़े बिना और require .mjs साथ फाइलों के लिए इसके कार्यान्वयन का उपयोग कर रहा हो। हो सकता है और कुछ ऐसा जिसे हम समर्थन देने पर विचार कर सकते हैं, लेकिन एक चर्चा (और इस तरह के एक पीआर) को समुदाय से आने की आवश्यकता होगी, कम से कम जब तक यह व्यवहार ध्वज के पीछे न हो।

import describe from 'mocha' प्राथमिकता सूची में बहुत कम है, दुर्भाग्य से, इस तरह की चीज़ों के आसपास अंतर्निहित कठिनाई के कारण (#956)। node के साथ चलने के लिए सबसे अच्छा है और ग्लोबल्स का उपभोग करने के लिए चिपके रहें।

वास्तव में, मेरे साथ ऐसा होता है कि हम परीक्षणों को लोड कर सकते हैं और vm.runInContext का लाभ उठा सकते हैं, यह मानते हुए कि ऐसी चीज मॉड्यूल का समर्थन करती है। चूंकि नोड का लोडिंग व्यवहार .mjs एक्सटेंशन से जुड़ा हुआ है, और vm.runInContext एक स्ट्रिंग की अपेक्षा करता है, यह न देखें कि यह कैसे हो सकता है- और दस्तावेज़ों में इसके बारे में कुछ भी उल्लेख नहीं किया गया है। शायद कहीं कोई मसला?

(फिर फिर, यह वही हो सकता है जो @std/esm हुड के नीचे करता है!)

मेरे पास ब्राउज़र में ट्रांसपिलर के बिना काम कर रहे मोचा परीक्षण हैं। शायद यह इस मुद्दे के लिए मदद करता है।

यह असंबंधित है क्योंकि आप मोचा को एक मॉड्यूल के रूप में नहीं, बल्कि एक स्क्रिप्ट के रूप में खींच रहे हैं ...

खेद है कि मैं भ्रमित हूँ। यह एक ब्राउज़र में अलग है।

मैं मोचा को ईएस मॉड्यूल में स्थित परीक्षण चलाने की अनुमति देने के लिए कुछ करने के लिए समर्थन के वोट के साथ वजन करना चाहता हूं। मैं इस तरह के परीक्षण को लिखने की कोशिश करने और Node.js मॉड्यूल लोडर से एक अजीब त्रुटि प्राप्त करने के बाद यहां पहुंचा। मैं Node.js 9.5 का उपयोग कर रहा हूं, जो मूल रूप से ES6 मॉड्यूल का समर्थन करता है।

जैसा कि यह वर्तमान में खड़ा है, Node.js 9.5 एक CommonJS मॉड्यूल को एक ES6 मॉड्यूल की आवश्यकता () की अनुमति नहीं देता है। शायद वे इसकी अनुमति देने की दिशा में काम कर रहे हैं, मुझे नहीं पता।

मैंने .mjs एक्सटेंशन के साथ ES6 मॉड्यूल के रूप में परीक्षण लिखा और इसे चलाने की कोशिश की। लोडर से त्रुटि मिली - मुझे लगता है कि mocha कमांड के परिणाम require() का उपयोग करते हैं और इसलिए यह विफल रहा।

.js एक्सटेंशन के साथ परीक्षण को फिर से करें और परीक्षण किए जाने वाले मॉड्यूल को लोड करने के लिए require() का उपयोग करने का प्रयास किया। वह भी लोडर से त्रुटि मिली।

मेरा मानना ​​है कि Node.js दुनिया को इस बात पर विचार करने की जरूरत है कि वे ES6 मॉड्यूल में कैसे आगे बढ़ेंगे और उनका समर्थन करेंगे। चूंकि मोचा इस दुनिया में एक बहुत लोकप्रिय उपकरण है, इसलिए मोचा टीम के लिए यह विचार करना सबसे अच्छा होगा कि ES6 मॉड्यूल का समर्थन कैसे किया जाए।

अनुवर्ती कार्रवाई करने के लिए ... कुछ विचार और खोज के बाद मैं इस क्रम को वर्कअराउंड के रूप में काम करने में सक्षम था।

परीक्षण स्क्रिप्ट को .js एक्सटेंशन के साथ नाम दें (इसे कॉमनजेएस स्क्रिप्ट बनाते हुए)

फिर इसे टेस्ट स्क्रिप्ट में जोड़ें:

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

तब मैं require() एक ES मॉड्यूल इस प्रकार कर सकता हूं:

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

@robogeek या कमांडलाइन से @std/esm प्रीलोडर का उपयोग करना और भी बेहतर हो सकता है, इसलिए आपको वर्कअराउंड के साथ अपनी विशिष्ट फ़ाइलों को अव्यवस्थित करने की आवश्यकता नहीं है, और इसमें .mjs एक्सटेंशन हो सकते हैं।

mocha -r @std/esm spec.mjs

--harmony-dynamic-import ध्वज के पीछे नोड v9.6 के साथ गतिशील आयात जहाज। गतिशील आयात मोचा को ट्रांसपिलर की आवश्यकता के बिना es6 मॉड्यूल में निहित परीक्षणों को लोड करने की अनुमति देता है।

@harrysarson यह लीक से हटकर काम नहीं करेगा। मोचा सीजेएस मॉड्यूल और require का उपयोग करता है, आपको $#$1 import #$ की एसिंक प्रकृति को संभालने के लिए कुछ अतिरिक्त गोंद कोड के साथ सीजेएस का उपयोग करके परीक्षण फाइलें लिखनी होंगी। या क्या मैं कुछ न कुछ भूल रहा हूं?

मैं एक बॉट हूं जो निष्क्रियता के मुद्दों को देखता है।
इस समस्या में हाल की कोई गतिविधि नहीं है, और मैं इसे stale लेबल कर रहा हूं। 14 दिनों में, अगर कोई और टिप्पणी या गतिविधि नहीं होती है, तो मैं इस मुद्दे को बंद कर दूंगा।
मोचा में योगदान के लिए धन्यवाद!

मुद्दा अभी भी प्रासंगिक है लेकिन ईएसएम के लिए मूल समर्थन पर निर्भर करता है। ब्राउज़रों के पास है, नोड अभी तक नहीं है।

मैं बस इधर-उधर खेल रहा था, ESM/.mjs से परिचित हो रहा था और फैसला किया कि मुझे अपने खिलौने के लिए परीक्षण की आवश्यकता है। मोचा को साकार करना अभी तक आधिकारिक तौर पर .mjs फाइलों का समर्थन नहीं कर रहा है, मैं एक साथ एक त्वरित अंतरिम मॉड्यूल के माध्यम से (जब तक किसी के पास मोचा को पूर्ण समर्थन जोड़ने का समय नहीं है):

https://www.npmjs.com/package/mocha-esm
पीआर/मुद्दों का स्वागत है: https://github.com/stefanpenner/mocha-esm

वहाँ कुछ बेहतर हो सकता है, लेकिन एक साथ रहने में मज़ा आया। तो \o/

मैंने गतिशील आयात का समर्थन करने के लिए mocha को स्वयं फोर्क करने का निर्णय लिया (उपरोक्त कुछ विचारों के आधार पर, लेकिन मैं इसे किसी अन्य तरीके से चलाने के लिए नहीं मिला)।

इसका मतलब है कि आप उदाहरण के लिए node --experimental-modules --harmony-dynamic-import test.mjs . का उपयोग करके चला सकते हैं

फिर 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);
  });
});

मैंने इस न्यूनतम का समर्थन करने के लिए मोचा में परिवर्तन रखा, और मेरे पास संभावित पीआर के लिए इसे ठीक से एकीकृत करने का समय नहीं था और न ही मैंने एक विशेष एनपीएम मॉड्यूल जोड़ा था, लेकिन आप इस कांटा को सीधे जीथब से "mocha": "git+https://[email protected]/odolha/mocha" स्थापित कर सकते हैं .

ध्यान दें कि आप इस दृष्टिकोण का उपयोग किसी भी एसिंक तरीके से फ़ाइलों को लोड करने के लिए कर सकते हैं, न केवल गतिशील आयात के माध्यम से, क्योंकि मोचा एक ऐसे फ़ंक्शन की अपेक्षा कर रहा है जो एक वादा प्रदान करता है।

संपादित करें

मैं यह उल्लेख करना भूल गया कि आपके परीक्षण इस दृष्टिकोण के साथ शुद्ध स्क्रिप्ट नहीं हो सकते हैं, क्योंकि हम संदर्भ को इंजेक्ट नहीं कर सकते हैं, इसलिए इसके बजाय आपको यह करना होगा:

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

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

आपका कार्यान्वयन मुझे दिलासा देता है कि इसके लिए समर्थन जोड़ना आसान होना चाहिए। हम इस सुविधा का बेसब्री से इंतजार कर रहे हैं :)

@demurgos : no_mouth: हाँ ... मैंने अपनी बात करने के बाद बस उस पीआर को देखा, डी ओह ।

@harrysarson @boneskull
esm पैकेज (जिसे पहले @std/esm नाम दिया गया था) ने इस कमिट में .mjs फाइलों का समर्थन छोड़ दिया।
इसका मतलब है कि अब मोचा के साथ .mjs फाइलों का परीक्षण करने के लिए इसका उपयोग करना संभव नहीं है। इस मुद्दे में इस पर चर्चा की गई है।

मैं अभी भी ES मॉड्यूल का परीक्षण करने में सक्षम होना चाहता हूं ताकि मैं उन्हें नोड या ब्राउज़र में सुरक्षित रूप से चला सकूं।

वर्तमान मॉड्यूल चर्चाओं के संबंध में, आम सहमति है कि .mjs अंतिम परिणाम में उपलब्ध होना चाहिए (शायद एकमात्र समाधान के रूप में नहीं, लेकिन कम से कम उपलब्ध है) और यह कि import("./foo.mjs") के लिए एक वादा वापस करेगा संबंधित ES नामस्थान। तथ्य यह है कि CJS मॉड्यूल को default निर्यात के साथ एक मॉड्यूल में परिवर्तित किया जाता है, जो $#$7 module.exports #$ के अनुरूप होता है, इस पर अधिक बहस होती है, लेकिन यह एक सुरक्षित धारणा प्रतीत होती है।

क्या मोचा में गतिशील import का उपयोग करके मूल ES समर्थन जोड़ने पर पुनर्विचार करना संभव होगा? बेहतर संकेत के लिए फीचर फ्लैग का नाम बदलकर --experimental-es-modules (#3253 से) किया जा सकता है कि यह नोड के समर्थन की वर्तमान प्रगति पर निर्भर है।
समय सीमा के अनुसार, अंतिम युक्ति नोड 12 तक नहीं आएगी, इसलिए वर्तमान कार्यान्वयन कुछ समय के लिए वहां रहेगा (और अंतिम प्रस्ताव का अपेक्षाकृत सुरक्षित उपसमुच्चय है)।

@demurgos मैं व्यक्तिगत रूप से मोचा पर किसी भी कोड कार्यान्वयन के लिए प्रतिबद्ध होने से पहले इस पर थोड़ा और इंतजार करना पसंद करता हूं। लेकिन शायद @boneskull या @ScottFreeCode असहमत हैं?

@demurgos

esm पैकेज (जिसे पहले @std/esm नाम दिया गया था) ने इस कमिट में .mjs फाइलों का समर्थन छोड़ दिया।

esm लोडर ने .mjs के लिए समर्थन नहीं छोड़ा। हम केवल वर्तमान --experimental-modules कार्यान्वयन का अनुसरण करते हैं और .mjs को require $ के साथ लोड करने का प्रयास करते समय एक त्रुटि उत्पन्न करते हैं। उपयोगकर्ता अभी भी अपनी परीक्षण प्रविष्टि फ़ाइल के लिए .js फ़ाइल का उपयोग कर सकते हैं जो .mjs या .js की बाद की परीक्षण फ़ाइलों को लोड करने के लिए ESM सिंटैक्स या गतिशील import() का उपयोग करती है, बहुत कुछ जैसे esm अपने स्वयं के परीक्षणों के लिए करता है।

समय सीमा के अनुसार, अंतिम युक्ति नोड 12 तक नहीं आएगी, इसलिए वर्तमान कार्यान्वयन कुछ समय के लिए वहीं रहेगा

--experimental-modules को ध्वजांकित न किए जाने के लिए कोई निर्धारित समय नहीं है। उम्मीद है कि यह नोड 10 के समर्थन चक्र में कभी भी उतर सकता है _(इसलिए अगले 2 वर्षों में कुछ समय)_ लेकिन पत्थर में कुछ भी सेट नहीं है।

(और अंतिम प्रस्ताव का अपेक्षाकृत सुरक्षित उपसमुच्चय है)।

वर्तमान --experimental-modules कार्यान्वयन अंतिम प्रस्ताव के साथ संगत नहीं हो सकता है। नोड में ईएसएम समर्थन कैसा दिखेगा, इसके बारे में कई चर्चाएं हैं। कुछ प्रस्तावित निर्देश वर्तमान प्रायोगिक कार्यान्वयन के अनुकूल नहीं हैं। इस पर निर्भर करते हुए कि --experimental-modules के लिए आज आपके द्वारा लिखे गए कोड को चीजें कैसे हिलाती हैं, हो सकता है कि अंतिम रूप जो भी हो, उसके साथ काम न करें।

esm लोडर ने .mjs के लिए समर्थन नहीं छोड़ा।

मेरा कहना है कि esm अब .mjs की आवश्यकता को सक्षम नहीं करता है, इसलिए अब आप .mjs के लिए मोचा की परीक्षण खोज का उपयोग नहीं कर सकते हैं। लेकिन आप सही कह रहे हैं, इसे प्रलेखित नहीं किया गया था, इसलिए यह वास्तव में एक ब्रेकिंग बदलाव नहीं है, भले ही अन्य लोग इस पर भरोसा करते हों।

समय सीमा के संबंध में, मैं इस मुद्दे का जिक्र कर रहा था। ऐसा लगता है कि नोड 11 के लिए एक प्रयास और नोड 12 के लिए अंतिम कार्यान्वयन है, इसलिए इसे नोड 10 एलटीएस में पोर्ट किया जा सकता है। कुछ चाहते हैं कि यह जल्दी हो जाए, अन्य ने इसे जल्दी न करने की चेतावनी दी।

मेरा प्रस्ताव #3253 का विलय करना है। यह केवल परीक्षण मामलों को लोड करने के लिए require $ के बजाय import(...) का उपयोग करने के लिए एक ऑप्ट-इन तंत्र प्रदान करता है। चूंकि मुझे उम्मीद है कि इसे ज्यादातर .mjs के संदर्भ में --experimental-modules के लिए लागू किया जाएगा, मुझे अभी भी लगता है कि यह सुरक्षित है। ( .mjs का गतिशील आयात एक नामस्थान वादा लौटाने की संभावना है)। लेकिन मैं आपको यह तय करने दूंगा कि क्या आप इसे मर्ज कर सकते हैं और इसके लिए बहुत अधिक दबाव डालने से बचें।

फिर, इस पीआर का मुख्य कारण यह है कि इसके बिना, आप अब मोचा की परीक्षण खोज का उपयोग नहीं कर सकते हैं, लेकिन @jdalton द्वारा ऊपर वर्णित समाधान का उपयोग करना होगा। ( .js प्रवेश बिंदु और मैन्युअल आयात)

मेरा प्रस्ताव #3253 का विलय करना है।

3253 में कुछ खामियां थीं, निश्चित रूप से इसे मर्ज करना एक अच्छा विचार नहीं है।

@jdalton उदाहरण के बाद, मैंने esm पैकेज (शुद्ध नोड + मोचा) के बिना देशी ईएसएम का परीक्षण करने के लिए एक छोटा वर्कफ़्लो सेट किया है।
मैं एसिंक्रोनस परीक्षण परिभाषाओं ( --delay का उपयोग करके) और --experimental-modules का उपयोग करता हूं।

वर्तमान में, _mocha_ केवल CJS आयात कर सकता है, और CJS केवल गतिशील import() छद्म-कार्य का उपयोग करके ESM आयात कर सकता है। तो मैं निम्नलिखित सीजेएस प्रविष्टि बिंदु उत्पन्न करता हूं (इसका नाम .js के साथ समाप्त होता है) जो विशिष्ट फाइलों को आयात करता है और परीक्षण निष्पादन को ट्रिगर करता है:

test.esm.js :

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

(मैं निर्माण समय पर आयात की सूची के साथ प्रवेश बिंदु उत्पन्न करता हूं, लेकिन आप इसे मैन्युअल रूप से लिख सकते हैं या वहां glob का उपयोग कर सकते हैं।)

मैं फिर इसे निम्न आदेश के साथ निष्पादित करता हूं:

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

मुझे NODE_OPTIONS से गुजरना पड़ता है क्योंकि झंडा मोचा द्वारा पहचाना नहीं जाता है।

मुझे अब भी उम्मीद है कि मोचा प्रयोगात्मक ईएसएम के लिए बेहतर समर्थन प्रदान करेगा, लेकिन कम से कम यह जानकर अच्छा लगा कि आज अन्य उपकरणों के बिना इसका उपयोग करने का एक तरीका है।

@demurgos यह एक अच्छा सा कामकाज है जिसे आपने पाया है: +1:।

यह देखना अच्छा है कि मोचा के साथ ईएस मॉड्यूल का उपयोग करना वास्तव में संभव है (यदि आसान नहीं है): मुस्कान:।

@demurgos यह मुद्दा ट्रांसपिलर उपयोग के बिना ES6 शैली परीक्षणों का समर्थन करने के बारे में है। "बिल्ड टाइम" क्या है? वह कोड जिसका उपयोग आप परीक्षण प्रवेश बिंदु उत्पन्न करने के लिए करते हैं, एक ट्रांसपिलर है , बस एक विशेष है।

@rulatir
मैंने उल्लेख किया है कि मैं बिल्ड टूल्स का उपयोग करता हूं, लेकिन वे इस मुद्दे में चर्चा किए गए स्तर नहीं हैं: मोचा देशी ईएसएम के साथ चल रहा है, न कि ईएसएम एक ट्रांसपिलर द्वारा सीजेएस को कम किया गया है।

मेरा संदेश देखें:

मैं निर्माण समय पर आयात की सूची के साथ प्रवेश बिंदु उत्पन्न करता हूं, लेकिन आप इसे मैन्युअल रूप से लिख सकते हैं या वहां glob का उपयोग कर सकते हैं।

मैंने एक बिल्ड चरण का उपयोग किया क्योंकि मैं चाहता हूं कि मेरे आयात (1) स्थिर रूप से परिभाषित हों और (2) सूची को स्वयं बनाए रखें।

यदि आपके पास केवल कुछ विशिष्ट फ़ाइलें हैं, तो छोड़ना (2) ठीक है: बस अपनी 1-2 विशिष्ट फ़ाइलों को आयात करने के लिए एक प्रवेश बिंदु है।
(1) परीक्षण फ़ाइलों के लिए पहले से ही एक विशिष्ट आवश्यकता है, इसलिए यह ज्यादातर "अच्छी-से-अच्छी" चीज है और आप रनटाइम पर glob का उपयोग कर सकते हैं (मेरे जैसे निर्माण समय के बजाय)। यह केवल एक विवरण है जो मूल विचार को समझने के बाद अंत में कोई मायने नहीं रखता है।

यदि आप रनटाइम पर एमजेएस स्पेक फाइलों को ढूंढते हुए एक साधारण कॉपी-पेस्ट समाधान की तरह कुछ चाहते हैं, तो यहां एक उदाहरण दिया गया है:

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

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

इसे NODE_OPTIONS="--experimental-modules" mocha --delay test.esm.js के साथ चलाएं।
जैसा कि आप देखते हैं, कोई निर्माण नहीं, लेकिन कोड में थोड़ा और शोर।

मैं एक बॉट हूं जो निष्क्रियता के मुद्दों को देखता है।
इस समस्या में हाल की कोई गतिविधि नहीं है, और मैं इसे stale लेबल कर रहा हूं। 14 दिनों में, अगर कोई और टिप्पणी या गतिविधि नहीं होती है, तो मैं इस मुद्दे को बंद कर दूंगा।
मोचा में योगदान के लिए धन्यवाद!

यह समस्या अभी भी मान्य है और इसे बंद नहीं किया जाना चाहिए।

आगामी mocha@6 रिलीज में श्वेतसूचीबद्ध --experimental-modules ध्वज होगा जो ES6 मॉड्यूल के साथ अधिक आसानी से प्रयोग करने की अनुमति देगा। क्या v6 से पहले मामूली या पैच रिलीज होना संभव होगा? मैं वर्तमान में एक नए कवरेज टूल को अंतिम रूप दे रहा हूं जो इस्तांबुल के बजाय वी 8 डीबगर का उपयोग करता है और इसे मोचा और ईएस 6 मॉड्यूल के साथ परीक्षण करना चाहता है (मेरे पैकेज में गिट निर्भरता का उपयोग किए बिना। जेसन)।

@demurgos

जब मैं इस तरह की कोशिश करता हूं ...

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

मुझे मिला

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

लेकिन जब मैं इस तरह दौड़ता हूं ...

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

यह सही चलता है मैं क्या खो रहा हूँ?

@demurgos आपको @bcoe के साथ समन्वय करना चाहिए; देखें https://github.com/bcoe/c8

@demurgos एक मामूली रिलीज में कटौती करने के लिए, हमें एक शाखा में v5.2.0 के बाद से सभी गैर-ब्रेकिंग परिवर्तनों को चेरी करने और उन्हें चेंजलॉग में संकलित करने की आवश्यकता होगी। अगर आप या कोई और उस काम को करने को तैयार है, तो हम रिलीज में कटौती कर सकते हैं।

fwiw मैं esm को --experimental-modules से अधिक की अनुशंसा करता हूं जब तक कि Node.js की कहानी सीधी न हो। यह एक बड़ा इंतजार होगा।

@बोनस्कुल
हा हा धन्यवाद। मैं जुलाई से लगभग c8 के आसपास काम कर रहा हूं (मैंने इस रेपो पर पीआर और मुद्दों का एक समूह खोला)। कुछ डिज़ाइन निर्णय भी हैं जहाँ हम असहमत हैं इसलिए हम अधिकांश निर्भरताओं को साझा करने का प्रयास करते हैं (उदाहरण के लिए मैंने मर्ज एल्गोरिथम लिखा था) और निर्णय लिया कि मैं एक और टूल प्रकाशित करूंगा: c88 । मुझे यह इस सप्ताह के अंत में काम करने के लिए मिला है और अब मैं इसे अपने पुस्तकालयों पर परीक्षण कर रहा हूं। मैं इसे सीआई में देशी ईएसएम और मोचा के साथ उपयोग करने में सक्षम हूं। मुझे अभी भी इसे दस्तावेज और ठीक करने के लिए कुछ समय चाहिए लेकिन यह जनवरी में तैयार हो जाना चाहिए)।

@jrgleason
मैंने अपने सिर के शीर्ष के ऊपर कोड लिखा था। ऐसा लगता है कि यहां मुद्दा यह है कि globSync सापेक्ष पथ लौटाता है जो ./ या ../ से शुरू नहीं होता है। आप इसे ./ के साथ प्रीपेड करना चाह सकते हैं: इसे सरल सापेक्ष पथों के साथ काम करना चाहिए।
आपको यह भी ध्यान रखना चाहिए कि डायनामिक आयात सापेक्ष URL का उपयोग करते हैं: # , ? और अन्य विशेष वर्णों को अलग तरीके से नियंत्रित किया जा सकता है। यदि आप एक ठोस ठोस समाधान चाहते हैं, तो आपको मॉड्यूल के पूर्ण पथ को हल करना चाहिए और फिर इसे एक फ़ाइल URL में परिवर्तित करना चाहिए। कवरेज पर मेरे काम के हिस्से के रूप में, मैंने पूर्ण पथ और यूआरएल के बीच कनवर्ट करने के लिए एक lib लिखा था: आप fromSysPath से furi का उपयोग करना चाह सकते हैं। रूपांतरणों को किसी भी प्रकार के पथ (यहां तक ​​​​कि विंडोज नेमस्पेस और यूएनसी पथ ...) को संभालना चाहिए।

यहाँ एक पूरा उदाहरण कैसा दिख सकता है:

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

मेरा मतलब है, mocha --require esm बस काम नहीं करता है? क्या हमें वास्तव में स्वचालित पहचान की आवश्यकता है? यह मुश्किल लगता है और ओवरहेड जोड़ता है ...

@demurgos एक मामूली रिलीज में कटौती करने के लिए, हमें एक शाखा में v5.2.0 के बाद से सभी गैर-ब्रेकिंग परिवर्तनों को चेरी करने और उन्हें चेंजलॉग में संकलित करने की आवश्यकता होगी। अगर आप या कोई और उस काम को करने को तैयार है, तो हम रिलीज में कटौती कर सकते हैं।

प्रस्ताव के लिए धन्यवाद। --experimental-modules के साथ NODE_OPTIONS प्राप्त करना अभी भी संभव है, इसलिए यह उच्च प्राथमिकता नहीं है (और यह चेरी-पिक कमिट्स के लिए गिट ट्री को जटिल बना सकता है)। अगर मैं अन्य निर्भरताओं के साथ अपने मुद्दों को बंद करने का प्रबंधन करता हूं, तो मैं देखूंगा कि मैं इस पर कुछ समय बिता सकता हूं या नहीं। इस बीच, मैं सिर्फ v6 मील के पत्थर पर नजर रखता हूं।

fwiw मैं esm से अधिक --experimental-modules की अनुशंसा करता हूं जब तक कि Node.js की कहानी सीधी न हो। यह एक बड़ा इंतजार होगा।
मेरा मतलब है, क्या मोचा --require esm बस काम नहीं करता है?

मैं निश्चित रूप से सहमत हूं कि यह अभी सबसे अच्छा समाधान है: यह स्थापित करने का सबसे आसान समाधान है और कुछ समय के लिए बाहर हो गया है: यह काम करता है। मेरे मामले में, मैं अपने स्वयं के निर्माण उपकरण बनाए रख रहा हूं और क्लासिक सीजेएस बिल्ड के विकल्प के रूप में देशी ईएसएम को संभाल रहा हूं। मूल ईएसएम के लिए वास्तव में उत्सुक होने के बावजूद, मैं अभी भी इसे आपके कोड को चलाने के एकमात्र तरीके के रूप में उपयोग नहीं करने की सलाह देता हूं: यह प्रयोगात्मक है: अटक_आउट_ जीभ:।

मेरे हाल के अधिकांश संदेश यह साझा करने के बारे में हैं कि देशी ईएसएम का उपयोग करके क्या किया जा सकता है। यह ज्यादातर प्रायोगिक कार्य है और मुझे उम्मीद है कि जब नोड का ईएसएम स्थिर हो जाएगा तो मुझे इसे बदलना होगा। दीर्घकालिक समाधान के लिए ऐसे लाभ हैं जिनके लिए esm पैकेज की आवश्यकता नहीं है। यहाँ मेरे कारण हैं:

• यह आवश्यक उपकरणों की मात्रा को कम करता है (कम जटिलता, समझने के लिए कम विन्यास)
• वास्तविक ESM और esm किनारे के मामलों के बीच कुछ अंतर हो सकते हैं (मूल्यांकन त्रुटियां, चक्र, लोड त्रुटियां, async/गतिशील मॉड्यूल, wasm, आदि)। आइसोमॉर्फिक कोड लिखते समय, व्यवहार विचलन के किसी भी संभावित स्रोत को कम करना सुरक्षित हो सकता है। यह मूल कवरेज से भी संबंधित है: esm के साथ, V8 ट्रांसपाइल आउटपुट देखता है, इसलिए आपको स्रोत मानचित्रों से निपटना होगा (अभी तक समर्थित नहीं है c8 , लेकिन मैं एक पीआर तैयार कर रहा हूं, वे c88 पर काम करते हैं)। डिबगिंग करते समय अन्य अंतर भी दिखाई दे सकते हैं।
• यह कोड को गतिशील रूप से ट्रांसपाइल करने से बचता है और प्रदर्शन को बेहतर बनाने में मदद करता है।

क्या हमें वास्तव में स्वचालित पहचान की आवश्यकता है? यह मुश्किल लगता है और ओवरहेड जोड़ता है ...

मुझे यकीन नहीं है कि आप किस स्वचालित पहचान की बात कर रहे हैं। क्या यह उस पीआर से संबंधित है जिसे इस साल की शुरुआत में भेजा गया था?

संपादित करें : यदि आप चर्चा करना चाहते हैं तो मैं नोड टूलिंग स्लैक (ज्यादातर #c8 चैनल पर सक्रिय) पर भी हूं।

@demurgos मुझे लगता है कि मैं थोड़ा उलझन में था कि लोग यहां क्या चाहते हैं। वैसे भी...

यदि NODE_OPTIONS=--experimental-modules मोचा v6.0.0 में --experimental-modules समर्थित होने तक काम करता है, तो क्या इस मुद्दे के लिए कोई अन्य कार्य किया जाना है? मुझे तो यही याद आ रहा है।

मैं उम्मीद करता हूं कि यह मुद्दा तब तक खुला रहना चाहिए जब तक कि मूल ईएसएम ("ट्रांसपिलर उपयोग के बिना ईएस 6 शैली परीक्षण") बॉक्स से बाहर काम करता है / जितनी आसानी से सीजेएस वर्तमान में काम करता है।

मैंने --delay और NODE_OPTIONS=--experimental-modules के साथ जो समाधान पोस्ट किया है वह उचित समर्थन से अधिक एक समाधान है। एक बार जब आप mocha **/*.spec.mjs चलाने और एक रिपोर्ट प्राप्त करने में सक्षम हो जाएंगे तो मैं इस मुद्दे को ठीक करने पर विचार करूंगा।

दुर्भाग्य से, फिलहाल मुझे लगता है कि हमें अभी भी ईएसएम समर्थन का पता लगाने के लिए नोड की प्रतीक्षा करनी है। मुझे जांचना होगा, लेकिन मुझे लगता है कि पीआर ने स्वचालित पहचान का उपयोग नहीं किया बल्कि गतिशील आयात का उपयोग करके हर मॉड्यूल (सीजेएस या ईएसएम) को आयात किया। कार्यान्वयन मॉड्यूल के लिए इंटरऑप कहानी पर निर्भर करेगा।

संपादित करें : मैं https://github.com/mochajs/mocha/pull/3253 की बात कर रहा हूं। यह सभी मॉड्यूल को ईएसएम (कोई स्वचालित पहचान नहीं) के रूप में लोड करने की अनुमति देता है।

मैं एक बॉट हूं जो निष्क्रियता के मुद्दों को देखता है।
इस समस्या में हाल की कोई गतिविधि नहीं है, और मैं इसे stale लेबल कर रहा हूं। 14 दिनों में, अगर कोई और टिप्पणी या गतिविधि नहीं होती है, तो मैं इस मुद्दे को बंद कर दूंगा।
मोचा में योगदान के लिए धन्यवाद!

नोड 12 में नया ईएसएम कार्यान्वयन शामिल होना चाहिए। यह मोचा में ईएस मॉड्यूल का समर्थन करने के तरीके की जांच करने का अवसर होगा।

मोचा ईएसएम का उपयोग करते समय मैंने जीसी बग मारा, लेकिन इसकी सूचना दी गई और पुष्टि की गई, इसलिए इसे ठीक किया जाना चाहिए: https://github.com/nodejs/node/issues/27492।

इस बग के अलावा, ऊपर मेरी टिप्पणी में वर्णित रणनीति अभी भी ईएसएम के साथ मोचा का उपयोग करने के लिए काम करती है।

हाय मोचा लोग, अच्छा टूल बनाने और बनाए रखने के लिए धन्यवाद!

यह सिर्फ FYI टिप्पणी है। पिछले कुछ महीनों से मैं नीचे दिए गए पैच का उपयोग करके मोचा और * -test.mjs पर काम कर रहा हूं। mocha test/*.mjs (बिना ट्रांसपिलर या esm npm मॉड्यूल के) चलाने में लगभग कोई समस्या नहीं है।
https://gist.github.com/tadd/756d21bad38933c179f10e59bddee6b4

बेशक यह पैच मोचा कमिटर्स के लिए "प्रोडक्शन-रेडी" नहीं है; यह मोचा उपयोगकर्ताओं के लिए सिर्फ एक हैक है जो जल्द से जल्द परीक्षण कोड में ईएसएम का उपयोग करना चाहते हैं।
मुझे --experimental-modules विकल्प के साथ Node.js v11 का उपयोग किया गया है। वर्तमान में मैं v12 के साथ हूं और काम भी करता हूं।

यह एक और कहानी है, लेकिन नोड v12 ने .cjs एक्सटेंशन और "type" फ़ील्ड को package.json में पेश किया। ऐसा लगता है कि इन पर भी विचार करने की आवश्यकता है।

हाय मोचा लोग, अच्छा टूल बनाने और बनाए रखने के लिए धन्यवाद!

वास्तव में, और मैं भी धन्यवाद देना चाहूंगा

लोडफाइल्स को सिंक्रोनस रहने के लिए मैंने एक अलग तरीका अपनाया, नीचे देखें। इसने मेरे लिए फरवरी से काम किया है। कुछ अन्य हैक्स के विपरीत, यह अभी भी c8 का उपयोग करके सभी झंडे, निरीक्षण/ devtools और सटीक कोड कवरेज की अनुमति देता है। वह आखिरी विशेषता इसलिए है कि मुझे वास्तव में मूल ईएसएम की आवश्यकता है, क्योंकि esm पैकेज में प्रत्येक फ़ाइल के लिए अलग-अलग ऑफ़सेट हैं। (मॉड्यूल के निर्यात सूचीबद्ध हो जाते हैं और इस्तांबुल को भ्रमित करते हैं)।

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

नमस्कार! यह किसी भी कोड का परीक्षण करने के लिए भी आवश्यक है जो मूल ES6 प्रोजेक्ट पर निर्भर करता है, जैसे lit-element । अन्यथा, यह इस तरह फेंकता है:

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)
    ...

मुझे नहीं पता कि इसके लिए कोई समाधान है या नहीं, लेकिन वर्तमान में मुझे नहीं लगता कि ES6 मूल ढांचे के साथ मोचा का उपयोग करने का कोई तरीका है।

@heruan मैंने उपरोक्त टिप्पणियों में नोड 8 के बाद से काम कर रहे एक समाधान पोस्ट किया। यहाँ एक अद्यतन संस्करण है जिसके लिए मूल फ़ाइल URL रूपांतरणों के लिए Node 10.12 की आवश्यकता है:

निम्नलिखित test.esm.js फ़ाइल जोड़ें:

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

फिर mocha --experimental-modules --delay test.esm.js के साथ परीक्षण चलाएं।

यह कोड ईएसएम परीक्षणों को लोड करने के लिए कॉमनज ब्रिज के रूप में test.esm.js का उपयोग करके काम करता है।

नोड 12 में एक रिपोर्ट की गई समस्या है जहां IIAFE को वें GC (नोडज/नोड#27492) द्वारा एकत्र किया जाता है, इसे अगले छोटे संस्करणों में से एक में तय किया जाना चाहिए (कुछ वर्कअराउंड हो सकते हैं लेकिन मैंने अभी तक उन पर ध्यान नहीं दिया है)। मैं नवीनतम नोड 10 संस्करण का उपयोग करने की सलाह देता हूं जब तक कि यह ठीक न हो जाए।

यदि कोई त्रुटि होती है तो थार UnhandledPromiseRejectionWarning चेतावनी ट्रिगर करेगा। console.error को चेन करना बेहतर है या अन्यथा त्रुटि को संभालना।

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)

_मुझे पता है कि यह import से अधिक require का उपयोग कर रहा है, लेकिन एक समाधान के लिए मेरा सार देखें कि आप ESM भूमि में रहें_

@demurgos दस दिन पहले पोस्ट किए गए नोड 10.12 के लिए कोड स्निपेट के लिए धन्यवाद!

मैं नोड 12.1 चला रहा हूं और ऐसा लगता है कि यह ठीक काम करता है। क्या इसे जल्द ही मोचा में जोड़ा जाएगा, या नोड 12 के साथ ऐसा करने का और भी आसान तरीका है? साथ ही, मैं इसे --watch मोड में कैसे उपयोग करूं?

https://github.com/standard-things/esm --require esm के साथ बॉक्स से बाहर काम करने लगता है, लेकिन एक और निर्भरता को छोड़ना बहुत अच्छा होगा :) धन्यवाद।

यदि मोचा को स्रोत में ESM पर स्विच करना था, तो रोलअप एक ESM वितरण फ़ाइल के साथ-साथ एक CommonJS और/या UMD फ़ाइल प्रदान कर सकता है।

यहां एक और फायदा यह है कि मोचा में खींचने के लिए ब्राउज़र एचटीएमएल को अतिरिक्त स्क्रिप्ट टैग के साथ प्रदूषित करने की आवश्यकता नहीं होगी। परीक्षण फ़ाइलें (या मुख्य परीक्षण प्रवेश फ़ाइल) आयात कर सकती हैं (और परीक्षण फ़ाइलों के भीतर "जादू" से बचें जहां तक ​​​​यह पता लगाना है कि चर कहां से आ रहे हैं - केवल आयात पथ का पता लगाने की आवश्यकता है)।

कोई भी रोलअप के लिए CSS प्लगइन्स का उपयोग कर सकता है, साथ ही mocha.css को इंजेक्ट करने की अनुमति देता है, जिससे HTML अव्यवस्था की आवश्यकता को और कम किया जा सकता है।

मैं एक बॉट हूं जो निष्क्रियता के मुद्दों को देखता है।
इस समस्या में हाल की कोई गतिविधि नहीं है, और मैं इसे stale लेबल कर रहा हूं। 14 दिनों में, अगर कोई और टिप्पणी या गतिविधि नहीं होती है, तो मैं इस मुद्दे को बंद कर दूंगा।
मोचा में योगदान के लिए धन्यवाद!

मुझे लगता है कि यह अभी भी प्रासंगिक है।

क्या कोई मोचा को ES6 मॉड्यूल के साथ चलाने में सक्षम था (संपादित करें: ~ ट्रैविस ~) नोड> = 12.11.0?
12.10.0 पर ऐसा लगता है, मैंने इसे सफलतापूर्वक स्थापित किया:
मोचा-रन.जेएस

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

फिर mocha --experimental-modules --delay ./mocha-run.js आकर्षण की तरह काम करता है।

लेकिन किसी अज्ञात कारण से, 12.11.0 को, यह ऐसा व्यवहार करता है जैसे कोई --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 मैं नोड 12.11.1 पर ES मॉड्यूल के साथ मोचा चला रहा हूं:

__मोचा-रन.जेएस__

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

हालाँकि, वॉच मोड काम नहीं कर रहा है। मोचा फ़ाइल परिवर्तन की प्रतीक्षा करता है, लेकिन फ़ाइल बदलने के बाद कोई अन्य परीक्षण नहीं चलाता है।

@vanslly लकी यू;)
मेरे लिए नोड 12.12.0 (https://travis-ci.org/Palindrom/Palindrom/builds/597771311#L450) और mocha-run.js जैसा कि आपने ऊपर सुझाव दिया है (https://github.com/Palindrom/ पलिंड्रोम/प्रतिबद्ध/49835962bdd61c849f115e271bbc6c3f82d30511#diff-24eabf03aee8844b2b4747aa95a6af7d),

mocha --experimental-modules --delay test/mocha-run.js https://travis-ci.org/Palindrom/Palindrom/builds/597771311#L643 , अभी भी वही त्रुटि फेंकता है

कि यह अभी भी एक मुद्दा है पागल है! ESM अब --प्रायोगिक-मॉड्यूल के पीछे छिपा नहीं है। यह भविष्य है।

गलत, वास्तव में इसकी घोषणा अभी कुछ दिन पहले की गई थी...

बहुत देर हो चुकी है—हम सभी ने जेस्ट में स्विच कर लिया है।

अरे दोस्तों, बस यह सुनिश्चित करना चाहते हैं कि इसे जीवित रखा जाए। कृपया इसे सर्वोच्च प्राथमिकता दें और सभी महान कार्यों के लिए धन्यवाद!

@luijar इस पर #4038 . पर काम किया जा रहा है

हमने कल एक प्रयोगात्मक रिलीज़ v7.0.0-esm1 प्रकाशित की: रिलीज़ नोट देखें।

यह देखना बहुत अच्छा है!

क्या मैं हालांकि पूछ सकता हूं - क्या ब्राउज़र के संदर्भ की कमी का मतलब है कि ईएसएम उपयोग ब्राउज़र पर उपलब्ध नहीं है या केवल यह कि आपको ब्राउज़र संस्करणों को Node. मुझे लगता है कि यह रिलीज नोट में ब्राउज़र के लिए स्थिति का उल्लेख करने में मदद कर सकता है (और यदि समर्थित नहीं है, तो इसके समर्थन के लिए क्या योजनाएं हो सकती हैं)।

@ ब्रेट्ज़9
NodeJs ESM किसी भी तरह से मोचा ब्राउज़र को प्रभावित नहीं करता है। आपके द्वारा अपने ब्राउज़र में चलाए जाने वाले परीक्षण NodeJs द्वारा लोड नहीं किए जाते हैं, आपको इसे स्वयं अपने HTML कोड में करना होगा।

अगर मुझे अच्छी तरह याद है, तो आपको <script> टैग को type="module" विशेषता पर सेट करना होगा। लोडिंग अनुक्रम को बनाए रखने के लिए, आपकी परीक्षण फ़ाइलों और मोचा स्क्रिप्ट दोनों के लिए। ESM को ब्राउज़र के साथ वर्षों से काम करना चाहिए था।

@juergba : हाँ, निश्चित रूप से, लेकिन किसी को एक ईएसएम निर्यात वितरण फ़ाइल की आवश्यकता है ताकि कोई संकलन के बिना import mocha from '../node_modules/mocha/mocha-esm.js'; का उपयोग कर सके - और संकलन का उपयोग करने वालों के लिए (उदाहरण के लिए, ताकि केवल import mocha from 'mocha'; का उपयोग करने में सक्षम हो) module में package.json ताकि बंडलर स्वचालित रूप से ESM बिल्ड की खोज कर सकें।

मोचा कॉमनज में लिखा गया है; हम package.json में "मॉड्यूल" फ़ील्ड नहीं डाल सकते। मोचा ईएसएम में लिखे नोड में चल रहे परीक्षणों का समर्थन करेगा।

यदि आप आंतरिक रूप से ESM का उपयोग करने के लिए रिफैक्टर नहीं करना चाहते हैं, तो आपको अभी भी इसके CommonJS प्लगइन के साथ रोलअप का उपयोग करने में सक्षम होना चाहिए और module का समर्थन करने के लिए ESM लक्ष्य फ़ाइल को इंगित करना चाहिए (जैसे कि सिनॉन ऑफ़र और अधिकांश पैकेज ध्यान दें कि मैंने सामना किया है, jQuery एकमात्र अन्य उल्लेखनीय अपवाद है और वे ईएसएम का उपयोग करने के लिए रिफैक्टरिंग कर रहे हैं)।

मैंने ईएसएम के साथ मोचा का परीक्षण करने के लिए एक नमूना परियोजना बनाई है। मैं सफलतापूर्वक परीक्षण चला सकता हूं, लेकिन (_अभी_) एनवाईसी/इस्तांबुल के साथ कवरेज चलाने में सक्षम नहीं था। आपकी मदद का स्वागत किया जाएगा।

@concatime जब तक nyc को संगत नहीं बनाया जाता, आप c8 का उपयोग कर सकते हैं: https://www.npmjs.com/package/c8

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

@cedx मैंने अपना टेम्पलेट रेपो अपडेट किया है, और यह काम करता है। साफ!

हमने मोचा v7.1.0.1 में नोड के मूल ईएसएम समर्थन को लागू किया।