নেটিভ উপায়ে ফ্রন্টেন্ড প্রকল্পগুলিতে পথ উপনামগুলি কীভাবে কনফিগার করবেন

পথ উপনাম সম্পর্কে

প্রকল্পগুলি প্রায়শই জটিল, নেস্টেড ডিরেক্টরি কাঠামোতে বিকশিত হয়। ফলস্বরূপ, আমদানির পথগুলি দীর্ঘ এবং আরও বিভ্রান্তিকর হয়ে উঠতে পারে, যা কোডের উপস্থিতিকে নেতিবাচকভাবে প্রভাবিত করতে পারে এবং আমদানি করা কোডটি কোথা থেকে এসেছে তা বোঝা আরও কঠিন করে তোলে।

পাথ উপনাম ব্যবহার করে পূর্ব-নির্ধারিত ডিরেক্টরির সাথে সম্পর্কিত আমদানির সংজ্ঞাকে অনুমতি দিয়ে সমস্যার সমাধান করতে পারে। এই পদ্ধতিটি কেবল আমদানি পথ বোঝার সমস্যাগুলি সমাধান করে না, তবে এটি রিফ্যাক্টরিংয়ের সময় কোড আন্দোলনের প্রক্রিয়াটিকেও সরল করে।

 // 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-এ পাথ উপনাম কনফিগার করার জন্য একাধিক লাইব্রেরি উপলব্ধ রয়েছে, যেমন alias-hq এবং tsconfig-paths । যাইহোক, Node.js ডকুমেন্টেশনের মাধ্যমে দেখার সময়, আমি তৃতীয় পক্ষের লাইব্রেরির উপর নির্ভর না করে পাথ উপনামগুলি কনফিগার করার একটি উপায় আবিষ্কার করেছি।

অধিকন্তু, এই পদ্ধতিটি বিল্ড ধাপের প্রয়োজন ছাড়াই উপনাম ব্যবহার করতে সক্ষম করে।

এই নিবন্ধে, আমরা Node.js Subpath Imports এবং এটি ব্যবহার করে পাথ উপনামগুলি কীভাবে কনফিগার করতে হয় তা নিয়ে আলোচনা করব। আমরা ফ্রন্টএন্ড ইকোসিস্টেমে তাদের সমর্থন অন্বেষণ করব।

আমদানি ক্ষেত্র

Node.js v12.19.0 থেকে শুরু করে, বিকাশকারীরা একটি npm প্যাকেজের মধ্যে পাথ উপনাম ঘোষণা করতে Subpath Imports ব্যবহার করতে পারে। এটি package.json ফাইলের imports ক্ষেত্রের মাধ্যমে করা যেতে পারে। প্যাকেজটি npm-এ প্রকাশ করার প্রয়োজন নেই।

যেকোনো ডিরেক্টরিতে একটি 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 বিশ্ব থেকে মডিউল রেজোলিউশনের নিয়মগুলি অনুসরণ করতে হবে। এটি ES মডিউল এবং CommonJS মডিউল উভয়ের ক্ষেত্রেই প্রযোজ্য এবং এর ফলে দুটি নতুন প্রয়োজনীয়তা পূরণ করা আবশ্যক:

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 মডিউল ব্যবহার করছেন, তাহলে আপনার কোড সমস্ত প্রয়োজনীয়তা পূরণ করে।

তদ্ব্যতীত, আপনি যদি একটি বান্ডলার ব্যবহার করে কোড তৈরি করেন তবে আপনি এই সীমাবদ্ধতাগুলিকে বাইপাস করতে পারেন। আমরা নীচে আলোচনা করব কিভাবে এটি করতে হবে।

টাইপস্ক্রিপ্টে সাবপথ আমদানির জন্য সমর্থন

টাইপ চেকিংয়ের জন্য আমদানি করা মডিউলগুলিকে সঠিকভাবে সমাধান করতে, TypeScript-কে 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 এর মতো একইভাবে কাজ করতে সক্ষম করে। এর মানে হল যে আপনি যদি একটি মডিউল আমদানিতে একটি ফাইল এক্সটেনশন অন্তর্ভুক্ত করতে ভুলে যান, TypeScript এটি সম্পর্কে আপনাকে সতর্ক করে একটি ত্রুটি তৈরি করবে৷

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

আমাদের একটি অবশিষ্ট সমস্যা আছে যা একটি আপেক্ষিক পথ ব্যবহার করে আমদানির বিষয়ে উদ্বিগ্ন। এই সমস্যাটি পাথ উপনামের সাথে সম্পর্কিত নয়। TypeScript একটি ত্রুটি নিক্ষেপ করে কারণ আমরা nodenext মোড ব্যবহার করার জন্য মডিউল রেজোলিউশন কনফিগার করেছি।

সৌভাগ্যবশত, সাম্প্রতিক TypeScript 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 কম্পাইলার ব্যবহার করে সোর্স কোড তৈরি করার সময়, অতিরিক্ত কনফিগারেশন প্রয়োজন হতে পারে। TypeScript এর একটি সীমাবদ্ধতা হল যে imports ক্ষেত্র ব্যবহার করার সময় CommonJS মডিউল বিন্যাসে একটি কোড তৈরি করা যায় না।

তাই, কোডটি অবশ্যই 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 সংস্করণে একটি গুরুত্বপূর্ণ বাগ সংশোধন করা হয়েছে, তাই অন্তত এই সংস্করণটি ব্যবহার করার পরামর্শ দেওয়া হচ্ছে। ভিটে, পাথ উপনামগুলি dev এবং build উভয় মোডে অতিরিক্ত কনফিগারেশনের প্রয়োজন ছাড়াই কাজ করে।

অতএব, আমি সম্পূর্ণ খালি কনফিগারেশন সহ একটি পরীক্ষা প্রকল্প তৈরি করেছি।

রোলআপ

যদিও Rollup 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 দিয়ে পাথ উপনাম পরীক্ষা করেছি। উভয় ক্ষেত্রেই, পাথ উপনামগুলি কোনও অতিরিক্ত সেটআপ বা সীমাবদ্ধতা ছাড়াই নির্বিঘ্নে কাজ করেছে। Jest সংস্করণ v29.4.0 থেকে imports ক্ষেত্রের জন্য সমর্থন আছে ।

Vitest-এ সমর্থনের স্তরটি শুধুমাত্র Vite-এর সংস্করণের উপর নির্ভর করে, যা কমপক্ষে v4.2.0 হতে হবে।

কোড এডিটরগুলিতে সাবপথ আমদানির জন্য সমর্থন

জনপ্রিয় লাইব্রেরিতে imports ক্ষেত্রটি বর্তমানে ভালোভাবে সমর্থিত। যাইহোক, কোড সম্পাদকদের সম্পর্কে কি? আমি কোড নেভিগেশন পরীক্ষা করেছি, বিশেষ করে "গো টু ডেফিনিশন" ফাংশন, একটি প্রকল্পে যা পাথ উপনাম ব্যবহার করে। দেখা যাচ্ছে যে কোড এডিটরগুলিতে এই বৈশিষ্ট্যটির সমর্থনে কিছু সমস্যা রয়েছে।

ভিএস কোড

যখন এটি VS কোড আসে, TypeScript এর সংস্করণটি অত্যন্ত গুরুত্বপূর্ণ। টাইপস্ক্রিপ্ট ল্যাঙ্গুয়েজ সার্ভার জাভাস্ক্রিপ্ট এবং টাইপস্ক্রিপ্ট কোডের মাধ্যমে বিশ্লেষণ এবং নেভিগেট করার জন্য দায়ী।

আপনার সেটিংসের উপর নির্ভর করে, VS কোডটি টাইপস্ক্রিপ্টের অন্তর্নির্মিত সংস্করণ বা আপনার প্রকল্পে ইনস্টল করা সংস্করণ ব্যবহার করবে।

আমি TypeScript v5.0.4 এর সংমিশ্রণে VS কোড v1.77.3-এ imports ক্ষেত্রের সমর্থন পরীক্ষা করেছি।

ভিএস কোডের পাথ উপনামের সাথে নিম্নলিখিত সমস্যা রয়েছে:

1. মডিউল রেজোলিউশন সেটিং nodenext বা bundler সেট না হওয়া পর্যন্ত TypeScript imports ক্ষেত্র ব্যবহার করে না। অতএব, ভিএস কোডে এটি ব্যবহার করতে, আপনাকে আপনার প্রকল্পে মডিউল রেজোলিউশন নির্দিষ্ট করতে হবে।

   
   

2. IntelliSense বর্তমানে imports ফিল্ড ব্যবহার করে ইম্পোর্ট পাথ সাজেস্ট করা সমর্থন করে না। এই সমস্যার জন্য একটি খোলা সমস্যা আছে।

উভয় সমস্যা বাইপাস করতে, আপনি tsconfig.json ফাইলে একটি পাথ ওরফে কনফিগারেশন প্রতিলিপি করতে পারেন। আপনি যদি TypeScript ব্যবহার না করেন, আপনি jsconfig.json এ একই কাজ করতে পারেন।

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

ওয়েবস্টর্ম

সংস্করণ 2021.3 থেকে (আমি 2022.3.4 এ পরীক্ষা করেছি), WebStorm imports ক্ষেত্র সমর্থন করে । এই বৈশিষ্ট্যটি TypeScript সংস্করণ থেকে স্বাধীনভাবে কাজ করে, কারণ WebStorm তার নিজস্ব কোড বিশ্লেষক ব্যবহার করে। যাইহোক, ওয়েবস্টর্মের সমর্থনকারী পাথ উপনাম সম্পর্কিত সমস্যাগুলির একটি পৃথক সেট রয়েছে:

1. সম্পাদক কঠোরভাবে পাথ উপনাম ব্যবহারের উপর Node.js দ্বারা আরোপিত বিধিনিষেধ অনুসরণ করে। ফাইল এক্সটেনশন স্পষ্টভাবে নির্দিষ্ট না হলে কোড নেভিগেশন কাজ করবে না। একই একটি index.js ফাইলের সাথে ডিরেক্টরি আমদানি করার ক্ষেত্রে প্রযোজ্য।

   
   

2. WebStorm-এ একটি বাগ রয়েছে যা 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. একটি package.json ফাইলে ESM প্যাকেজ বিন্যাস সক্ষম করা আবশ্যক কারণ imports ক্ষেত্র ব্যবহার করার সময় TypeScript শুধুমাত্র 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/*" } } }

একটি বান্ডলার ব্যবহার করে বিল্ডিং কোড

এই কনফিগারেশনটি সেই প্রকল্পগুলির জন্য উদ্দিষ্ট যেখানে সোর্স কোড বান্ডিল করা হয়। এই ক্ষেত্রে TypeScript এর প্রয়োজন নেই। এটি উপস্থিত না থাকলে, সমস্ত সেটিংস একটি 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 ফিল্ড ব্যবহার করে আমদানির পথে নতুন সীমাবদ্ধতা যুক্ত হয়। এই সীমাবদ্ধতাগুলি ES মডিউলগুলির মতোই, তবে তারা imports ক্ষেত্রের ব্যবহার শুরু করা আরও কঠিন করে তুলতে পারে।

• Node.js সীমাবদ্ধতার ফলে Node.js এবং অন্যান্য ডেভেলপমেন্ট টুলের মধ্যে বাস্তবায়নে পার্থক্য হতে পারে। উদাহরণস্বরূপ, কোড বান্ডলাররা Node.js সীমাবদ্ধতা উপেক্ষা করতে পারে। এই পার্থক্যগুলি কখনও কখনও কনফিগারেশনকে জটিল করে তুলতে পারে, বিশেষ করে টাইপস্ক্রিপ্ট সেট আপ করার সময়।

সুতরাং, পাথ উপনামগুলি কনফিগার করতে imports ক্ষেত্রটি ব্যবহার করা কি মূল্যবান? আমি বিশ্বাস করি যে নতুন প্রকল্পগুলির জন্য, হ্যাঁ, এই পদ্ধতিটি তৃতীয় পক্ষের লাইব্রেরির পরিবর্তে ব্যবহার করার মতো।

imports ক্ষেত্রের আগামী বছরগুলিতে অনেক ডেভেলপারের জন্য পাথ উপনাম কনফিগার করার একটি আদর্শ উপায় হয়ে ওঠার একটি ভাল সুযোগ রয়েছে, কারণ এটি ঐতিহ্যগত কনফিগারেশন পদ্ধতির তুলনায় উল্লেখযোগ্য সুবিধা প্রদান করে।

যাইহোক, আপনার যদি ইতিমধ্যেই কনফিগার করা পাথ উপনাম সহ একটি প্রকল্প থাকে, তাহলে imports ক্ষেত্রে স্যুইচ করা উল্লেখযোগ্য সুবিধা আনবে না।

আমি আশা করি আপনি এই নিবন্ধ থেকে নতুন কিছু শিখেছি. পড়ার জন্য আপনাকে ধন্যবাদ!

উপকারী সংজুক

1. রপ্তানি ও আমদানি বাস্তবায়নের জন্য RFC
2. আমদানি ক্ষেত্রের ক্ষমতা আরও ভালভাবে বোঝার জন্য পরীক্ষার একটি সেট
3. Node.js-এ আমদানি ক্ষেত্রের ডকুমেন্টেশন
4. ES মডিউলগুলিতে আমদানি পাথগুলিতে Node.js সীমাবদ্ধতা৷

এছাড়াও এখানে প্রকাশিত