5 उपयोगी वेबपैक प्लगइन्स

नमस्कार, हेब्र!

वेबपैक में कई उपयोगी प्लगइन्स हैं जिनके बारे में बहुत से लोग नहीं जानते हैं और अपनी परियोजनाओं में उपयोग नहीं करते हैं। कटौती के तहत, मैंने इनमें से 5 एकत्र किए, वे आपके जीवन को सरल बना सकते हैं!

1. अप्रयुक्त फ़ाइलें वेबपैक प्लगइन

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

किसी प्रोजेक्ट में अप्रयुक्त फ़ाइलों के बारे में जानने के लिए, अपने डिस्क पर अप्रयुक्त-फाइल्स-वेबपैक-प्लगइन जोड़ें:

npm i unused-files-webpack-plugin 

 /* webpack.config.js */ const { UnusedFilesWebpackPlugin } = require('unused-files-webpack-plugin'); module.exports = { /* ... */ plugins: [ /* ... */ new UnusedFilesWebpackPlugin(), ], }; 

स्थापना के बाद, आप किसी भी अप्रयुक्त फ़ाइलों के बारे में चेतावनी प्राप्त करेंगे:

 src/ ├── index.js └── someFile.js ( ) 

 WARNING in UnusedFilesWebpackPlugin found some unused files: src/someFile.js 

संदर्भ:

→ जीथब
→ एनपीएम

2. केस संवेदनशील पथ वेबपैक प्लगइन

OSX पर विकास के दौरान, अक्सर मॉड्यूल को आयात करते समय लोअरकेस और अपरकेस अक्षरों को एक पथ में भ्रमित करना संभव होता है। असेंबली एक खसखस ​​पर इकट्ठा होगी, लेकिन अन्य केस-संवेदी प्रणालियों पर यह गिर जाएगी।

यदि आप इस समस्या से छुटकारा पाना चाहते हैं, तो आपको केस-सेंसिटिव-पाथ-वेबपैक-प्लगइन डालने की आवश्यकता है:

 npm i case-sensitive-paths-webpack-plugin 

 /* webpack.config.js */ const CaseSensitivePathsPlugin = require('case-sensitive-paths-webpack-plugin'); module.exports = { /* ... */ plugins: [ /* ... */ new CaseSensitivePathsPlugin(), ], }; 

अब गलत मामले के साथ एक मॉड्यूल आयात करते समय, आपको हमेशा एक त्रुटि मिलेगी:

 /* index.js */ import someFile from './SOMEFILE'; 

 /* someFile.js */ export default () => { console.log('Hello!'); }; 

 ERROR in index.js Module not found: Error: [CaseSensitivePathsPlugin] `SOMEFILE.js` does not match the corresponding path on disk `someFile.js`. 

इस समस्या को इंपोर्ट / नो-अनसुलझे एस्लिंट प्लगइन का उपयोग करके भी हल किया जा सकता है।

टाइपस्क्रिप्ट में काम के लिए एक समान विकल्प है - ForceConsistentCasingInFileNames। लेकिन वह थोड़ी अलग तरह से व्यवहार करती है: वह जाँचती है कि विभिन्न स्थानों से मॉड्यूल आयात करने की स्थिति में भिन्न नहीं है, रजिस्टर की बहुत शुद्धता की जाँच नहीं की जाती है।

संदर्भ:

→ जीथब
→ एनपीएम

3. निरीक्षण

आपकी परियोजना में, एक स्थिति उत्पन्न हो सकती है कि आप और आपके पैकेज एक ही पुस्तकालय के विभिन्न संस्करणों का उपयोग करते हैं। फिर पैकेज के कई बंडल बंडल में दिखाई देंगे, जिन्हें समान संस्करणों को निर्दिष्ट करके आसानी से तय किया जा सकता है।

इंस्पेक्टपैक आपको इस स्थिति को तुरंत खोजने में मदद करेगा:

 npm i inspectpack 

 /* webpack.config.js */ const { DuplicatesPlugin } = require('inspectpack/plugin'); module.exports = { /* ... */ plugins: [ /* ... */ new DuplicatesPlugin(), ], }; 

यदि आप प्लगइन स्थापित करते हैं, तो पैकेज की प्रतियां दिखाई देने पर एक चेतावनी पॉप अप होगी:

 /* package.json */ { /* ... */ "name": "my-app", "dependencies": { "lodash": "4.1.0", "one": "1.2.3" } } 

 /* node_modules/one/package.json */ { /* ... */ "name": "one", "dependencies": { "lodash": "3.0.0" } } 

 /* index.js */ import _ from 'lodash'; import 'one'; /* ... */ 

 WARNING in Duplicate Sources / Packages - Duplicates found! ️ * Duplicates: Found 2 similar files across 2 code sources (both identical + similar) accounting for 703 bundled bytes. * Packages: Found 1 packages with 2 resolved, 2 installed, and 2 depended versions. ## bundle.js lodash (Found 2 resolved, 2 installed, 2 depended. Latest 4.1.0.) 3.0.0 ~/one/~/lodash scenario-new-webpack-new-npm-unflattened@* -> one@1.2.3 -> lodash@3.0.0 4.1.0 ~/lodash scenario-new-webpack-new-npm-unflattened@* -> lodash@4.1.0 

इसी तरह की कार्यक्षमता डुप्लिकेट-पैकेज-चेकर-वेबपैक-प्लगइन द्वारा प्रदान की जाती है। लेकिन इसके साथ एक समस्या है - यह पुस्तकालय के एक संस्करण के कई घटनाओं को नहीं दिखाता है , अर्थात्। स्पॉइलर के तहत उदाहरण में समस्या, जहां tslib के कई समान संस्करण हैं, वह नहीं मिल सकता है।

संदर्भ:

→ जीथब
→ एनपीएम

4. परिपत्र निर्भरता प्लगइन

विकास के दौरान, कभी-कभी निर्भरता को हल करने में समस्याएं होती हैं - दो मॉड्यूल एक दूसरे को आयात करते हैं और एक परिपत्र निर्भरता प्राप्त की जाती है। यह अन्य मॉड्यूल की एक श्रृंखला के माध्यम से, स्पष्ट रूप से हो सकता है। दुर्लभ मामलों में, चक्रीय निर्भरताएं सामान्य हैं, लेकिन सबसे अधिक संभावना है कि यह इंगित करता है कि परियोजना की वास्तुकला में कोई समस्या है।

परिपत्र निर्भरता को तुरंत देखने और इसे हटाने के लिए, परिपत्र-निर्भरता-प्लगइन जोड़ें:

 npm i circular-dependency-plugin 

 /* webpack.config.js */ const CircularDependencyPlugin = require('circular-dependency-plugin'); module.exports = { /* ... */ plugins: [ /* ... */ new CircularDependencyPlugin(), ], }; 

अब, जब एक परिपत्र निर्भरता प्रकट होती है, तो आपको एक चेतावनी मिलेगी:

 /* first.js */ import second from './second' /* ... */ 

 /* second.js */ import first from './first' /* ... */ 

 WARNING in Circular dependency detected: first.js -> second.js -> first.js WARNING in Circular dependency detected: second.js -> first.js -> second.js 

एस्लिंट और tslint के लिए आयात / नो-साइकल नियम- tslint के लिए नो-सर्कुलर-इंपोर्ट एक समान समस्या का समाधान करते हैं। उत्तरार्द्ध, हालांकि, केवल टाइपिंग के लिए उपयोग किए जाने वाले प्रकारों, इंटरफेस और वर्गों के आयात को अनदेखा करने की क्षमता नहीं है - आपको अक्सर tslint लिखना होगा: अक्षम।

संदर्भ:

→ जीथब
→ एनपीएम

5. स्पीड माप वेबपैक प्लगइन

कई सौ फाइलों से मिलकर बड़ी परियोजनाओं में, विधानसभा में कई मिनट लग सकते हैं।

स्पीड-माप-वेबपैक-प्लगइन हर बिल्ड कदम को मापने और समस्याओं को खोजने में मदद करेगा:

 npm i speed-measure-webpack-plugin 

 /* webpack.config.js */ const SpeedMeasurePlugin = require("speed-measure-webpack-plugin"); const smp = new SpeedMeasurePlugin(); module.exports = smp.wrap({ /* ... */ }); 

बिल्ड आउटपुट कुल बिल्ड समय, प्रत्येक प्लगइन के निष्पादन समय और लोडर की प्रत्येक श्रृंखला के बारे में जानकारी जोड़ देगा:

  SMP General output time took 48.97 secs SMP - Plugins TerserPlugin took 19.6 secs OptimizeCssAssetsWebpackPlugin took 2.65 secs MiniCssExtractPlugin took 0.261 secs VueLoaderPlugin took 0.216 secs /* ... */ SMP - Loaders mini-css-extract-plugin, and css-loader, and postcss-loader took 21.81 secs module count = 33 cache-loader, and babel-loader, and ts-loader, and tslint-loader took 21.63 secs module count = 240 /* ... */ 

उन्होंने मुझे TerserPlugin की न्यूनतम गति के साथ एक समस्या खोजने में मदद की: मैंने कई सेटिंग्स हटा दीं, जिसके परिणामस्वरूप फ़ाइलों के आकार पर लगभग कोई प्रभाव नहीं पड़ा, और इसे कुछ सेकंड तक त्वरित किया।

संदर्भ:

→ जीथब
→ एनपीएम