ESLint x OXLint प्लगइन

eslint-plugin-intlayer उन i18n गलतियों को पकड़ता है जिन्हें TypeScript नहीं पकड़ सकता:

1. हार्डकोडेड टेक्स्ट जो कभी डिक्शनरी में नहीं गया।
2. डायनामिक कॉल्स जो टाइप-चेक पास करते हैं और रन होते हैं, लेकिन Intlayer कंपाइलर उन्हें ऑप्टिमाइज़ नहीं कर सकता।
3. अप्रयुक्त सामग्री (Dead content) — डिक्शनरी और फ़ील्ड्स जिन्हें प्रोजेक्ट में कहीं भी नहीं पढ़ा जाता (वैकल्पिक/ऑप्ट-इन)।

अज्ञात डिक्शनरी कीज, अज्ञात फ़ील्ड पाथ और अनुपलब्ध लोकेल्स पहले से ही कंपाइल एरर हैं, इसलिए प्लगइन उन्हें दोबारा रिपोर्ट नहीं करता है।

इंस्टॉलेशन

npm install --save-dev eslint-plugin-intlayer

ESLint 9 या बाद के संस्करण (flat config) की आवश्यकता है। ESLint 10 समर्थित है।

उपयोग

यह प्लगइन ESLint और oxlint दोनों में समान नियमों और विकल्पों के साथ चलता है।

{"jsPlugins": ["eslint-plugin-intlayer"],"rules": {  "intlayer/no-raw-text": "warn",  "intlayer/static-dictionary-key": "error",  "intlayer/no-dynamic-field-access": "error",  "intlayer/enforce-adapter-import": "warn"}}

कॉन्फ़िग्स

recommended जानबूझकर no-raw-text को warn पर रखता है: इसे किसी मौजूदा कोडबेस पर लागू करने से सभी अनुवादित न किए गए स्ट्रिंग्स एक साथ सामने आ जाते हैं, जिससे पहले दिन ही आपका बिल्ड टूटना नहीं चाहिए।

enforce-adapter-import डिफ़ॉल्ट रूप से बंद है — यदि आप चाहें तो इसे स्पष्ट रूप से सक्षम करें।

no-unused-content हर कॉन्फ़िग में बंद है, जिसमें strict भी शामिल है। यह एकमात्र ऐसा नियम है जो आपके Intlayer कॉन्फ़िगरेशन को पढ़ता है और डिस्क से आपकी सोर्स फ़ाइलों को स्कैन करता है, इसलिए इसे चालू करना एक विचारशील निर्णय होना चाहिए।

नियम

no-raw-text

उपयोगकर्ता-उन्मुख ऐसे टेक्स्ट की रिपोर्ट करता है जो डिक्शनरी में घोषित नहीं है। यह intlayer extract के समान डिटेक्शन का उपयोग करता है, इसलिए ब्रांड नाम, CSS क्लास और तकनीकी पहचानकर्ताओं को अनदेखा कर दिया जाता है।

// ✗ रिपोर्ट किया गया<h1>Welcome to our documentation</h1><input placeholder="Enter your email address" />// ✓ सहीconst { title } = useIntlayer("home");<h1>{title}</h1>

सामग्री घोषणा फ़ाइलें (*.content.ts, …) छोड़ दी जाती हैं।

एक बार में पूरी फ़ाइल को ठीक करने के लिए, npx intlayer extract चलाएं और कंपाइलर को स्ट्रिंग्स को डिक्शनरी में स्थानांतरित करने दें।

विकल्प

static-dictionary-key

आवश्यकता है कि डिक्शनरी कुंजी एक स्ट्रिंग लिटरल होनी चाहिए।

कंपाइलर केवल तभी डिक्शनरी को प्री-लोड कर सकता है जब वह कॉल साइट पर सीधे कुंजी पढ़ सके। एक गणना की गई कुंजी के साथ यह चुपचाप अनुकूलन को छोड़ देता है और इसके बजाय हर डिक्शनरी को बंडल कर देता है।

// ✗ रिपोर्ट किया गयाuseIntlayer(dictionaryKey);useIntlayer(`home-${suffix}`);getTranslations({ namespace: page });// ✗ वेरिएबल अभी भी लिटरल नहीं हैconst key = "home";useIntlayer(key);// ✓ सहीuseIntlayer("home");getTranslations({ namespace: "home" });

यह useIntlayer, getIntlayer और प्रत्येक संगतता एडॉप्टर (useTranslation, useTranslations, formatMessage, <FormattedMessage id>, <Trans i18nKey>, …) पर लागू होता है।

no-dynamic-field-access

आवश्यकता है कि डिक्शनरी से आप जो फ़ील्ड पढ़ते हैं वह स्थैतिक रूप से ज्ञात हो।

कंपाइलर उन फ़ील्ड्स को हटा देता है जिनका उपयोग वह नहीं देखता है। एक कंप्यूटेड एक्सेस इसके लिए अदृश्य होता है, इसलिए रनटाइम पर यह undefined लौटा सकता है।

// ✗ रिपोर्ट किया गयाconst content = useIntlayer("home");content[fieldName];const t = useTranslations("home");t(messageKey);// ✓ सहीcontent.title;content["title"];content.items[0];t("hero.title");

enforce-adapter-import

मूल पैकेज के बजाय @intlayer/* संगतता एडॉप्टर को प्राथमिकता देता है। मूल पैकेज केवल तभी Intlayer पर रीज़ॉल्व होता है जब बंडलर उपनाम कॉन्फ़िगर किया गया हो; एडॉप्टर हमेशा करता है। --fix के साथ ऑटोफ़िक्सेबल।

// ✗ रिपोर्ट किया गयाimport { useTranslation } from "react-i18next";import { getTranslations } from "next-intl/server";// ✓ सहीimport { useTranslation } from "@intlayer/react-i18next";import { getTranslations } from "@intlayer/next-intl/server";

no-unused-content

डिफ़ॉल्ट रूप से बंद। ऐसी सामग्री की रिपोर्ट करता है जिसे आपके प्रोजेक्ट में कुछ भी नहीं पढ़ता है, साथ ही एक से अधिक स्थानों पर घोषित डिक्शनरी कीज की रिपोर्ट करता है।

export default {  key: "home", // ✗ तब रिपोर्ट किया जाता है जब प्रोजेक्ट में कोई कॉलर "home" का अनुरोध नहीं करता है  content: {    title: t({ hi: "शीर्षक", en: "Title" }),    // ✗ तब रिपोर्ट किया जाता है जब कुछ भी `hero` को नहीं पढ़ता है    hero: {      subtitle: t({ hi: "उपशीर्षक", en: "Subtitle" }),    },  },};

अन्य नियमों के विपरीत, यह नियम केवल सामने की फ़ाइल से निर्णय नहीं ले सकता — एक फ़ील्ड केवल पूरे प्रोजेक्ट के सापेक्ष ही अप्रयुक्त होती है। लिंट रन की पहली सामग्री घोषणा पर यह आपके Intlayer कॉन्फ़िगरेशन को लोड करता है, उन सोर्स फ़ाइलों को स्कैन करता है जिन्हें वह कॉन्फ़िगरेशन घोषित करता है (build.traversePattern, compiler.transformPattern) और उसी उपयोग विश्लेषक को चलाता है जो @intlayer/lsp और VS Code एक्सटेंशन में "अप्रयुक्त" स्ट्राइकथ्रू को शक्ति प्रदान करता है। परिणाम को cacheTtl मिलीसेकंड के लिए कैश किया जाता है, इसलिए स्कैन प्रत्येक फ़ाइल के बजाय प्रति रन एक बार होता है।

विकल्प

जब आप लंबे समय तक चलने वाले एडिटर सर्वर से लिंट करते हैं और चाहते हैं कि आपके संपादन जल्दी दिखाई दें, तो cacheTtl कम करें; जब एक ही लिंट रन मोनोरेपो में कई Intlayer प्रोजेक्ट्स में फैला हो तो baseDir सेट करें।

यह गलत रिपोर्ट से बचने को प्राथमिकता देता है। यहां एक झूठी सकारात्मक रिपोर्ट एक अनुवाद को हटा सकती है, इसलिए जब डिक्शनरी का उपयोग ऐसे तरीके से किया जाता है जिसे विश्लेषण ट्रैक नहीं कर सकता है, तो कुछ भी रिपोर्ट नहीं किया जाता है: पूरा कंटेंट ऑब्जेक्ट पास करना, इससे बाउंड अनुवाद फ़ंक्शन (const t = useTranslations("home")), सीधे आयात के माध्यम से पहुंचा गया डिक्लेरेशन (useDictionary(myDictionary)), किसी अन्य डिक्शनरी से nest(), या स्प्रेड ऑपरेटर द्वारा गैर-विस्तृत बनाई गई फ़ील्ड सूची। सिंगल-फ़ाइल घटक (.vue, .svelte, .astro) उनके द्वारा उल्लिखित डिक्शनरी के प्रत्येक फ़ील्ड का उपयोग करते हुए गिने जाते हैं, क्योंकि उनके स्क्रिप्ट ब्लॉक यहां पार्स नहीं किए जाते हैं।

reportDuplicateKeys उन अनमर्ज्ड डिक्शनरीज़ को पढ़ता है जिन्हें बिल्ड .intlayer/ के तहत लिखता है, इसलिए यह तब तक शांत रहता है जब तक कि प्रोजेक्ट कम से कम एक बार बिल्ड न हो जाए। एक कुंजी साझा करने वाले दो डिक्लेरेशन मर्ज किए जाते हैं, जो एक वैध पैटर्न है — रिपोर्ट इसलिए मौजूद है क्योंकि दोनों पक्षों पर परिभाषित फ़ील्ड चुपचाप दो मानों में से केवल एक को रखता है।

विश्लेषक @intlayer/lsp से लोड होता है, जो ESM के रूप में वितरित होता है। इसलिए नियम को एक ऐसे Node संस्करण की आवश्यकता होती है जो ES मॉड्यूल को require() कर सके — Node 20.19+ या 22.12+। इससे पुराने किसी भी संस्करण पर यह लिंट रन को विफल करने के बजाय कुछ भी रिपोर्ट नहीं करता है।

फ्रेमवर्क

प्रत्येक नियम सभी Intlayer एकीकरणों में काम करता है, जिसमें Vue, Svelte और Angular टेम्प्लेट्स शामिल हैं। आपको केवल ESLint को यह बताना होगा कि प्रत्येक फ़ाइल प्रकार को कौन सा पार्सर पढ़ता है।

केवल वही पार्सर स्थापित करें जिनकी आपके प्रोजेक्ट को आवश्यकता है।

ज्ञात सीमा। Vue और Angular टेम्प्लेट्स में, {{ content[key] }} जैसा एक्सप्रेशन no-dynamic-field-access द्वारा जाँचा नहीं जाता है। स्क्रिप्ट ब्लॉक में लिखे गए डायनामिक रीड सामान्य रूप से पकड़े जाते हैं।