हम Node.js में ECMAScript मॉड्यूल के लिए समर्थन की घोषणा करते हैं

Node.js 13.2.0 अपने आयात और निर्यात सिंटैक्स के लिए ज्ञात मॉड्यूल के लिए ECMAScript समर्थन के साथ आता है। पहले, यह कार्यक्षमता --experimental-modules ध्वज के पीछे थी, जिसकी अब आवश्यकता नहीं है। हालाँकि, कार्यान्वयन अभी भी प्रायोगिक है और परिवर्तन के अधीन है।

एक अनुवादक से: यह लंबे समय से प्रतीक्षित सुविधा अंत में हमें आधुनिक ब्राउज़रों में पहले से ही उपलब्ध मानक मॉड्यूलर सिंटैक्स का उपयोग करने की अनुमति देगा, और अब झंडे और ट्रांसपैरर्स के बिना नोड्स में भी।

सक्रियण

Node.js निम्नलिखित मामलों में ES मॉड्यूल के रूप में कोड को संसाधित करेगा:

• .mjs एक्सटेंशन वाली फाइलें
• .js एक्सटेंशन के साथ या बिना एक्सटेंशन वाली फाइलें, बशर्ते कि मूल package.json उनके सबसे करीब "type": "module" मान हो
• कोड —-input-type=module के साथ —-eval या STDIN तर्क के माध्यम से पारित कर दिया

अन्य सभी मामलों में, कोड को कॉमनजेएस माना जाएगा। यह "type": "module" बिना .js फाइलों पर लागू होता है "type": "module" निकटतम package.json में "type": "module" --input-type और कमांड लाइन के माध्यम से पारित कोड को निर्दिष्ट किए बिना --input-type । यह पश्चगामी संगतता बनाए रखने के लिए किया जाता है। हालांकि, चूंकि अब हमारे पास दो प्रकार के मॉड्यूल हैं, कॉमनजस और ईएस, स्पष्ट रूप से मॉड्यूल के प्रकार को निर्दिष्ट करना बेहतर होगा।

आप निम्नलिखित विशेषताओं के साथ कॉमनज के रूप में अपने कोड को स्पष्ट रूप से चिह्नित कर सकते हैं:

• .cjs एक्सटेंशन वाली फाइलें
• एक्सटेंशन .js या बिना एक्सटेंशन वाली फाइलें बिल्कुल उपलब्ध हैं, बशर्ते कि निकटतम पैरेंट "type": "“commonjs”"
• कोड को स्पष्ट ध्वज --input-type=commonjs साथ --eval या STDIN तर्क के माध्यम से पारित किया गया

इन विशेषताओं के बारे में अधिक जानने के लिए, "पैकेज स्कोप और फ़ाइल एक्सटेंशन" दस्तावेज़ीकरण अनुभाग और --input-type

सिंटेक्स आयात और निर्यात

ईएस मॉड्यूल के संदर्भ में, आप अन्य जावास्क्रिप्ट फ़ाइलों की ओर इशारा करते हुए, import उपयोग कर सकते हैं। उन्हें निम्नलिखित प्रारूपों में से एक में निर्दिष्ट किया जा सकता है:

• सापेक्ष URL: "./file.mjs"
• पूर्ण URL c file:// , उदाहरण के लिए, "file:///opt/app/file.mjs"
• पैकेज का नाम: "es-module-package"
• पैकेज के अंदर फ़ाइल का पथ: "es-module-package/lib/file.mjs"

आयातों में, आप डिफ़ॉल्ट ( import _ from "es-module-package" ) और नामित मान ( import { shuffle } from "es-module-package" उपयोग कर सकते हैं, साथ ही साथ एक नाम स्थान ( import * as fs from "fs" ) के रूप में सब कुछ आयात कर सकते हैं। import * as fs from "fs" )। सभी बिल्ट-इन Node.js पैकेज, जैसे fs या path , सभी तीन प्रकार के आयातों का समर्थन करते हैं।

ऐसे module.exports कोड की ओर इशारा करते हैं (यानी, सभी मौजूदा जावास्क्रिप्ट जो कि require और module.exports require Node.js के लिए लिखा गया है) केवल डिफ़ॉल्ट विकल्प ( import _ from "commonjs-package" ) का उपयोग कर सकते हैं।

JSON और WASM जैसे अन्य फ़ाइल स्वरूपों को आयात करना प्रायोगिक बना हुआ है, और उन्हें क्रमशः --experimental-wasm-modules --experimental-json-modules और --experimental-wasm-modules --experimental-json-modules आवश्यकता होती है। हालाँकि, आप इन फ़ाइलों का उपयोग कर सकते हैं module.createRequire . module.createRequire API का उपयोग करके, जो अतिरिक्त झंडे के बिना उपलब्ध है।

अपने ES मॉड्यूल में, आप डिफ़ॉल्ट और नामित मानों को निर्यात करने के लिए निर्यात कीवर्ड का उपयोग कर सकते हैं।

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

import.meta.url मॉड्यूल में import.meta.url उपलब्ध है, जिसमें वर्तमान ES मॉड्यूल का निरपेक्ष URL है।

फ़ाइलें और package.json में नया "प्रकार" फ़ील्ड

अपनी परियोजना के package.json में "type": "module" जोड़ें, और Node.js ES मॉड्यूल के रूप में आपकी परियोजना की सभी .js फ़ाइलों को महसूस करना शुरू कर देंगे।

यदि आपके प्रोजेक्ट की कुछ फाइलें अभी भी .cjs उपयोग करती हैं और आप एक बार में पूरे प्रोजेक्ट को माइग्रेट नहीं कर सकते हैं, तो आप इस कोड के लिए .cjs एक्सटेंशन का उपयोग कर सकते हैं, या इसे एक अलग निर्देशिका में रख सकते हैं और package.json जोड़ सकते हैं package.json { "type": "commonjs" } , जो Node.js को बताता है कि इसे { "type": "commonjs" } माना जाना चाहिए।

प्रत्येक डाउनलोड की गई फ़ाइल के लिए, Node.js इसमें मौजूद निर्देशिका में package.json को देखेगा, फिर एक स्तर ऊपर, और इसी तरह जब तक यह रूट डायरेक्टरी तक नहीं पहुंचता। यह तंत्र Babel .babelrc कैसे Babel .babelrc । यह दृष्टिकोण Node.js को पैकेज और विन्यास के बारे में विभिन्न मेटाडेटा के स्रोत के रूप में package.json का उपयोग करने की अनुमति देता है, जैसा कि यह पहले से ही बैबेल और अन्य उपकरणों में काम करता है।

हम अनुशंसा करते हैं कि सभी पैकेज डेवलपर एक type फ़ील्ड निर्दिष्ट करें, भले ही commonjs लिखा गया commonjs ।

पैकेज एंट्री पॉइंट और पैकेज.जॉन में "निर्यात" फ़ील्ड

अब हमारे पास पैकेज में प्रवेश बिंदु को निर्दिष्ट करने के लिए दो क्षेत्र हैं: main और exports । main क्षेत्र Node.js के सभी संस्करणों द्वारा समर्थित है, लेकिन इसकी क्षमताएं सीमित हैं: इसके साथ आप पैकेज में केवल एक मुख्य प्रवेश बिंदु को परिभाषित कर सकते हैं। नया exports क्षेत्र आपको मुख्य प्रविष्टि बिंदु, साथ ही अतिरिक्त पथ को परिभाषित करने की भी अनुमति देता है। यह उन पैकेजों के लिए अतिरिक्त इनकैप्सुलेशन प्रदान करता है जहां पैकेज के बाहर से आयात के लिए केवल स्पष्ट exports पथ उपलब्ध हैं। exports दोनों प्रकार के मॉड्यूल, कॉमनजस और ईएस पर लागू होता है, भले ही वे require या import माध्यम से उपयोग किए जाएं।

यह कार्यक्षमता pkg/feature आयात को वास्तविक पथ जैसे ./node_modules/pkg/esm/feature.js पर इंगित करने की अनुमति देगा। इसके अलावा, अगर आयात pkg/esm/feature.js को संदर्भित करता है जो exports में निर्दिष्ट नहीं है, तो Node.js एक त्रुटि फेंक देगा।

एक अतिरिक्त, अभी भी प्रयोगात्मक, सुविधा, सशर्त निर्यात विभिन्न वातावरणों के लिए विभिन्न फ़ाइलों को निर्यात करने की क्षमता प्रदान करता है। यह पैकेज को कॉमनजेएस कोड को कॉल करने की require("pkg") और ES मॉड्यूल कोड को आयात करने के लिए import "pkg" माध्यम से अनुमति देगा, हालांकि ऐसा पैकेज लिखना अन्य समस्याओं के बिना नहीं है । आप —-experimental-conditional-exports ध्वज के साथ सशर्त निर्यात सक्षम कर सकते हैं।

नए मॉड्यूल की मुख्य रेक

आवश्यक फ़ाइल एक्सटेंशन

आयात का उपयोग करते समय, आपको फ़ाइल एक्सटेंशन को निर्दिष्ट करना होगा। एक निर्देशिका से एक इंडेक्स फ़ाइल आयात करते समय, आपको पूरी तरह से फ़ाइल का पथ निर्दिष्ट करना होगा, अर्थात, "./startup/index.js"।

यह व्यवहार इस बात से मेल खाता है कि अतिरिक्त कॉन्फ़िगरेशन के बिना नियमित सर्वर तक पहुंचने पर ब्राउज़र में आयात कैसे काम करता है।

module.exports , exports , module.exports , __filename , __dirname

कॉमनजस के ये मूल्य ES मॉड्यूल के संदर्भ में उपलब्ध नहीं हैं। हालाँकि, require को module.createRequire() मॉड्यूल में मॉड्यूल. module.createRequire() माध्यम से आयात किया जा सकता है। __filename और __dirname को import.meta.url से प्राप्त किया जा सकता है।

पैकेज बनाना

फिलहाल, हम सुझाव देते हैं कि पैकेज लेखक अपने Node.js परियोजनाओं के लिए या तो पूरी तरह से कॉमनजेस या पूरी तरह से ईएस मॉड्यूल का उपयोग करें। Node.js के लिए मॉड्यूल का काम करने वाला समूह दोहरे पैकेजों के लिए समर्थन में सुधार के तरीकों की तलाश जारी रखता है, नए उपयोगकर्ताओं के लिए विरासत उपयोगकर्ताओं और ES मॉड्यूल के लिए CommonJS। सशर्त निर्यात अब प्रायोगिक हैं और हम इस कार्यक्षमता या इसके विकल्प को जनवरी 2020 के अंत तक या इससे भी पहले रोल आउट करने की उम्मीद करते हैं।

इसके बारे में अधिक जानने के लिए, दोहरी कॉमनज / ईएस मॉड्यूल पैकेज बनाने के लिए हमारे उदाहरण और अनुशंसाएँ देखें ।

आगे क्या होगा

लोडर। कस्टम लोडर लिखने के लिए एपीआई पर काम जारी है, रनटाइम में मॉड्यूल ट्रांसप्लिमेंटेशन को लागू करने के लिए, आयात पथ (पैकेज या व्यक्तिगत फ़ाइलों) को ओवरराइड करने और कोड का इंस्ट्रूमेंटेशन भी। प्रायोगिक एपीआई, —-experimental-loader ध्वज के तहत उपलब्ध है, इससे पहले कि हम इसे ध्वज से हटा दें, महत्वपूर्ण परिवर्तन के अधीन होगा।

दोहरी CommonJS / ES मॉड्यूल पैकेज। हम एक पैकेज को प्रकाशित करने के लिए एक मानक तरीका प्रदान करना चाहते हैं जिसका उपयोग कॉमनजस में require माध्यम से और ईएस मॉड्यूल में import माध्यम से किया जा सकता है। प्रलेखन में इसके बारे में हमारे पास अधिक जानकारी है। हम काम को पूरा करने की योजना बनाते हैं और ध्वज से पीछे हटने का समय जनवरी 2020 के अंत तक है, यदि पहले नहीं।

वह सब है! हमें उम्मीद है कि मॉड्यूल के लिए ECMAScript समर्थन Node.js को जावास्क्रिप्ट मानकों के करीब लाता है और पूरे जावास्क्रिप्ट पारिस्थितिकी तंत्र में अनुकूलता के लिए नई सुविधाएँ लाता है। मॉड्यूल समर्थन में सुधार के लिए वर्कफ़्लो यहां सार्वजनिक रूप से किया जा रहा है: https://github.com/nodejs/modules ।