नेटिव तरीके से फ्रंटएंड प्रोजेक्ट्स में पाथ एलियासेस को कैसे कॉन्फ़िगर करें

पथ उपनाम के बारे में

परियोजनाएं अक्सर जटिल, नेस्टेड निर्देशिका संरचनाओं में विकसित होती हैं। नतीजतन, आयात पथ लंबे और अधिक भ्रमित हो सकते हैं, जो कोड की उपस्थिति को नकारात्मक रूप से प्रभावित कर सकते हैं और यह समझना अधिक कठिन बना सकते हैं कि आयातित कोड कहां से उत्पन्न होता है।

पथ उपनामों का उपयोग पूर्व-निर्धारित निर्देशिकाओं के सापेक्ष आयात की परिभाषा की अनुमति देकर समस्या को हल कर सकता है। यह दृष्टिकोण न केवल आयात पथों को समझने के मुद्दों को हल करता है, बल्कि यह रिफैक्टरिंग के दौरान कोड आंदोलन की प्रक्रिया को भी सरल करता है।

 // Without Aliases import { apiClient } from '../../../../shared/api'; import { ProductView } from '../../../../entities/product/components/ProductView'; import { addProductToCart } from '../../../add-to-cart/actions'; // With Aliases import { apiClient } from '#shared/api'; import { ProductView } from '#entities/product/components/ProductView'; import { addProductToCart } from '#features/add-to-cart/actions';

Node.js में पथ उपनामों को कॉन्फ़िगर करने के लिए कई पुस्तकालय उपलब्ध हैं, जैसे कि उपनाम-एचक्यू और tsconfig-पथ । हालाँकि, Node.js प्रलेखन को देखते हुए, मैंने तृतीय-पक्ष पुस्तकालयों पर भरोसा किए बिना पथ उपनामों को कॉन्फ़िगर करने का एक तरीका खोजा।

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

इस लेख में, हम Node.js सबपाथ आयात और इसका उपयोग करके पथ उपनामों को कॉन्फ़िगर करने के तरीके पर चर्चा करेंगे। हम फ्रंटएंड इकोसिस्टम में उनके समर्थन का भी पता लगाएंगे।

आयात क्षेत्र

Node.js v12.19.0 से शुरू होकर, डेवलपर्स npm पैकेज के भीतर पथ उपनाम घोषित करने के लिए सबपाथ आयात का उपयोग कर सकते हैं। यह package.json फ़ाइल में imports फ़ील्ड के माध्यम से किया जा सकता है। पैकेज को एनपीएम पर प्रकाशित करने की आवश्यकता नहीं है।

किसी भी डायरेक्टरी में एक package.json फाइल बनाना काफी है। अतः यह विधि निजी परियोजनाओं के लिए भी उपयुक्त है।

पथ उपनामों के लिए मूल समर्थन के सिद्धांत में निम्नलिखित लाभ हैं:

• किसी तृतीय-पक्ष लाइब्रेरी को स्थापित करने की कोई आवश्यकता नहीं है।

• कोड चलाने के लिए फ्लाई पर आयात को प्री-बिल्ड या प्रोसेस करने की कोई आवश्यकता नहीं है।

• उपनाम किसी भी Node.js- आधारित उपकरण द्वारा समर्थित हैं जो मानक आयात रिज़ॉल्यूशन तंत्र का उपयोग करते हैं।

• कोड नेविगेशन और ऑटो-पूर्णता को बिना किसी अतिरिक्त सेटअप की आवश्यकता के कोड संपादकों में काम करना चाहिए।

मैंने अपनी परियोजनाओं में पथ उपनामों को कॉन्फ़िगर करने का प्रयास किया और व्यवहार में उन कथनों का परीक्षण किया।

पथ उपनामों को कॉन्फ़िगर करना

एक उदाहरण के रूप में, निम्नलिखित निर्देशिका संरचना के साथ एक परियोजना पर विचार करें:

 my-awesome-project ├── src/ │ ├── entities/ │ │ └── product/ │ │ └── components/ │ │ └── ProductView.js │ ├── features/ │ │ └── add-to-cart/ │ │ └── actions/ │ │ └── index.js │ └── shared/ │ └── api/ │ └── index.js └── package.json

पथ उपनामों को कॉन्फ़िगर करने के लिए, आप package.json में कुछ पंक्तियाँ जोड़ सकते हैं जैसा कि दस्तावेज़ीकरण में वर्णित है। उदाहरण के लिए, यदि आप src निर्देशिका के सापेक्ष आयात की अनुमति देना चाहते हैं, तो निम्नलिखित imports फ़ील्ड को package.json में जोड़ें:

 { "name": "my-awesome-project", "imports": { "#*": "./src/*" } }

कॉन्फ़िगर किए गए उपनाम का उपयोग करने के लिए, आयात को इस तरह लिखा जा सकता है:

 import { apiClient } from '#shared/api'; import { ProductView } from '#entities/product/components/ProductView'; import { addProductToCart } from '#features/add-to-cart/actions';

सेटअप चरण से शुरू करते हुए, हमें पहली सीमा का सामना करना पड़ता है: imports क्षेत्र में प्रविष्टियां # प्रतीक से शुरू होनी चाहिए। यह सुनिश्चित करता है कि वे @ जैसे पैकेज विनिर्देशकों से अलग हैं।

मेरा मानना है कि यह सीमा उपयोगी है क्योंकि यह डेवलपर्स को जल्दी से यह निर्धारित करने की अनुमति देती है कि आयात में पथ उपनाम का उपयोग कब किया जाता है, और जहां अन्य कॉन्फ़िगरेशन मिल सकते हैं।

आमतौर पर उपयोग किए जाने वाले मॉड्यूल के लिए अधिक पथ उपनाम जोड़ने के लिए, imports क्षेत्र को निम्नानुसार संशोधित किया जा सकता है:

 { "name": "my-awesome-project", "imports": { "#modules/*": "./path/to/modules/*", "#logger": "./src/shared/lib/logger.js", "#*": "./src/*" } }

लेख को "बाकी सब कुछ बॉक्स से बाहर काम करेगा" वाक्यांश के साथ समाप्त करना आदर्श होगा। हालाँकि, वास्तव में, यदि आप imports क्षेत्र का उपयोग करने की योजना बनाते हैं, तो आपको कुछ कठिनाइयों का सामना करना पड़ सकता है।

Node.js की सीमाएं

यदि आप CommonJS मॉड्यूल के साथ पथ उपनामों का उपयोग करने की योजना बना रहे हैं, तो मेरे पास आपके लिए बुरी खबर है: निम्न कोड काम नहीं करेगा।

 const { apiClient } = require('#shared/api'); const { ProductView } = require('#entities/product/components/ProductView'); const { addProductToCart } = require('#features/add-to-cart/actions');

Node.js में पथ उपनामों का उपयोग करते समय, आपको ESM दुनिया के मॉड्यूल रिज़ॉल्यूशन नियमों का पालन करना चाहिए। यह ईएस मॉड्यूल और कॉमनजेएस मॉड्यूल दोनों पर लागू होता है और इसके परिणामस्वरूप दो नई आवश्यकताएं पूरी होनी चाहिए:

1. फ़ाइल एक्सटेंशन सहित फ़ाइल का पूरा पथ निर्दिष्ट करना आवश्यक है।

   
   

2. किसी निर्देशिका के लिए पथ निर्दिष्ट करने और index.js फ़ाइल आयात करने की अपेक्षा करने की अनुमति नहीं है। इसके बजाय, index.js फ़ाइल का पूरा पथ निर्दिष्ट करने की आवश्यकता है।

मॉड्यूल को सही ढंग से हल करने के लिए Node.js को सक्षम करने के लिए, आयात को निम्नानुसार ठीक किया जाना चाहिए:

 const { apiClient } = require('#shared/api/index.js'); const { ProductView } = require('#entities/product/components/ProductView.js'); const { addProductToCart } = require('#features/add-to-cart/actions/index.js');

कई कॉमनजेएस मॉड्यूल वाले प्रोजेक्ट में imports फ़ील्ड को कॉन्फ़िगर करते समय ये सीमाएँ समस्याएँ पैदा कर सकती हैं। हालाँकि, यदि आप पहले से ही ES मॉड्यूल का उपयोग कर रहे हैं, तो आपका कोड सभी आवश्यकताओं को पूरा करता है।

इसके अलावा, यदि आप बंडलर का उपयोग करके कोड बना रहे हैं, तो आप इन सीमाओं को बायपास कर सकते हैं। इसे कैसे करें, हम नीचे चर्चा करेंगे।

टाइपस्क्रिप्ट में सबपाथ आयात के लिए समर्थन

टाइप चेकिंग के लिए आयातित मॉड्यूल को ठीक से हल करने के लिए, टाइपस्क्रिप्ट को imports क्षेत्र का समर्थन करने की आवश्यकता है। यह सुविधा संस्करण 4.8.1 से शुरू होकर समर्थित है, लेकिन केवल तभी ऊपर सूचीबद्ध Node.js सीमाएं पूरी होती हैं।

मॉड्यूल रिज़ॉल्यूशन के लिए imports फ़ील्ड का उपयोग करने के लिए, कुछ विकल्पों को tsconfig.json फ़ाइल में कॉन्फ़िगर किया जाना चाहिए।

 { "compilerOptions": { /* Specify what module code is generated. */ "module": "esnext", /* Specify how TypeScript looks up a file from a given module specifier. */ "moduleResolution": "nodenext" } }

यह कॉन्फ़िगरेशन imports फ़ील्ड को उसी तरह कार्य करने में सक्षम बनाता है जैसे यह Node.js में करता है। इसका मतलब यह है कि यदि आप मॉड्यूल आयात में फ़ाइल एक्सटेंशन शामिल करना भूल जाते हैं, तो टाइपस्क्रिप्ट आपको इसके बारे में चेतावनी देने वाली त्रुटि उत्पन्न करेगा।

 // OK import { apiClient } from '#shared/api/index.js'; // Error: Cannot find module '#src/shared/api/index' or its corresponding type declarations. import { apiClient } from '#shared/api/index'; // Error: Cannot find module '#src/shared/api' or its corresponding type declarations. import { apiClient } from '#shared/api'; // Error: Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Did you mean './relative.js'? import { foo } from './relative';

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

 { "name": "my-awesome-project", "imports": { "#*": [ "./src/*", "./src/*.ts", "./src/*.tsx", "./src/*.js", "./src/*.jsx", "./src/*/index.ts", "./src/*/index.tsx", "./src/*/index.js", "./src/*/index.jsx" ] } }

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

 // OK import { apiClient } from '#shared/api/index.js'; // OK import { apiClient } from '#shared/api/index'; // OK import { apiClient } from '#shared/api'; // Error: Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Did you mean './relative.js'? import { foo } from './relative';

हमारे पास एक शेष समस्या है जो सापेक्ष पथ का उपयोग करके आयात करने से संबंधित है। यह समस्या पथ उपनामों से संबंधित नहीं है। टाइपस्क्रिप्ट एक त्रुटि फेंकता है क्योंकि हमने nodenext मोड का उपयोग करने के लिए मॉड्यूल रिज़ॉल्यूशन को कॉन्फ़िगर किया है।

सौभाग्य से, हाल ही में टाइपस्क्रिप्ट 5.0 रिलीज़ में एक नया मॉड्यूल रिज़ॉल्यूशन मोड जोड़ा गया था जो आयात के अंदर पूर्ण पथ निर्दिष्ट करने की आवश्यकता को हटा देता है। इस मोड को सक्षम करने के लिए, tsconfig.json फ़ाइल में कुछ विकल्पों को कॉन्फ़िगर किया जाना चाहिए।

 { "compilerOptions": { /* Specify what module code is generated. */ "module": "esnext", /* Specify how TypeScript looks up a file from a given module specifier. */ "moduleResolution": "bundler" } }

सेटअप पूर्ण करने के बाद, संबंधित पथों के लिए आयात हमेशा की तरह काम करेगा।

 // OK import { apiClient } from '#shared/api/index.js'; // OK import { apiClient } from '#shared/api/index'; // OK import { apiClient } from '#shared/api'; // OK import { foo } from './relative';

अब, हम आयात पथ लिखने के तरीके पर बिना किसी अतिरिक्त सीमा के imports क्षेत्र के माध्यम से पथ उपनामों का पूरी तरह से उपयोग कर सकते हैं।

बिल्डिंग कोड टाइपस्क्रिप्ट के साथ

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

इसलिए, कोड को ESM प्रारूप में संकलित किया जाना चाहिए और Node.js में संकलित कोड को चलाने के लिए type फ़ील्ड को package.json में जोड़ा जाना चाहिए।

 { "name": "my-awesome-project", "type": "module", "imports": { "#*": "./src/*" } }

यदि आपका कोड एक अलग निर्देशिका में संकलित किया गया है, जैसे build/ , मॉड्यूल Node.js द्वारा नहीं पाया जा सकता है क्योंकि पथ उपनाम मूल स्थान, जैसे src/ को इंगित करेगा। इस समस्या को हल करने के लिए, सशर्त आयात पथ का उपयोग package.json फ़ाइल में किया जा सकता है।

यह पहले से निर्मित कोड को src/ निर्देशिका के बजाय build/ निर्देशिका से आयात करने की अनुमति देता है।

 { "name": "my-awesome-project", "type": "module", "imports": { "#*": { "default": "./src/*", "production": "./build/*" } } }

एक विशिष्ट आयात स्थिति का उपयोग करने के लिए, Node.js को --conditions फ़्लैग के साथ लॉन्च किया जाना चाहिए।

 node --conditions=production build/index.js

कोड बंडलर्स में सबपाथ आयात के लिए समर्थन

कोड बंडलर आमतौर पर Node.js में निर्मित एक के बजाय अपने स्वयं के मॉड्यूल रिज़ॉल्यूशन कार्यान्वयन का उपयोग करते हैं। इसलिए, उनके लिए imports क्षेत्र के लिए समर्थन लागू करना महत्वपूर्ण है।

मैंने अपनी परियोजनाओं में वेबपैक, रोलअप और वीट के साथ पथ उपनामों का परीक्षण किया है, और मैं अपने निष्कर्षों को साझा करने के लिए तैयार हूं।

यहाँ पाथ अलियास कॉन्फ़िगरेशन है जिसका उपयोग मैंने बंडलर्स का परीक्षण करने के लिए किया था। आयात के अंदर फ़ाइलों के लिए पूर्ण पथ निर्दिष्ट करने से बचने के लिए मैंने टाइपस्क्रिप्ट के समान ही ट्रिक का उपयोग किया।

 { "name": "my-awesome-project", "type": "module", "imports": { "#*": [ "./src/*", "./src/*.ts", "./src/*.tsx", "./src/*.js", "./src/*.jsx", "./src/*/index.ts", "./src/*/index.tsx", "./src/*/index.js", "./src/*/index.jsx" ] } }

वेबपैक

वेबपैक v5.0 से शुरू होने वाले imports क्षेत्र का समर्थन करता है । पथ उपनाम बिना किसी अतिरिक्त कॉन्फ़िगरेशन के काम करते हैं। यहाँ वेबपैक कॉन्फ़िगरेशन है जिसका उपयोग मैंने टाइपस्क्रिप्ट के साथ एक परीक्षण परियोजना बनाने के लिए किया था:

 const config = { mode: 'development', devtool: false, entry: './src/index.ts', module: { rules: [ { test: /\.tsx?$/, use: { loader: 'babel-loader', options: { presets: ['@babel/preset-typescript'], }, }, }, ], }, resolve: { extensions: ['.ts', '.tsx', '.js', '.jsx'], }, }; export default config;

विटे

Vite संस्करण 4.2.0 में imports क्षेत्र के लिए समर्थन जोड़ा गया था। हालाँकि, संस्करण 4.3.3 में एक महत्वपूर्ण बग को ठीक किया गया था, इसलिए कम से कम इस संस्करण का उपयोग करने की अनुशंसा की जाती है। Vite में, पथ उपनाम dev और build मोड दोनों में अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता के बिना काम करते हैं।

इसलिए, मैंने पूरी तरह से खाली कॉन्फ़िगरेशन के साथ एक टेस्ट प्रोजेक्ट बनाया।

जमना

हालांकि रोलअप का उपयोग Vite के अंदर किया जाता है, लेकिन imports क्षेत्र बॉक्स से बाहर काम नहीं करता है। इसे सक्षम करने के लिए, आपको @rollup/plugin-node-resolve प्लगइन संस्करण 11.1.0 या उच्चतर स्थापित करने की आवश्यकता है। यहाँ एक उदाहरण विन्यास है:

 import { nodeResolve } from '@rollup/plugin-node-resolve'; import { babel } from '@rollup/plugin-babel'; export default [ { input: 'src/index.ts', output: { name: 'mylib', file: 'build.js', format: 'es', }, plugins: [ nodeResolve({ extensions: ['.ts', '.tsx', '.js', '.jsx'], }), babel({ presets: ['@babel/preset-typescript'], extensions: ['.ts', '.tsx', '.js', '.jsx'], }), ], }, ];

दुर्भाग्य से, इस कॉन्फ़िगरेशन के साथ, पथ उपनाम केवल Node.js की सीमाओं के भीतर काम करते हैं। इसका मतलब है कि आपको एक्सटेंशन सहित फ़ाइल का पूरा पथ निर्दिष्ट करना होगा। imports क्षेत्र के अंदर एक सरणी निर्दिष्ट करना इस सीमा को बायपास नहीं करेगा, क्योंकि रोलअप केवल सरणी में पहले पथ का उपयोग करता है।

मेरा मानना है कि रोलअप प्लगइन्स का उपयोग करके इस समस्या को हल करना संभव है, लेकिन मैंने ऐसा करने की कोशिश नहीं की है क्योंकि मैं मुख्य रूप से छोटे पुस्तकालयों के लिए रोलअप का उपयोग करता हूं। मेरे मामले में, पूरे प्रोजेक्ट में आयात पथों को फिर से लिखना आसान था।

टेस्ट रनर में सबपाथ आयात के लिए समर्थन

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

सौभाग्य से, जिन उपकरणों का मैंने परीक्षण किया है वे अच्छी तरह से काम करते हैं। मैंने Jest v29.5.0 और Vite v0.30.1 के साथ पथ उपनामों का परीक्षण किया। दोनों ही मामलों में, पथ उपनामों ने बिना किसी अतिरिक्त सेटअप या सीमाओं के निर्बाध रूप से काम किया। संस्करण v29.4.0 के बाद से जेस्ट को imports क्षेत्र के लिए समर्थन मिला है ।

Vitest में समर्थन का स्तर केवल Vite के संस्करण पर निर्भर करता है, जो कम से कम v4.2.0 होना चाहिए।

कोड संपादकों में सबपाथ आयात के लिए समर्थन

लोकप्रिय पुस्तकालयों में imports क्षेत्र वर्तमान में अच्छी तरह से समर्थित है। हालाँकि, कोड संपादकों के बारे में क्या? मैंने कोड नेविगेशन का परीक्षण किया, विशेष रूप से "गो टू डेफिनिशन" फ़ंक्शन, एक प्रोजेक्ट में जो पथ उपनामों का उपयोग करता है। यह पता चला है कि कोड संपादकों में इस सुविधा के समर्थन में कुछ समस्याएँ हैं।

वीएस कोड

जब वीएस कोड की बात आती है, तो टाइपस्क्रिप्ट का संस्करण महत्वपूर्ण होता है। टाइपस्क्रिप्ट लैंग्वेज सर्वर जावास्क्रिप्ट और टाइपस्क्रिप्ट कोड के माध्यम से विश्लेषण और नेविगेट करने के लिए जिम्मेदार है।

आपकी सेटिंग्स के आधार पर, वीएस कोड टाइपस्क्रिप्ट के अंतर्निहित संस्करण या आपके प्रोजेक्ट में स्थापित संस्करण का उपयोग करेगा।

मैंने टाइपस्क्रिप्ट v5.0.4 के संयोजन में वीएस कोड v1.77.3 में imports क्षेत्र समर्थन का परीक्षण किया।

वीएस कोड में पथ उपनामों के साथ निम्नलिखित मुद्दे हैं:

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

   
   

2. IntelliSense वर्तमान में imports क्षेत्र का उपयोग करके आयात पथ सुझाने का समर्थन नहीं करता है। इस समस्या के लिए एक खुला मुद्दा है।

दोनों मुद्दों को बायपास करने के लिए, आप tsconfig.json फ़ाइल में पथ उपनाम कॉन्फ़िगरेशन को दोहरा सकते हैं। यदि आप टाइपस्क्रिप्ट का उपयोग नहीं कर रहे हैं, तो आप jsconfig.json में भी ऐसा ही कर सकते हैं।

 // tsconfig.json OR jsconfig.json { "compilerOptions": { "baseUrl": "./", "paths": { "#*": ["./src/*"] } } } // package.json { "name": "my-awesome-project", "imports": { "#*": "./src/*" } }

वेबतूफान

संस्करण 2021.3 (मैंने 2022.3.4 में परीक्षण किया) के बाद से, वेबस्टॉर्म imports क्षेत्र का समर्थन करता है । यह सुविधा टाइपस्क्रिप्ट संस्करण से स्वतंत्र रूप से काम करती है, क्योंकि वेबस्टॉर्म अपने स्वयं के कोड विश्लेषक का उपयोग करता है। हालाँकि, वेबस्टॉर्म के पास सहायक पथ उपनामों के संबंध में मुद्दों का एक अलग सेट है:

1. संपादक पथ उपनामों के उपयोग पर Node.js द्वारा लगाए गए प्रतिबंधों का कड़ाई से पालन करता है। यदि फ़ाइल एक्सटेंशन स्पष्ट रूप से निर्दिष्ट नहीं है तो कोड नेविगेशन काम नहीं करेगा। एक index.js फ़ाइल के साथ आयात करने वाली निर्देशिकाओं पर भी यही बात लागू होती है।

   
   

2. वेबस्टॉर्म में एक बग है जो imports क्षेत्र के भीतर पथों की एक सरणी के उपयोग को रोकता है। इस स्थिति में, कोड नेविगेशन पूरी तरह से काम करना बंद कर देता है।

 { "name": "my-awesome-project", // OK "imports": { "#*": "./src/*" }, // This breaks code navigation "imports": { "#*": ["./src/*", "./src/*.ts", "./src/*.tsx"] } }

सौभाग्य से, हम उसी ट्रिक का उपयोग कर सकते हैं जो वीएस कोड की सभी समस्याओं को हल करती है। विशेष रूप से, हम tsconfig.json या jsconfig.json फ़ाइल में पथ उपनाम कॉन्फ़िगरेशन को दोहरा सकते हैं। यह बिना किसी सीमा के पथ उपनामों के उपयोग की अनुमति देता है।

अनुशंसित कॉन्फ़िगरेशन

विभिन्न परियोजनाओं में imports क्षेत्र का उपयोग करने के मेरे प्रयोगों और अनुभव के आधार पर, मैंने विभिन्न प्रकार की परियोजनाओं के लिए सर्वोत्तम पथ उर्फ कॉन्फ़िगरेशन की पहचान की है।

टाइपस्क्रिप्ट या बंडलर के बिना

यह कॉन्फ़िगरेशन उन परियोजनाओं के लिए अभिप्रेत है जहां अतिरिक्त निर्माण चरणों की आवश्यकता के बिना Node.js में स्रोत कोड चलता है। इसका उपयोग करने के लिए, इन चरणों का पालन करें:

1. package.json फ़ाइल में imports फ़ील्ड को कॉन्फ़िगर करें। इस मामले में एक बहुत ही बुनियादी विन्यास पर्याप्त है।

   
   

2. कोड संपादकों में कोड नेविगेशन के काम करने के लिए, jsconfig.json फ़ाइल में पथ उपनामों को कॉन्फ़िगर करना आवश्यक है।

 // jsconfig.json { "compilerOptions": { "baseUrl": "./", "paths": { "#*": ["./src/*"] } } } // package.json { "name": "my-awesome-project", "imports": { "#*": "./src/*" } }

बिल्डिंग कोड टाइपस्क्रिप्ट का उपयोग करना

इस कॉन्फ़िगरेशन का उपयोग उन परियोजनाओं के लिए किया जाना चाहिए जहां स्रोत कोड टाइपस्क्रिप्ट में लिखा गया है और tsc कंपाइलर का उपयोग करके बनाया गया है। इस कॉन्फ़िगरेशन में निम्नलिखित को कॉन्फ़िगर करना महत्वपूर्ण है:

1. package.json फ़ाइल में imports फ़ील्ड। इस मामले में, यह सुनिश्चित करने के लिए सशर्त पथ उपनाम जोड़ना आवश्यक है कि Node.js संकलित कोड को सही ढंग से हल करता है।

   
   

2. ESM पैकेज प्रारूप को package.json फ़ाइल में सक्षम करना आवश्यक है क्योंकि imports फ़ील्ड का उपयोग करते समय टाइपस्क्रिप्ट केवल ESM प्रारूप में कोड संकलित कर सकता है।

   
   

3. एक tsconfig.json फ़ाइल में, ESM मॉड्यूल स्वरूप और moduleResolution सेट करें। यह टाइपस्क्रिप्ट को आयात में भूले हुए फ़ाइल एक्सटेंशन का सुझाव देने की अनुमति देगा। यदि कोई फ़ाइल एक्सटेंशन निर्दिष्ट नहीं है, तो संकलन के बाद कोड Node.js में नहीं चलेगा।

   
   

4. कोड संपादकों में कोड नेविगेशन को ठीक करने के लिए, पथ उपनामों को tsconfig.json फ़ाइल में दोहराया जाना चाहिए।

 // tsconfig.json { "compilerOptions": { "module": "esnext", "moduleResolution": "nodenext", "baseUrl": "./", "paths": { "#*": ["./src/*"] }, "outDir": "./build" } } // package.json { "name": "my-awesome-project", "type": "module", "imports": { "#*": { "default": "./src/*", "production": "./build/*" } } }

बंडलर का उपयोग करके बिल्डिंग कोड

यह कॉन्फ़िगरेशन उन परियोजनाओं के लिए अभिप्रेत है जहाँ स्रोत कोड बंडल किया गया है। इस मामले में टाइपस्क्रिप्ट की आवश्यकता नहीं है। यदि यह मौजूद नहीं है, तो सभी सेटिंग्स को jsconfig.json फ़ाइल में सेट किया जा सकता है।

इस कॉन्फ़िगरेशन की मुख्य विशेषता यह है कि यह आपको आयात में फ़ाइल एक्सटेंशन निर्दिष्ट करने के संबंध में Node.js की सीमाओं को बायपास करने की अनुमति देता है।

निम्नलिखित को कॉन्फ़िगर करना महत्वपूर्ण है:

1. package.json फ़ाइल में imports फ़ील्ड को कॉन्फ़िगर करें। इस स्थिति में, आपको प्रत्येक उपनाम के लिए पथों की एक सरणी जोड़ने की आवश्यकता है। यह एक बंडलर को फ़ाइल एक्सटेंशन निर्दिष्ट करने की आवश्यकता के बिना आयातित मॉड्यूल को खोजने की अनुमति देगा।

   
   

2. कोड संपादकों में कोड नेविगेशन को ठीक करने के लिए, आपको tsconfig.json या jsconfig.json फ़ाइल में पथ उपनामों को दोहराना होगा।

 // tsconfig.json { "compilerOptions": { "baseUrl": "./", "paths": { "#*": ["./src/*"] } } } // package.json { "name": "my-awesome-project", "imports": { "#*": [ "./src/*", "./src/*.ts", "./src/*.tsx", "./src/*.js", "./src/*.jsx", "./src/*/index.ts", "./src/*/index.tsx", "./src/*/index.js", "./src/*/index.jsx" ] } }

निष्कर्ष

imports क्षेत्र के माध्यम से पथ उपनामों को कॉन्फ़िगर करने में तृतीय-पक्ष पुस्तकालयों के माध्यम से इसे कॉन्फ़िगर करने की तुलना में पेशेवरों और विपक्ष दोनों हैं। हालाँकि यह दृष्टिकोण सामान्य विकास साधनों (अप्रैल 2023 तक) द्वारा समर्थित है, इसकी सीमाएँ भी हैं।

यह विधि निम्नलिखित लाभ प्रदान करती है:

• "मक्खी पर" कोड को संकलित या ट्रांसपाइल करने की आवश्यकता के बिना पथ उपनामों का उपयोग करने की क्षमता।

• अधिकांश लोकप्रिय विकास उपकरण बिना किसी अतिरिक्त कॉन्फ़िगरेशन के पथ उपनामों का समर्थन करते हैं। Webpack, Vite, Jest, और Vitest में इसकी पुष्टि की गई है।

• यह दृष्टिकोण एक पूर्वानुमेय स्थान ( package.json फ़ाइल) में पथ उपनामों को कॉन्फ़िगर करने को बढ़ावा देता है।

• पथ उपनामों को कॉन्फ़िगर करने के लिए तृतीय-पक्ष लाइब्रेरी की स्थापना की आवश्यकता नहीं होती है।

हालाँकि, अस्थायी नुकसान हैं जो विकास उपकरण विकसित होने पर समाप्त हो जाएंगे:

• यहां तक कि लोकप्रिय कोड संपादकों को imports क्षेत्र का समर्थन करने में समस्या होती है। इन समस्याओं से बचने के लिए, आप jsconfig.json फ़ाइल का उपयोग कर सकते हैं। हालाँकि, यह दो फ़ाइलों में पथ अन्य कॉन्फ़िगरेशन के दोहराव की ओर जाता है।

• कुछ विकास उपकरण बॉक्स से बाहर imports क्षेत्र के साथ काम नहीं कर सकते हैं। उदाहरण के लिए, रोलअप को अतिरिक्त प्लगइन्स की स्थापना की आवश्यकता होती है।

• Node.js में imports फ़ील्ड का उपयोग करने से आयात पथों पर नई बाधाएँ जुड़ती हैं। ये बाधाएं ईएस मॉड्यूल के समान हैं, लेकिन वे imports क्षेत्र का उपयोग शुरू करना अधिक कठिन बना सकते हैं।

• Node.js बाधाओं के परिणामस्वरूप Node.js और अन्य विकास उपकरणों के बीच कार्यान्वयन में अंतर हो सकता है। उदाहरण के लिए, कोड बंडलर Node.js बाधाओं को अनदेखा कर सकते हैं। ये अंतर कभी-कभी कॉन्फ़िगरेशन को जटिल बना सकते हैं, खासकर टाइपस्क्रिप्ट सेट करते समय।

तो, क्या पथ उपनामों को कॉन्फ़िगर करने के लिए imports फ़ील्ड का उपयोग करना उचित है? मेरा मानना है कि नई परियोजनाओं के लिए, हाँ, यह विधि तृतीय-पक्ष पुस्तकालयों के बजाय उपयोग करने योग्य है।

आने वाले वर्षों में imports क्षेत्र में कई डेवलपर्स के लिए पथ उपनामों को कॉन्फ़िगर करने का एक मानक तरीका बनने का एक अच्छा मौका है, क्योंकि यह पारंपरिक कॉन्फ़िगरेशन विधियों की तुलना में महत्वपूर्ण लाभ प्रदान करता है।

हालाँकि, यदि आपके पास पहले से ही कॉन्फ़िगर किए गए पथ उपनामों वाला एक प्रोजेक्ट है, तो imports फ़ील्ड पर स्विच करने से महत्वपूर्ण लाभ नहीं होंगे।

मुझे उम्मीद है कि आपको इस लेख से कुछ नया सीखने को मिला होगा। पढ़ने के लिए आपका शुक्रिया!

उपयोगी कड़ियां

1. निर्यात और आयात को लागू करने के लिए RFC
2. आयात क्षेत्र की क्षमताओं को बेहतर ढंग से समझने के लिए परीक्षणों का एक सेट
3. Node.js में आयात क्षेत्र पर प्रलेखन
4. ES मॉड्यूल में आयात पथों पर Node.js की सीमाएं

यहाँ भी प्रकाशित हुआ