টাইপস্ক্রিপ্ট তৈরি করা হচ্ছে সত্যিকার অর্থে "স্ট্রংলি টাইপ করা"

টাইপস্ক্রিপ্ট জাভাস্ক্রিপ্টের উপরে নির্মিত একটি শক্তিশালী টাইপ করা প্রোগ্রামিং ভাষা বলে দাবি করে, যে কোনও স্কেলে আরও ভাল টুলিং প্রদান করে। যাইহোক, TypeScript any প্রকারকে অন্তর্ভুক্ত করে, যা প্রায়শই একটি কোডবেসের মধ্যে গোপনে প্রবেশ করতে পারে এবং টাইপস্ক্রিপ্টের অনেক সুবিধা হারাতে পারে।

এই নিবন্ধটি TypeScript প্রজেক্টের any ধরনের নিয়ন্ত্রণ করার উপায়গুলি অন্বেষণ করে। টাইপস্ক্রিপ্টের শক্তি উন্মোচন করার জন্য প্রস্তুত হোন, চূড়ান্ত ধরনের নিরাপত্তা অর্জন এবং কোডের গুণমান উন্নত করুন।

টাইপস্ক্রিপ্টে যেকোনো ব্যবহার করার অসুবিধা

টাইপস্ক্রিপ্ট বিকাশকারীর অভিজ্ঞতা এবং উত্পাদনশীলতা বাড়াতে অতিরিক্ত টুলিংয়ের একটি পরিসর সরবরাহ করে:

• এটি বিকাশের পর্যায়ে প্রাথমিকভাবে ত্রুটিগুলি ধরতে সহায়তা করে।
• এটি কোড এডিটর এবং IDE-এর জন্য চমৎকার স্বয়ংক্রিয়-সম্পূর্ণতা প্রদান করে।
• এটি চমত্কার কোড নেভিগেশন সরঞ্জাম এবং স্বয়ংক্রিয় রিফ্যাক্টরিংয়ের মাধ্যমে বড় কোডবেসগুলির সহজে রিফ্যাক্টরিংয়ের অনুমতি দেয়।
• এটি প্রকারের মাধ্যমে অতিরিক্ত শব্দার্থবিদ্যা এবং সুস্পষ্ট ডেটা স্ট্রাকচার প্রদান করে একটি কোডবেস বোঝা সহজ করে।

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

উদাহরণস্বরূপ, নিম্নলিখিত উদাহরণ বিবেচনা করুন:

 function parse(data: any) { return data.split(''); } // Case 1 const res1 = parse(42); // ^ TypeError: data.split is not a function // Case 2 const res2 = parse('hello'); // ^ any

উপরের কোডে:

• parse ফাংশনের ভিতরে আপনি স্বয়ংক্রিয়-সম্পূর্ণতা মিস করবেন। আপনি যখন data. আপনার সম্পাদকে, data জন্য উপলব্ধ পদ্ধতিগুলির জন্য আপনাকে সঠিক পরামর্শ দেওয়া হবে না।
• প্রথম ক্ষেত্রে, একটি TypeError: data.split is not a function কারণ আমরা একটি স্ট্রিংয়ের পরিবর্তে একটি সংখ্যা পাস করেছি। TypeScript ত্রুটিটি হাইলাইট করতে সক্ষম নয় কারণ any প্রকার পরীক্ষা অক্ষম করে।
• দ্বিতীয় ক্ষেত্রে, res2 ভেরিয়েবলের any প্রকার আছে। এর মানে হল যে any একটি একক ব্যবহার কোডবেসের একটি বড় অংশে ক্যাসকেডিং প্রভাব ফেলতে পারে।

শুধুমাত্র চরম ক্ষেত্রে বা প্রোটোটাইপিং প্রয়োজনের জন্য any ব্যবহার করা ঠিক। সাধারণভাবে, TypeScript থেকে সর্বাধিক সুবিধা পেতে any ব্যবহার এড়িয়ে চলাই ভালো।

যেখান থেকে যে কোন প্রকার আসে

কোডবেসের any প্রকারের উত্স সম্পর্কে সচেতন হওয়া গুরুত্বপূর্ণ কারণ স্পষ্টভাবে any লেখাই একমাত্র বিকল্প নয়। any ধরনের ব্যবহার এড়ানোর জন্য আমাদের সর্বোত্তম প্রচেষ্টা সত্ত্বেও, এটি কখনও কখনও একটি কোডবেসে লুকিয়ে থাকতে পারে।

একটি কোডবেসে any ধরনের চারটি প্রধান উৎস রয়েছে:

1. tsconfig এ কম্পাইলার অপশন।
2. TypeScript এর স্ট্যান্ডার্ড লাইব্রেরি।
3. প্রকল্প নির্ভরতা।
4. একটি কোডবেসে যে any সুস্পষ্ট ব্যবহার।

আমি ইতিমধ্যেই প্রথম দুটি পয়েন্টের জন্য tsconfig-এ কী বিবেচনা এবং স্ট্যান্ডার্ড লাইব্রেরি প্রকারের উন্নতির উপর নিবন্ধ লিখেছি। আপনি আপনার প্রকল্পে টাইপ নিরাপত্তা উন্নত করতে চান তাহলে অনুগ্রহ করে তাদের পরীক্ষা করে দেখুন.

এই সময়, আমরা একটি কোডবেসে any ধরণের চেহারা নিয়ন্ত্রণের জন্য স্বয়ংক্রিয় সরঞ্জামগুলিতে ফোকাস করব।

পর্যায় 1: ESLint ব্যবহার করা

ESLint হল একটি জনপ্রিয় স্ট্যাটিক বিশ্লেষণ টুল যা ওয়েব ডেভেলপারদের দ্বারা সর্বোত্তম অনুশীলন এবং কোড বিন্যাস নিশ্চিত করতে ব্যবহৃত হয়। এটি কোডিং শৈলী প্রয়োগ করতে এবং নির্দিষ্ট নির্দেশিকা মেনে চলে না এমন কোড খুঁজে পেতে ব্যবহার করা যেতে পারে।

ESLint TypeScript প্রজেক্টের সাথেও ব্যবহার করা যেতে পারে, Typescript-eslint প্লাগইনকে ধন্যবাদ। সম্ভবত, এই প্লাগইনটি ইতিমধ্যে আপনার প্রকল্পে ইনস্টল করা হয়েছে। কিন্তু যদি না হয়, আপনি অফিসিয়াল শুরু করার নির্দেশিকা অনুসরণ করতে পারেন।

typescript-eslint জন্য সবচেয়ে সাধারণ কনফিগারেশন নিম্নরূপ:

 module.exports = { extends: [ 'eslint:recommended', 'plugin:@typescript-eslint/recommended', ], plugins: ['@typescript-eslint'], parser: '@typescript-eslint/parser', root: true, };

এই কনফিগারেশনটি eslint সিনট্যাক্স স্তরে টাইপস্ক্রিপ্ট বুঝতে সক্ষম করে, আপনাকে সহজ এস্লিন্ট নিয়ম লিখতে দেয় যা একটি কোডে ম্যানুয়ালি লিখিত প্রকারের ক্ষেত্রে প্রযোজ্য। উদাহরণস্বরূপ, আপনি any এর সুস্পষ্ট ব্যবহার নিষিদ্ধ করতে পারেন।

recommended প্রিসেটটিতে কোডের সঠিকতা উন্নত করার লক্ষ্যে ESLint নিয়মগুলির একটি সাবধানে নির্বাচিত সেট রয়েছে। যদিও পুরো প্রিসেটটি ব্যবহার করার পরামর্শ দেওয়া হয়েছে, এই নিবন্ধটির উদ্দেশ্যে, আমরা শুধুমাত্র no-explicit-any নিয়মের উপর ফোকাস করব।

no-explicit-any

TypeScript এর কঠোর মোড উহ্য any ব্যবহারকে বাধা দেয়, কিন্তু এটি any স্পষ্টভাবে ব্যবহার করা থেকে বাধা দেয় না। no-explicit-any নিয়ম কোডবেসের any জায়গায় ম্যানুয়ালি লেখা নিষিদ্ধ করতে সাহায্য করে।

 // ❌ Incorrect function loadPokemons(): any {} // ✅ Correct function loadPokemons(): unknown {} // ❌ Incorrect function parsePokemons(data: Response<any>): Array<Pokemon> {} // ✅ Correct function parsePokemons(data: Response<unknown>): Array<Pokemon> {} // ❌ Incorrect function reverse<T extends Array<any>>(array: T): T {} // ✅ Correct function reverse<T extends Array<unknown>>(array: T): T {}

এই নিয়মের প্রাথমিক উদ্দেশ্য হল পুরো দল জুড়ে any ব্যবহার রোধ করা। এটি দলের চুক্তিকে শক্তিশালী করার একটি মাধ্যম যে প্রকল্পে any ব্যবহার নিরুৎসাহিত করা হয়।

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

কেন নো-স্পষ্ট-কোনও যথেষ্ট নয়

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

নিম্নলিখিত কোডটি বিবেচনা করুন, যা কোনও প্রকল্পে দেখা যেতে পারে:

 const response = await fetch('https://pokeapi.co/api/v2/pokemon'); const pokemons = await response.json(); // ^? any const settings = JSON.parse(localStorage.getItem('user-settings')); // ^? any

উভয় ভেরিয়েবল pokemons এবং settings পরোক্ষভাবে any ধরনের দেওয়া হয়েছিল। এই ক্ষেত্রে no-explicit-any বা টাইপস্ক্রিপ্টের কঠোর মোড আমাদের সতর্ক করবে না। এখনো না.

এটি ঘটে কারণ response.json() এবং JSON.parse() এর প্রকারগুলি TypeScript-এর স্ট্যান্ডার্ড লাইব্রেরি থেকে এসেছে, যেখানে এই পদ্ধতিগুলির একটি স্পষ্ট any টীকা আছে। আমরা এখনও আমাদের ভেরিয়েবলের জন্য একটি ভাল টাইপ ম্যানুয়ালি নির্দিষ্ট করতে পারি, তবে স্ট্যান্ডার্ড লাইব্রেরিতে প্রায় 1,200টি any রয়েছে। স্ট্যান্ডার্ড লাইব্রেরি থেকে আমাদের কোডবেসে any লুকিয়ে থাকতে পারে এমন সমস্ত ক্ষেত্রে মনে রাখা প্রায় অসম্ভব।

একই বাহ্যিক নির্ভরতা জন্য যায়. এনপিএম-এ অনেক খারাপভাবে টাইপ করা লাইব্রেরি রয়েছে, যার বেশিরভাগ এখনও জাভাস্ক্রিপ্টে লেখা হচ্ছে। ফলস্বরূপ, এই ধরনের লাইব্রেরি ব্যবহার করে সহজেই একটি কোডবেসে any নিহিত হতে পারে।

সাধারনত, আমাদের কোডে any থাকার জন্য এখনও অনেক উপায় আছে।

পর্যায় 2: টাইপ চেকিং ক্ষমতা উন্নত করা

আদর্শভাবে, আমরা TypeScript-এ এমন একটি সেটিং রাখতে চাই যা কম্পাইলারকে যে কোনো ভেরিয়েবলের বিষয়ে অভিযোগ করে যে কোনো কারণে any প্রকার প্রাপ্ত হয়েছে। দুর্ভাগ্যবশত, এই ধরনের একটি সেটিং বর্তমানে বিদ্যমান নেই এবং যোগ করা হবে বলে আশা করা হচ্ছে না।

আমরা typescript-eslint প্লাগইনের টাইপ-চেকড মোড ব্যবহার করে এই আচরণটি অর্জন করতে পারি। এই মোডটি TypeScript-এর সাথে একত্রে কাজ করে যাতে TypeScript কম্পাইলার থেকে ESLint নিয়মে সম্পূর্ণ ধরনের তথ্য প্রদান করে। এই তথ্যের সাহায্যে, আরও জটিল ESLint নিয়ম লেখা সম্ভব যা মূলত TypeScript-এর টাইপ-চেকিং ক্ষমতা প্রসারিত করে। উদাহরণস্বরূপ, একটি নিয়ম any প্রকারের সাথে সমস্ত ভেরিয়েবল খুঁজে পেতে পারে, তা নির্বিশেষে যে any কীভাবে পাওয়া গেছে।

টাইপ-সচেতন নিয়মগুলি ব্যবহার করতে, আপনাকে ESLint কনফিগারেশন সামান্য সামঞ্জস্য করতে হবে:

 module.exports = { extends: [ 'eslint:recommended', - 'plugin:@typescript-eslint/recommended', + 'plugin:@typescript-eslint/recommended-type-checked', ], plugins: ['@typescript-eslint'], parser: '@typescript-eslint/parser', + parserOptions: { + project: true, + tsconfigRootDir: __dirname, + }, root: true, };

typescript-eslint এর জন্য টাইপ ইনফারেন্স সক্ষম করতে, ESLint কনফিগারেশনে parserOptions যোগ করুন। তারপরে, recommended প্রিসেটটিকে recommended-type-checked দিয়ে প্রতিস্থাপন করুন। পরবর্তী প্রিসেট প্রায় 17 নতুন শক্তিশালী নিয়ম যোগ করে। এই নিবন্ধটির উদ্দেশ্যে, আমরা তাদের মধ্যে মাত্র 5টিতে ফোকাস করব।

কোন-অনিরাপদ-যুক্তি

no-unsafe-argument নিয়ম ফাংশন কলগুলির জন্য অনুসন্ধান করে যেখানে any প্রকারের একটি পরিবর্তনশীল প্যারামিটার হিসাবে পাস করা হয়। যখন এটি ঘটে, টাইপ-চেকিং হারিয়ে যায়, এবং শক্তিশালী টাইপিংয়ের সমস্ত সুবিধাও হারিয়ে যায়।

উদাহরণস্বরূপ, আসুন একটি saveForm ফাংশন বিবেচনা করি যার জন্য একটি বস্তুর প্যারামিটার হিসাবে প্রয়োজন। ধরুন আমরা JSON গ্রহন করি, এটিকে পার্স করি এবং যে any প্রকার পাই।

 // ❌ Incorrect function saveForm(values: FormValues) { console.log(values); } const formValues = JSON.parse(userInput); // ^? any saveForm(formValues); // ^ Unsafe argument of type `any` assigned // to a parameter of type `FormValues`.

যখন আমরা এই প্যারামিটারের সাথে saveForm ফাংশনকে কল করি, তখন no-unsafe-argument নিয়ম এটিকে অনিরাপদ হিসাবে ফ্ল্যাগ করে এবং আমাদের value ভ্যারিয়েবলের জন্য উপযুক্ত টাইপ নির্দিষ্ট করতে চায়।

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

 // ❌ Incorrect saveForm({ name: 'John', address: JSON.parse(addressJson), // ^ Unsafe assignment of an `any` value. });

ত্রুটি ঠিক করার সর্বোত্তম উপায় হল TypeScript এর টাইপ সংকীর্ণ বা একটি বৈধকরণ লাইব্রেরি যেমন Zod বা Superstruct ব্যবহার করা। উদাহরণস্বরূপ, আসুন parseFormValues ফাংশনটি লিখি যা পার্স করা ডেটার সুনির্দিষ্ট প্রকারকে সংকুচিত করে।

 // ✅ Correct function parseFormValues(data: unknown): FormValues { if ( typeof data === 'object' && data !== null && 'name' in data && typeof data['name'] === 'string' && 'address' in data && typeof data.address === 'string' ) { const { name, address } = data; return { name, address }; } throw new Error('Failed to parse form values'); } const formValues = parseFormValues(JSON.parse(userInput)); // ^? FormValues saveForm(formValues);

মনে রাখবেন যে unknown স্বীকার করে এমন একটি ফাংশনে যুক্তি হিসাবে any প্রকারকে পাস করার অনুমতি দেওয়া হয়, কারণ এটি করার সাথে সম্পর্কিত কোনও নিরাপত্তা উদ্বেগ নেই।

ডেটা যাচাইকরণ ফাংশন লেখা একটি ক্লান্তিকর কাজ হতে পারে, বিশেষ করে যখন প্রচুর পরিমাণে ডেটা নিয়ে কাজ করা হয়। অতএব, এটি একটি ডেটা বৈধতা লাইব্রেরি ব্যবহার বিবেচনা করা মূল্যবান। উদাহরণস্বরূপ, Zod এর সাথে, কোডটি দেখতে এইরকম হবে:

 // ✅ Correct import { z } from 'zod'; const schema = z.object({ name: z.string(), address: z.string(), }); const formValues = schema.parse(JSON.parse(userInput)); // ^? { name: string, address: string } saveForm(formValues);

কোন-অনিরাপদ-অ্যাসাইনমেন্ট

no-unsafe-assignment নিয়ম পরিবর্তনশীল অ্যাসাইনমেন্টের জন্য অনুসন্ধান করে যেখানে একটি মান যে any প্রকারের আছে। এই ধরনের অ্যাসাইনমেন্ট কম্পাইলারকে এই ভেবে বিভ্রান্ত করতে পারে যে একটি ভেরিয়েবলের একটি নির্দিষ্ট টাইপ আছে, যখন ডেটা আসলে ভিন্ন ধরনের থাকতে পারে।

JSON পার্সিংয়ের আগের উদাহরণটি বিবেচনা করুন:

 // ❌ Incorrect const formValues = JSON.parse(userInput); // ^ Unsafe assignment of an `any` value

no-unsafe-assignment নিয়মের জন্য ধন্যবাদ, আমরা অন্য কোথাও formValues পাস করার আগেও any প্রকার ধরতে পারি। ফিক্সিং কৌশল একই থাকে: আমরা ভেরিয়েবলের মানকে একটি নির্দিষ্ট ধরন প্রদান করতে টাইপ সংকীর্ণ ব্যবহার করতে পারি।

 // ✅ Correct const formValues = parseFormValues(JSON.parse(userInput)); // ^? FormValues

নো-অনিরাপদ-সদস্য-অ্যাক্সেস এবং নো-অনিরাপদ-কল

এই দুটি নিয়ম অনেক কম ঘন ঘন ট্রিগার. যাইহোক, আমার অভিজ্ঞতার উপর ভিত্তি করে, আপনি যখন খারাপভাবে টাইপ করা তৃতীয় পক্ষের নির্ভরতা ব্যবহার করার চেষ্টা করছেন তখন তারা সত্যিই সহায়ক।

no-unsafe-member-access নিয়ম আমাদের অবজেক্টের বৈশিষ্ট্যগুলি অ্যাক্সেস করতে বাধা দেয় যদি কোনও ভেরিয়েবলের any প্রকার থাকে, যেহেতু এটি null বা undefined হতে পারে।

no-unsafe-call নিয়ম আমাদেরকে একটি ফাংশন হিসাবে any প্রকারের সাথে একটি ভেরিয়েবলকে কল করতে বাধা দেয়, কারণ এটি একটি ফাংশন নাও হতে পারে।

আসুন কল্পনা করি যে আমাদের একটি খারাপভাবে টাইপ করা তৃতীয় পক্ষের লাইব্রেরি আছে যাকে বলা হয় untyped-auth :

 // ❌ Incorrect import { authenticate } from 'untyped-auth'; // ^? any const userInfo = authenticate(); // ^? any ^ Unsafe call of an `any` typed value. console.log(userInfo.name); // ^ Unsafe member access .name on an `any` value.

লিন্টার দুটি সমস্যা হাইলাইট করে:

• authenticate ফাংশন কল করা অনিরাপদ হতে পারে, কারণ আমরা ফাংশনে গুরুত্বপূর্ণ আর্গুমেন্ট পাস করতে ভুলে যেতে পারি।
• userInfo অবজেক্ট থেকে name সম্পত্তি পড়া অনিরাপদ, কারণ প্রমাণীকরণ ব্যর্থ হলে এটি null হবে।

এই ত্রুটিগুলি ঠিক করার সর্বোত্তম উপায় হল একটি দৃঢ়ভাবে টাইপ করা API সহ একটি লাইব্রেরি ব্যবহার করার কথা বিবেচনা করা। কিন্তু যদি এটি একটি বিকল্প না হয়, তাহলে আপনি নিজেইলাইব্রেরির প্রকারগুলিকে বাড়িয়ে তুলতে পারেন৷ স্থির লাইব্রেরি প্রকারের সাথে একটি উদাহরণ এইরকম দেখাবে:

 // ✅ Correct import { authenticate } from 'untyped-auth'; // ^? (login: string, password: string) => Promise<UserInfo | null> const userInfo = await authenticate('test', 'pwd'); // ^? UserInfo | null if (userInfo) { console.log(userInfo.name); }

কোন-অনিরাপদ-প্রত্যাবর্তন

no-unsafe-return নিয়মটি দুর্ঘটনাক্রমে একটি ফাংশন থেকে any ধরণের ফেরত না দিতে সহায়তা করে যা আরও নির্দিষ্ট কিছু ফেরত দেয়। এই ধরনের ক্ষেত্রে কম্পাইলারকে এই ভেবে বিভ্রান্ত করতে পারে যে একটি প্রত্যাবর্তিত মান একটি নির্দিষ্ট ধরনের আছে, যখন ডেটা আসলে একটি ভিন্ন ধরনের থাকতে পারে।

উদাহরণস্বরূপ, ধরুন আমাদের একটি ফাংশন আছে যা JSON পার্স করে এবং দুটি বৈশিষ্ট্য সহ একটি অবজেক্ট রিটার্ন করে।

 // ❌ Incorrect interface FormValues { name: string; address: string; } function parseForm(json: string): FormValues { return JSON.parse(json); // ^ Unsafe return of an `any` typed value. } const form = parseForm('null'); console.log(form.name); // ^ TypeError: Cannot read properties of null

parseForm ফাংশন প্রোগ্রামের যেকোনো অংশে রানটাইম ত্রুটির কারণ হতে পারে যেখানে এটি ব্যবহার করা হয়, যেহেতু পার্স করা মান চেক করা হয় না। no-unsafe-return নিয়ম এই ধরনের রানটাইম সমস্যা প্রতিরোধ করে।

পার্স করা JSON প্রত্যাশিত প্রকারের সাথে মেলে তা নিশ্চিত করার জন্য বৈধতা যোগ করে এটি ঠিক করা সহজ। এবার Zod লাইব্রেরি ব্যবহার করা যাক:

 // ✅ Correct import { z } from 'zod'; const schema = z.object({ name: z.string(), address: z.string(), }); function parseForm(json: string): FormValues { return schema.parse(JSON.parse(json)); }

কর্মক্ষমতা সম্পর্কে একটি নোট

টাইপ-চেক করা নিয়ম ব্যবহার করলে ESLint-এর জন্য পারফরম্যান্স পেনাল্টি আসে কারণ সব ধরনের অনুমান করতে টাইপস্ক্রিপ্টের কম্পাইলার ব্যবহার করতে হবে। প্রি-কমিট হুক এবং সিআই-তে লিন্টার চালানোর সময় এই মন্থরতা প্রধানত লক্ষণীয়, কিন্তু একটি IDE-তে কাজ করার সময় এটি লক্ষণীয় নয়। IDE স্টার্টআপে একবার টাইপ চেকিং করা হয় এবং তারপর আপনি কোড পরিবর্তন করার সাথে সাথে প্রকারগুলি আপডেট করে।

এটি লক্ষণীয় যে শুধু প্রকারগুলি অনুমান করা tsc কম্পাইলারের স্বাভাবিক আহ্বানের চেয়ে দ্রুত কাজ করে। উদাহরণস্বরূপ, টাইপস্ক্রিপ্ট কোডের প্রায় 1.5 মিলিয়ন লাইন সহ আমাদের সাম্প্রতিক প্রকল্পে, tsc মাধ্যমে টাইপ চেক করতে প্রায় 11 মিনিট সময় লাগে, যেখানে ESLint-এর টাইপ-সচেতন নিয়মগুলি বুটস্ট্র্যাপ করার জন্য প্রয়োজনীয় অতিরিক্ত সময় মাত্র 2 মিনিট।

আমাদের দলের জন্য, টাইপ-সচেতন স্ট্যাটিক বিশ্লেষণ নিয়ম ব্যবহার করে প্রদত্ত অতিরিক্ত নিরাপত্তা ট্রেডঅফের মূল্য। ছোট প্রকল্পগুলিতে, এই সিদ্ধান্ত নেওয়া আরও সহজ।

উপসংহার

সর্বোত্তম টাইপ নিরাপত্তা এবং কোডের গুণমান অর্জনের জন্য TypeScript প্রকল্পের any ব্যবহার নিয়ন্ত্রণ করা অত্যন্ত গুরুত্বপূর্ণ। typescript-eslint প্লাগইন ব্যবহার করে, ডেভেলপাররা তাদের কোডবেসে any ধরনের ঘটনা চিহ্নিত করতে এবং নির্মূল করতে পারে, যার ফলে আরও শক্তিশালী এবং রক্ষণাবেক্ষণযোগ্য কোডবেস তৈরি হয়।

টাইপ-সচেতন eslint নিয়মগুলি ব্যবহার করে, আমাদের কোডবেসে any কোনও কীওয়ার্ডের উপস্থিতি একটি ভুল বা তদারকির পরিবর্তে একটি ইচ্ছাকৃত সিদ্ধান্ত হবে। এই পদ্ধতিটি আমাদের নিজস্ব কোড, সেইসাথে স্ট্যান্ডার্ড লাইব্রেরি এবং তৃতীয় পক্ষের নির্ভরতাগুলিতে any ব্যবহার থেকে আমাদের রক্ষা করে।

সামগ্রিকভাবে, একটি টাইপ-সচেতন লিন্টার আমাদের স্ট্যাটিকালি টাইপ করা প্রোগ্রামিং ভাষা যেমন জাভা, গো, রাস্ট এবং অন্যান্যগুলির মতো টাইপ নিরাপত্তার একটি স্তর অর্জন করতে দেয়। এটি ব্যাপকভাবে বড় প্রকল্পগুলির উন্নয়ন এবং রক্ষণাবেক্ষণকে সহজ করে তোলে।

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

উপকারী সংজুক

• লাইব্রেরি: typescript-eslint
• প্রবন্ধ: tsconfig এ মূল বিবেচ্য বিষয়
• প্রবন্ধ: স্ট্যান্ডার্ড লাইব্রেরি প্রকারের উন্নতি
• ডক্স: টাইপস্ক্রিপ্টে সংকীর্ণ টাইপ করুন
• ডক্স: টাইপস্ক্রিপ্টে টাইপ ইনফারেন্স
• গ্রন্থাগার: জোড
• লাইব্রেরি: সুপারস্ট্রাক্ট