Jest: कृपया ES मॉड्यूल के लिए मूल समर्थन जोड़ने पर विचार करें

जेस्ट का अपना require कार्यान्वयन है (https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js), इसलिए यह सिर्फ की तुलना में अधिक शामिल होगा .mjs को देखने के लिए सिंटैक्स और डिफ़ॉल्ट का समर्थन करना। मैं प्रायोगिक झंडों को सक्रिय करने के भी खिलाफ हूं।

import / export को स्वचालित रूप से ट्रांसपाइल करना संभव हो सकता है, लेकिन शब्दार्थ को लागू करना एक बहुत बड़ा उपक्रम है, और संभवत: नोड 6 के समर्थन के कारण एक वर्ष के लिए अवरुद्ध है।

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

तो बस babel-plugin-transform-es2015-modules-commonjs और babel-plugin-dynamic-import-node को babel-jest जोड़ रहे हैं?

हाँ, मैं यही सोच रहा था।

दोस्तों, https://github.com/standard-things/esm को एकीकृत करने के बारे में क्या? यह तेज़ है और बहुत सारे किनारे के मामलों को बनाए रखता है।

@TrySound वह ठोस रूप से कैसा दिखेगा? क्या आप एक प्रोटोटाइप बना सकते हैं?

हमारे पास अभी भी अपनी आवश्यकता-कार्यान्वयन (मॉक्स के लिए आवश्यक) है, इसलिए मुझे नहीं लगता कि इससे बहुत मदद मिलेगी।

और हमें नोड के नियमों और ब्राउज़र के नियमों दोनों के साथ काम करने की आवश्यकता है।

मुझे सही होने में बहुत खुशी होगी और यह हमारे लिए पूरी तरह से काम करेगा: D

@std/esm जाहिरा तौर पर सिर्फ मजाक के साथ काम करना चाहिए: https://twitter.com/jdalton/status/930257653292400640

क्या कोई इसे घुमा सकता है और दस्तावेज़ों के लिए पीआर के साथ वापस आ सकता है? मैं

मुझे लगता है कि उपयोगकर्ता हर जगह समर्थन चाहते हैं, लेकिन मैंने पाया कि यह केवल परीक्षण फ़ाइलों की निर्भरताओं के लिए काम करता है।

// test.js
require = require('@std/esm')(module, { esm: 'js', cjs: true });
const utils = require('./utils');

// utils.js
export { default as update } from './update';

यह बेहतर है, लेकिन आदर्श नहीं है।

https://github.com/tarunlalwani/jest-overriding-require-function-stackoverflow

तो बस बेबेल-प्लगइन-ट्रांसफॉर्म-एस2015-मॉड्यूल-कॉमनज और बेबेल-प्लगइन-डायनामिक-आयात-नोड को बेबल-जेस्ट में जोड़ना?

मुझे नहीं लगता कि यह एक अच्छा समाधान है, क्योंकि यह कोई "लापता निर्यात" जांच नहीं करता है जो ES मॉड्यूल के साथ बहुत मूल्यवान है। उदाहरण के लिए, रिएक्ट रेपो में मैंने बिल्ड को अधिक बार चलाना शुरू कर दिया क्योंकि रोलअप इन गलतियों को ढूंढता है लेकिन es2015-modules-commonjs साथ जेस्ट नहीं करता है।

@ std/esm जाहिरा तौर पर सिर्फ मजाक के साथ काम करना चाहिए

उनके इंटरऑप में कुछ समय निवेश करना बहुत अच्छा होगा। बहुत यकीन है कि यह हैकी समाधान अंततः टूट जाएगा: https://stackoverflow.com/questions/46433678/specify-code-to-run-before-any-jest-setup-happens। लेकिन अगर यह सिर्फ जेस्ट की तरफ कुछ उजागर करने की बात है, तो इसे समर्थित देखना अच्छा होगा।

@SimenB , मेरे दिमाग में तत्काल कदम बहुत जटिल नहीं होगा। लोगों को .mjs मॉड्यूल के साथ काम करने की अनुमति देना अत्यावश्यक है, भले ही बैबेल परीक्षण दृश्य के पीछे मदद कर रहा हो। अन्यथा लोगों को .mjs का उपयोग करने के लिए अलग परीक्षण समाधान खोजने पड़ सकते हैं।

1. .mjs फ़ाइल को खोजने की अनुमति देने के लिए testMatch गुण को ठीक करें
   (वर्तमान में यह काम नहीं करता है, यहां तक ​​​​कि रेगेक्स पहले से ही सही लगता है, हो सकता है कि कहीं न कहीं एक हार्ड कोड है जो .mjs एक्सटेंशन को खारिज कर रहा है)
2. नोड.जेएस चलाते समय --प्रायोगिक-मॉड्यूल ध्वज पास करें ताकि यह मूल रूप से चल सके
3. जेस्ट को .mjs के साथ ठीक उसी तरह व्यवहार करना चाहिए जैसे आज .js (उदाहरण के लिए jest की आवश्यकता है) - आज .js के अंदर आयात विवरण की अनुमति है, इसलिए केवल .mjs एक्सटेंशन को अनुमति देने की आवश्यकता है।

अंतिम समाधान जटिल हो सकता है और इसमें समय लगता है, लेकिन यह अपरिहार्य है, है ना?

हैलो, क्या कोई इस त्रुटि को ठीक करने में सक्षम है?

हम "नोड --प्रायोगिक-मॉड्यूल" विकल्प के साथ .mjs का उपयोग कर रहे हैं। कोई उपाय?

हम "नोड --प्रायोगिक-मॉड्यूल" विकल्प के साथ .mjs का उपयोग कर रहे हैं। कोई उपाय?

यह प्रयोगात्मक है और पूरी तरह से बाहर नहीं निकला है। बुनियादी चीजों के साथ अभी भी बहुत सारे मंथन हैं, जैसे कि एक बिल्टिन मॉड्यूल को कैसे आयात किया जाए, अभी भी हवा में है। एवीए जैसी परियोजनाओं ने @std/esm को अपने लोडर पाइपलाइन के रूप में उपयोग करने की अनुमति देना शुरू कर दिया है यदि उपयोग किया जाता है (बेबेल को छोड़कर)। शायद मज़ाक एक समान दृष्टिकोण ले सकता है।

@std/esm का समर्थन करना कुछ ऐसा है जो हम करना चाहते हैं, इसे लागू करने में मदद स्वागत से कहीं अधिक है!

@SimenB क्या आप कभी hangouts पर चैट कर सकते हैं?

हाय @SimenB

एक esm उपयोगकर्ता ने esm + जेस्ट डेमो का योगदान दिया है और मुझे लगा कि यह एक अधिक आधिकारिक गाय पथ बनाने के लिए एक अच्छा प्रारंभिक बिंदु हो सकता है।

अद्यतन:

esm + जेस्ट डेमो को मूल मॉड्यूल नाम मैपिंग समर्थन के साथ अपडेट किया गया है।

यह बहुत मजेदार है! साझा करने के लिए धन्यवाद।

हमें यह पता लगाना होगा कि हम एकीकरण को कहाँ चाहते हैं। यह सीएसएस (या अन्य गैर-जेएस संपत्ति) फाइलों को कैसे संभालेगा? क्या यह सिर्फ एक परिवर्तन होना चाहिए? बिल्ट-इन बेबेल ट्रांसफॉर्म के बारे में क्या? आने वाले लोडर की बात करें तो जेस्ट को कैसे व्यवहार करना चाहिए, अगर यह कुछ भी प्रभावित करता है?

ऐसा लगता है कि समुदाय योगदान esm -सक्षम वैकल्पिक जेस्ट रनर (या एक अनौपचारिक/प्रयोगात्मक ध्वज) के लिए एक लाभ हो सकता है ताकि हम इस तरह कुछ प्रगति कर सकें। क्या इसमें जेस्ट टीम की ओर से दिलचस्पी होगी?

require एक धावक में लागू नहीं किया गया है, यह रनटाइम में ही है। इसे प्लग करने योग्य बनाने के लिए किसी भी योगदान का बहुत स्वागत है (संदर्भ #848)।

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

जेस्ट सीजेएस में कैसे टैप करता है, इसके बारे में कुछ बदलाव की आवश्यकता हो सकती है। उदाहरण के लिए, जब module ऑब्जेक्ट का मज़ाक उड़ाया जाता है, तो एक सादे ऑब्जेक्ट का उपयोग करने के बजाय, यह require("module") उपयोग कर सकता है और फिर अनुरोधों को रोकने और आवश्यकतानुसार हथकंडा लगाने के लिए module.require को रैप/ओवरराइट कर सकता है।

अद्यतन:

अब मैं esm साथ जेस्ट को बॉक्स से बाहर करने पर काम कर रहा हूं

@jdalton esm संगतता के साथ कोई अपडेट?

हाय @JasonCust , वाह मेरी टिप्पणी ने कुछ ध्यान आकर्षित किया है!

मैंने esm में जेस्ट समर्थन को सक्षम करने के लिए आवश्यक कार्य की पहचान करने में प्रगति की है। अपने प्रयोगों में मुझे ESM में जेस्ट लोडिंग और मूल्यांकन परीक्षण मिले। esm लोडर पक्ष पर आवश्यक कार्य यह है कि जिस तरह से हम vm.Script संभालते हैं उसे अधिक सामान्य उपयोग करें। फिलहाल हम मुख्य रूप से आरईपीएल उपयोग के लिए उसमें शामिल हैं जो एक एकल मॉड्यूल मानता है। जेस्ट सपोर्ट को हिला देने के लिए हमें इसे थोड़ा और सामान्य बनाना होगा। ऐसा नहीं लगता कि जेस्ट को कुछ भी बदलना होगा। हमारे vm.Script समर्थन का रिफैक्टर अभी भी मेरे TODO पर है और इससे पहले कि मैं प्रयोगात्मक WASM समर्थन जैसी चीज़ों को जारी करूं, इससे अभी भी निपटा जाएगा। फिलहाल मैं उन बगों को खत्म कर रहा हूं जो बेहतर एपीएम और नकली समर्थन के आसपास पॉप अप हुए हैं।

अपडेट @jdalton के लिए धन्यवाद क्योंकि मैं जेस्ट के साथ esm का उपयोग करने में सक्षम होने के लिए उत्साहित हूं। ताकि जब आप उन चीजों पर काम कर रहे हों तो आपको परेशान न करें, क्या esm लिए कोई कार्य है जिसे हम प्रगति के साथ पालन कर सकते हैं?

आप फॉलो रेपो के इस थ्रेड को सब्सक्राइब कर सकते हैं। जेस्ट समर्थन v3.1.0 रिलीज़ में होगा ताकि आप उस संस्करण पर नज़र रख सकें।

@jdalton esm में जेस्ट का समर्थन करने के बारे में कोई खबर?

हाय @दीपज!

यह अभी भी मेरी सूची में है और इसे पूरा करने से पहले मैं जिन वस्तुओं का सामना कर सकता हूं वे सिकुड़ रहे हैं। मैं जेस्ट _ (हालांकि जेस्ट परीक्षणों के भीतर सीजेएस) _ के भीतर esm मॉड्यूल के परीक्षण के पूरक जेस्ट समर्थन में सुधार कर रहा हूं। जेस्ट की ओर से कार्यान्वयन को अभी भी गंभीर रूप से अवरुद्ध करने वाला कुछ भी नहीं है _ (इसलिए उनके लिए कोई काम नहीं करना) _। माइक्रोसॉफ्ट, मेरा नियोक्ता, एक भारी जेस्ट उपयोगकर्ता भी है, इसलिए इसे सुधारना मेरे दिन-नौकरी के लक्ष्यों में से एक है। मैं जल्द ही इससे निपटने की उम्मीद कर रहा हूं।

@jdalton जानना अच्छा है। और आपके काम के लिए धन्यवाद। मैं इसकी सराहना करता हूं!

वास्तव में इस सुविधा की प्रतीक्षा कर रहे हैं :speak_no_evil:

पिछले दो घंटे से इस फीचर को काम करने की कोशिश कर रहे थे। बहुत सारे आंशिक समाधान हैं, आधे-अधूरे उत्तर हैं, सभी एक दूसरे से अलग हैं... नोड.जेएस पैकेज का परीक्षण करना आसान हुआ करता था।

तो बस babel-plugin-transform-es2015-modules-commonjs और babel-plugin-dynamic-import-node को babel-jest जोड़ रहे हैं?

उस विचार का क्या हुआ? इसे लागू करने में कोई दिक्कत?

हाय @jdalton। मैं सोच रहा था कि क्या आप हमें इस मुद्दे की स्थिति के बारे में अद्यतित रख सकते हैं। क्षमा करें यदि मैं आपको परेशान करता हूं, लेकिन मैं इसके लिए कुछ समय से प्रतीक्षा कर रहा हूं, और यह बेहतर होगा कि हमें कम से कम पिछले/अगले छह महीनों के लिए अपडेट प्राप्त हो। शुक्रिया :)

नमस्ते @SurenAt93!

आपके धैर्य के लिए धन्यवाद। मैं जेस्ट समर्थन के साथ महीने के अंत तक रिलीज होने की उम्मीद कर रहा हूं। इसके साथ आप esm को जेस्ट ट्रांसफॉर्म के रूप में निर्दिष्ट करेंगे।

ठंडा। वह परिवर्तन बाबेल से किस प्रकार भिन्न है?

@ केनोट्रॉन

जेस्ट के transform विकल्प का उपयोग करना मेरे लिए esm लोडर को साइड-लोड करने का एक तरीका है। इसलिए जबकि यह तकनीकी रूप से स्रोत को भी बदल रहा है, यह esm लोडर को भी तार-तार कर रहा है।

यदि प्रश्न अधिक है तो Babel और esm क्या अंतर है। बैबेल पैकेजों का एक संग्रह है जो स्रोत को बदल देता है, लक्ष्यों में से एक ईएसएम सिंटैक्स हो सकता है। esm लोडर एक शून्य निर्भरता लोडर है जो रनटाइम वातावरण का अनुकरण करता है। तो esm गतिशील import() जैसी चीजों का समर्थन करता है, प्रासंगिक परीक्षण 262 चश्मा (अस्थायी मृत क्षेत्र, लाइव बाइंडिंग, अग्रिम-त्रुटियां, आदि) पास करता है, और सीजेएस/ईएसएम/डब्ल्यूएएसएम के मिश्रण को लोड करने का समर्थन करता है विन्यास द्वारा स्वाद।

@jdalton आपके काम और समर्थन के लिए धन्यवाद!

@ टॉमहेलर ;)

पिछले दो घंटे से इस फीचर को काम करने की कोशिश कर रहे थे। बहुत सारे आंशिक समाधान हैं, आधे-अधूरे उत्तर हैं, सभी एक दूसरे से अलग हैं... नोड.जेएस पैकेज का परीक्षण करना आसान हुआ करता था।

मैं सहमत हूं।

मैंने एक साधारण Vue प्रोजेक्ट बनाया, जो समस्या को भी प्रकट करता है।
https://github.com/igasparetto/vue-jest-test
मैं इसे काम करने में सक्षम नहीं था।

मैंने निम्नलिखित पृष्ठों के निर्देशों का पालन किया:

• https://vuejs.org/v2/guide/unit-testing.html
• https://medium.com/@kevin_peters/unit -testing-vue-js-components-with-jest-86e14ef499da
• कृपया यह धागा देखें: https://github.com/vuejs/vue-cli/issues/1584

मेरी मशीन (सुनिश्चित नहीं है कि यह मायने रखता है):

• विंडोज 10 प्रो 64-बिट
• नोड v8.9.4
• व्यू: 3.2.3
• एनपीएम: 6.5.0

@ केनोट्रॉन

जेस्ट के transform विकल्प का उपयोग करना मेरे लिए esm लोडर को साइड-लोड करने का एक तरीका है। इसलिए जबकि यह तकनीकी रूप से स्रोत को भी बदल रहा है, यह esm लोडर को भी तार-तार कर रहा है।

यदि प्रश्न अधिक है तो Babel और esm क्या अंतर है। बैबेल पैकेजों का एक संग्रह है जो स्रोत को बदल देता है, लक्ष्यों में से एक ईएसएम सिंटैक्स हो सकता है। esm लोडर एक शून्य निर्भरता लोडर है जो रनटाइम वातावरण का अनुकरण करता है। तो esm गतिशील import() जैसी चीजों का समर्थन करता है, प्रासंगिक परीक्षण 262 चश्मा (अस्थायी मृत क्षेत्र, लाइव बाइंडिंग, अग्रिम-त्रुटियां, आदि) पास करता है, और सीजेएस/ईएसएम/डब्ल्यूएएसएम के मिश्रण को लोड करने का समर्थन करता है विन्यास द्वारा स्वाद।

@kenotron क्या आप कृपया हमें एक अपडेट प्रदान कर सकते हैं?

@igasparetto , यह @jdalton का काम है जो इसे सक्षम करना चाहिए। मैंने अभी तक उस समाधान की कोशिश नहीं की थी।

मुझे लगता है कि नवीनतम स्थिति है: https://twitter.com/jdalton/status/10800627279124934661

हां! क्षमा करें, इसमें मेरी अपेक्षा से अधिक समय लग रहा है। स्थानीय तौर पर अब मेरे पास सभी प्रासंगिक टेस्ट262 टेस्ट पास हो रहे हैं। उन्हें प्राप्त करने के क्रम में मज़ाक से संबंधित परिदृश्य परीक्षण फिसल गए, इसलिए मुझे रिलीज़ होने से पहले उन्हें वापस लेना होगा। यह दुर्गम नहीं है, इसमें थोड़ा समय लगता है। मैं 16 जनवरी को Covalence Conf में प्रस्तुत कर रहा हूँ और तब तक रिलीज़ होने की आशा करता हूँ। अन्य समाचारों में, npm tink ने अपने ESM सिंटैक्स समर्थन के लिए अपनाया ।

16 जनवरी और तब तक रिलीज होने की उम्मीद है

@jdalton मुझे आशा है कि प्रस्तुति अच्छी रही।

क्या आपको कृपया इस रिलीज़ पर कोई अपडेट मिला है?

@igasparetto यह में है https://github.com/standard-things/esm/issues/97#issuecomment -+४५,४९,८५,८९६ और में https://github.com/standard-things/esm/issues/706 ☺️

आपकी योजना बनाने में आपकी सहायता के लिए मैं यहां एक छोटा "डेटा बिंदु" छोड़ रहा हूं। मुझे एहसास है कि आप सभी इस मुद्दे को हल करने के लिए अपना समय और कौशल दान कर रहे हैं। एक देव के रूप में, मैं आपके योगदान की सराहना करता हूं।

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

मुझे यह भी एहसास है कि यह संदेश ऐसे पढ़ेगा जैसे मैं रो रहा हूँ (जो कुछ हद तक मैं हूँ)। मैं वह सारा काम देखता हूं जो मजाक में चला गया है। लेकिन यह ईएसएम सपोर्ट चीज मेरे लिए एक हत्यारा और एक डील ब्रेकर है। सोचा था कि आप कुछ प्रतिक्रिया की सराहना करेंगे, लेकिन यदि नहीं, तो इसे अनदेखा करें या मुझसे इसे हटाने के लिए कहें और मैं करूंगा।

नए मॉड्यूल के प्रकाश में कोई खबर

@dandv मैं कुछ जांच कर रहा हूं कि क्या जेस्ट नोड 12 में देशी ES मॉड्यूल का समर्थन कर सकता है। इसमें vm.SourceTextModule API का उपयोग करके जेस्ट शामिल होगा, जिसके लिए node को पास करने के लिए कुछ CLI झंडे की आवश्यकता होती है।

--experimental-modules --es-module-specifier-resolution=node --experimental-vm-modules

एपीआई सुपर लो-लेवल भी है।

टीबीडी।

https://github.com/nodejs/node/issues/27387 में चर्चा

अद्यतन: नोड के मॉड्यूल लोडर का डिज़ाइन लॉक होने तक प्रतीक्षा करने के लिए कहा गया है। इस बीच, मानक-चीजें/esm#७०६ सबसे अच्छी शर्त हो सकती है।

जेस्ट एक बहुत अच्छा परीक्षण पुस्तकालय है। ईएसएम के लिए समर्थन वास्तव में इसे पूरा करने की जरूरत है!

अद्यतन: नोड के मॉड्यूल लोडर का डिज़ाइन लॉक होने तक प्रतीक्षा करने के लिए कहा गया है। इस बीच, मानक-चीजें/esm#७०६ सबसे अच्छा दांव हो सकता है।

यह मजाक के साथ काम नहीं करता, दुख की बात है।

@jdalton हम lodash-es का उपयोग कर रहे हैं, जो कि lodash-es वेबपैक v4 के साथ ट्री शेकेबल है! (◔ )⊃━☆ﾟ.*・.

दुर्भाग्य से यह हमें समस्याएँ दे रहा है क्योंकि जेस्ट के पास अभी तक कोई ES मॉड्यूल समर्थन नहीं है। हमें उम्मीद है कि यह फीचर जल्द ही जेस्ट का हिस्सा होगा। चाहेंगे किसी को पाने के लिए पता करने के लिए हो lodash-एस जेस्ट के साथ काम?

जेस्ट त्रुटि संदेश के साथ विफल रहता है:

node_modules\lodash-es\lodash.js:10
    export { default as add } from './add.js';
    ^^^^^^

    SyntaxError: Unexpected token export

हमारे jest.config.js

हम जेस्ट-प्रीसेट-कोणीय एनपीएम पैकेज का भी उपयोग कर रहे हैं।

module.exports = {
  testMatch: ['**/+(*.)+(spec|test).+(ts|js)?(x)'],
  transform: {
    '^.+\\.(ts|js|html)$': 'ts-jest'
  },
  resolver: '@nrwl/builders/plugins/jest/resolver',
  moduleFileExtensions: ['ts', 'js', 'html'],
  collectCoverage: true,
  coverageReporters: ['html']
};

दुर्भाग्य से यह हमें समस्याएँ दे रहा है क्योंकि जेस्ट के पास अभी तक कोई ES मॉड्यूल समर्थन नहीं है। हमें उम्मीद है कि यह फीचर जल्द ही जेस्ट का हिस्सा होगा। चाहेंगे किसी को पाने के लिए पता करने के लिए हो lodash-एस जेस्ट के साथ काम?

जेस्ट को बताएं कि ट्रांसफ़ॉर्म करते समय लॉश-एस को नज़रअंदाज़ न करें:

  "transformIgnorePatterns": [
    "[/\\\\]node_modules[/\\\\](?!lodash-es/).+\\.js$"
  ],

https://www.npmjs.com/package/jest-esnext

https://github.com/haraldrudell/ECMAScript2049/tree/master/packages/jest-esnext

@haraldrudell निर्देश के अनुसार यह स्पष्ट नहीं है कि पैकेज का उपयोग कैसे करें, यह कहता है: package.json के बगल में फ़ाइल बनाएं जिसका नाम jest.config.js सामग्री module.exports = require('jest-esnext') , लेकिन क्या होगा यदि मेरे पास पहले से ही एक कॉन्फ़िगरेशन है? कैसे एकीकृत करें?

यह उपयोग की गई फ़ाइल है

https://github.com/haraldrudell/ECMAScript2049/blob/master/packages/jest-esnext/config/jest.config.js

आप _default की सामग्री को अपने jest.config.js से बदलने में सक्षम हो सकते हैं

हाय दोस्तों,
नोड १२.१३.० एलटीएस आखिरकार जारी हो गया ... उस मामले के बारे में कोई खबर?

@ mtsmachado8 मुझे डर है कि इस मामले पर v8 टीम द्वारा अभी भी कुछ समय की आवश्यकता है क्योंकि मुझे लगता है कि ESM मॉड्यूल अभी भी प्रयोगात्मक के रूप में फ़्लैग किए जा रहे हैं ... वे इसके लिए रोडमैप पर विफल हो सकते हैं।

https://nodejs.org/api/esm.html

ध्वजांकित ईएसएम के लिए यह पीआर जगह में है
https://github.com/nodejs/node/pull/29866

@azder @haraldrudell मूल रूप से आपके समाधान में आप node_modules सहित सभी जेएस फाइलों के लिए बेबेल ट्रांसफॉर्मेशन करते हैं?

मेरे मामले में मुझे सीधे आपके प्रीसेट का उपयोग करना पड़ा क्योंकि मुझे ट्रांसफॉर्मर को इस तरह कॉन्फ़िगर करने का तरीका नहीं मिला है:

const babelPreset7Esnext = require('babel-preset-7-esnext');
const babelJest = require('babel-jest');

module.exports = babelJest.createTransformer(
    babelPreset7Esnext(undefined, {decorators: {legacy: true}})
);

नोड में अब मॉड्यूल समर्थन डिफ़ॉल्ट रूप से टॉगल किया गया है

https://github.com/nodejs/node/pull/29866

ईसीएमएस्क्रिप्ट मॉड्यूल डिफ़ॉल्ट समर्थन 13.2.0 में उतरा

https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V13.md#13.2.0

लोडर उपलब्ध होने तक हम इस पर काम नहीं करेंगे। उनके बिना, नोड के पास हुक नहीं हैं जेस्ट को उचित समर्थन प्रदान करने की आवश्यकता है। देखें https://medium.com/@nodejs/announcing -core-node-js-support-for-ecmascript-modules-c5d6dc29b663 (मैं सीधे सेक्शन से लिंक करने में असमर्थ हूं, लेकिन यह "वर्क इन प्रोग्रेस" है। तल पर)

उन लोगों के लिए जो देशी मॉड्यूल का उपयोग करते हैं जेस्ट का उपयोग करना चाहते हैं।
जब आप इस पर काम कर रहे हों तो मैं नोड v. १३.२.० के लिए एक त्वरित सुधार का सुझाव देता हूं:
बेबल-प्लगइन-रूपांतरण-डिफ़ॉल्ट-आयात
उपयोग (_package.json_ में):

{
  "babel": {
    "presets": [
      [
        "@babel/preset-env",
        {
          "targets": {
            "node": "current"
          }
        }
      ]
    ],
    "plugins": ["transform-default-import"]
  },
}

Libs को स्थापित करने की आवश्यकता है:
npm i --save-dev @babel/core @babel/preset-env babel-plugin-transform-default-import

नोट: यदि आपके पास कोई libs नहीं है जिसका नाम निर्यात है (या आप इसका उपयोग नहीं करते हैं)

@infodusha बहुत बढ़िया :)। इसके लिए शुक्रिया।

मेरी परियोजना में यह प्लगइन्स के बिना काम करता है:

npm i --save-dev @babel/preset-env

babel.config.js (इसका नाम इसलिए रखा जाना था, न कि .babelrc ):

module.exports = {
    presets: [
        [
            '@babel/preset-env',
            {
                targets: {
                    node: '13.2',
                },
                modules: 'commonjs',
            },
        ],
    ],

    plugins: [],
};

चाल फाइलों को निर्देशिकाओं में अलग करना और उनमें उपयुक्त package.json का उपयोग करना है:

test डीआईआर में, मैंने इस्तेमाल किया

{
  "type": "commonjs"
}

जबकि src डीआईआर में:

{
  "type": "module"
}

@azder लेकिन यदि आप पैकेज आयात करते हैं जो देशी मॉड्यूल में आयात नाम के सामान्य नाम प्रदान करता है तो आपको इसे डिफ़ॉल्ट आयात के साथ आयात करने की आवश्यकता होती है और बेबेल में आपको नामित आयात का उपयोग करने की आवश्यकता होती है। संभवतः, आपके पास ऐसा कोई पैकेज नहीं है, या पैकेज जो es6 निर्यात प्रदान करते हैं, लेकिन सभी पैकेज इसे कल करने के लिए तैयार नहीं हैं

@infodusha शायद मेरे पास अब क्या नहीं है? क्या आपने मैंने जो लिखा है उसे आजमाया और इसके साथ समस्या ढूंढी या क्या आप मानते हैं कि मुझे इसका उपयोग करने में समस्याएं हैं?

एक वास्तविक उदाहरण प्रदान करें क्योंकि मैं स्पष्ट नहीं हूं कि "आयात पैकेज जो देशी मॉड्यूल में आयात नामक सामान्यज प्रदान करता है" से आपका क्या मतलब है।

अब तक मुझे .js फ़ाइल एक्सटेंशन वाली सभी फ़ाइलें लिखने में कोई समस्या नहीं हुई है जहाँ ./src निर्देशिका में "type":"module" और ./test निर्देशिका "type":"commonjs" साथ

const imported = require('../src/module.js').default;
const {anotherOne} = require('../src/module.js');

ऐसा इसलिए है क्योंकि जेस्ट चुपचाप CommonJS कोड के लिए ES मॉड्यूल transpiles है।

मुझे लगता है कि ईएस मॉड्यूल को मूल रूप से परीक्षण करना चाहिए:

(async () => {
    const [
        { default: imported },
        { anotherOne },
    ] = await Promise.all([
        import('../src/some-module.js'),
        import('../src/another-module.js'),
    ]);

    // Rest of your test goes here.
})();

@azder वे वर्कअराउंड हैं।

package.son type=module और इसमें दो फाइलों के साथ mymodule एक निर्देशिका बनाएं: first.js और second.js ।
फिर कोशिश करें import { first } from "mymodule";

नोड ईएसएम का उपयोग करने के लिए आपको जेसन में exports फ़ील्ड की आवश्यकता है, और आजकल कोई पैकेज नहीं है (यानी: लॉश)।

आपका उदाहरण काम करता प्रतीत हो सकता है लेकिन जैसे ही some-module.js या another-module.js से किसी एक नामित मॉड्यूल को import करने का प्रयास करते ही यह टूट जाता है: वे कैस्केड पर तोड़ने जा रहे हैं।

@damianobarbati You _ NEED _ "type": "module" में package.json , इसके बिना, आपके मॉड्यूल की सभी .js फाइलें CommonJS के रूप में लोड की जाएंगी।

exports का उपयोग केवल बाहरी उपभोक्ताओं के संपर्क में आने को सीमित करने के लिए किया जाता है और सशर्त निर्यात के लिए , इसका इस पर कोई प्रभाव नहीं पड़ता है कि .js फ़ाइलों को CommonJS या ESM के रूप में पार्स किया जाएगा या नहीं।

@damianobarbati आप गलत हैं, जैसा कि @ Exe-Boss ने कहा था, btw,

ऐसा इसलिए है क्योंकि जेस्ट चुपचाप ईएस मॉड्यूल को कॉमनजेएस कोड में ट्रांसपाइल करता है।

हां, मैं जेस्ट क्वर्की पर भरोसा करता हूं, यही कारण है कि मैं babel.config.js का उपयोग कर रहा था, यहां तक ​​कि devDependencies बेबेल को जोड़े बिना।

@damianobarbati

कृपया ध्यान दें, मेरे पास एक वर्किंग प्रोजेक्ट है, इसमें मैं जेस्ट ट्रांसपिल्ड का उपयोग कर रहा हूं, जबकि src डायरेक्टरी में मॉड्यूल टाइप है, नोट, ./src वह रूट नहीं है जहां बेबेल कॉन्फिग फाइल है (वह एक सीजेएस है विचित्रताओं के कारण)।

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

मेरी परियोजना में लक्ष्य केवल ईएसएम (टूलिंग वसा को कम करने के लिए) है, इसलिए जेस्ट एकमात्र अपवाद है जो अपने आप ही पार हो जाता है।

@azder ऐसा कुछ? https://github.com/damianobarbati/node-jest/tree/feature/azder-test

@damianobarbati

ऐसा ही कुछ, यहाँ प्रोजेक्ट https://github.com/azder/clip है । ध्यान दें कि ब्लॉग पोस्ट अंश के अंतिम वाक्य के अनुसार मेरे package.json में "निर्भरता" नहीं है, मैंने NPM से ESM और CJS मॉड्यूल को नहीं मिलाने का फैसला किया।

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

https://medium.com/@nodejs/announcing -a-new-experimental-modules-1be8d2d6c2ff

वर्तमान में, ऐसा पैकेज बनाना संभव नहीं है जिसका उपयोग आवश्यकता ('पीकेजी') और आयात 'पीकेजी' दोनों के माध्यम से किया जा सके। इसे संबोधित करने के प्रयास चल रहे हैं, और इसमें उपरोक्त में परिवर्तन शामिल हो सकते हैं। विशेष रूप से, Node.js पैकेज के ES मॉड्यूल प्रविष्टि बिंदु को परिभाषित करने के लिए "मुख्य" के अलावा कोई अन्य फ़ील्ड चुन सकता है। जबकि हम जानते हैं कि समुदाय ने "मॉड्यूल" फ़ील्ड को अपनाया है, यह संभावना नहीं है कि Node.js उस फ़ील्ड को अपनाएगा क्योंकि "मॉड्यूल" का उपयोग करके प्रकाशित किए गए कई पैकेजों में ES मॉड्यूल जावास्क्रिप्ट शामिल है जो Node.js में मूल्यांकन नहीं कर सकता है (क्योंकि एक्सटेंशन फ़ाइल नामों से छूट गए हैं, या कोड में आवश्यक विवरण आदि शामिल हैं)। कृपया Node.js द्वारा उपयोग के लिए लक्षित कोई भी ES मॉड्यूल पैकेज तब तक प्रकाशित न करें जब तक कि इसका समाधान न हो जाए।

कृपया #9430 देखें जिसे मैंने अभी जेस्ट में समर्थन ट्रैक करने के लिए खोला है। मैं इस मुद्दे को चर्चा के लिए खुला रखूंगा।

@SimenB यह एक अच्छा संकेत है! यह और जेस्ट 25 रिलीज नोट्स में मॉड्यूल का उल्लेख जल्द ही समर्थन देखने की उम्मीद देता है।

@SimenB अगर मुझे सही से याद है कि जेस्ट NPM पैकेजों का उपयोग करने में असमर्थ था जो केवल ESM के रूप में प्रकाशित होते हैं, जो कुछ node_modules पैकेजों के लिए भी Babel को सक्षम करने के लिए मजबूर होते हैं। क्या यह बदल गया है?

आपको उपयोगकर्ता और लाइब्रेरी कोड दोनों का समर्थन करने तक आयात/निर्यात को ट्रांसपाइल करने की आवश्यकता होगी

@ सिमेनबी :

आपको उपयोगकर्ता और लाइब्रेरी कोड दोनों का समर्थन करने तक आयात/निर्यात को ट्रांसपाइल करने की आवश्यकता होगी

हमारे मामले के लिए अब तक का सबसे अच्छा तरीका यह है, क्योंकि हमारे सभी पैकेजों में /es/ dir है, लेकिन यह नाजुक है और अन्य परियोजनाओं के लिए उपयुक्त नहीं हो सकता है:

transformIgnorePatterns: ['node_modules/(?!.*?/es/.*\\.js)'],

जेस्ट type: module बावजूद उन पैकेज w/o परिवर्तन को नहीं उठाता है, जैसा आपने कहा था।

आपको उपयोगकर्ता और लाइब्रेरी कोड दोनों का समर्थन करने तक आयात/निर्यात को ट्रांसपाइल करने की आवश्यकता होगी

इस पर कोई कठिन समय सारिणी?
नोड 14 रिलीज से:

यह हमारा विश्वास है कि वर्तमान कार्यान्वयन ईएसएम मॉड्यूल को संलेखित करने के लिए भविष्य के सबूत मॉडल प्रदान करता है जो यूनिवर्सल जावास्क्रिप्ट का मार्ग प्रशस्त करता है। कृपया हमारे दस्तावेज़ीकरण में और पढ़ें।

Node.js में ESM कार्यान्वयन अभी भी प्रायोगिक है, लेकिन हम मानते हैं कि हम Node.js में ESM को "स्थिर" कहने में सक्षम होने के बहुत करीब पहुंच रहे हैं। चेतावनी को हटाना उस दिशा में एक बड़ा कदम है।

जैसे कि मैं एनपीएम पैकेजों को निर्यात करने के लिए अनिच्छुक हूं (जो कि जेस्ट परीक्षण ढांचे को लागू करने वाले परीक्षणों द्वारा अच्छी तरह से उपभोग किया जा सकता है) कॉमनजेएस का अधिक समय तक उपयोग कर रहा है।

हम जेस्ट 25.4 से एक प्रयोगात्मक संस्करण भेज रहे हैं। 25.5 में कुछ बग फिक्स हैं, लेकिन यह अभी भी नहीं है जहां इसे होना चाहिए। आप #9430 . में प्रगति का अनुसरण कर सकते हैं