Html5-boilerplate: HTMLLinter का उपयोग करने पर विचार करें?

उपयोग किए गए नियमों को कैसे चुना जाएगा? कुछ मानक नियम वास्तव में व्यक्तिगत प्राथमिकता हैं। उदाहरण के लिए:

https://github.com/yaniswang/HTMLHint/wiki/Attr-value-double-quotes दोनों पूरी तरह से मान्य HTML5 हैं और मुझे नहीं लगता कि यह बॉयलरप्लेट चुनना चाहिए कि किस शैली को डिफ़ॉल्ट होना चाहिए।

https://github.com/yaniswang/HTMLHint/wiki/Tag-self-close दोनों ही मान्य HTML5 हैं, और बाद वाला वास्तव में इसे और अधिक आधुनिक तरीका है क्योंकि यह XHTML के लिए है और इसे HTML5 में अनुमति दी गई है जब तक मुझे पता है कि एक्सएचटीएमएल से एचटीएमएल 5 तक माइग्रेट किया जा रहा है।

https://github.com/yaniswang/HTMLHint/wiki/Attr-value-not-empty दोनों ही मान्य हैं और बाद वाला वही है जो अधिकांश लोग उपयोग करते हैं, लेकिन इसे बुरा तरीका माना जा रहा है।

इनमें से बहुत सारे नियम संदिग्ध हैं और बॉयलरप्लेट के कुछ हिस्सों को त्रुटियों या चेतावनियों के रूप में चिह्नित किया जाएगा। उसके कारण, मैं इसे जोड़ने के खिलाफ हूं और इसके बजाय ऐसी प्राथमिकताएं डेवलपर को छोड़ दी जाएंगी और इसे इस परियोजना के साथ नहीं जोड़ा जाएगा। हो सकता है कि डॉक्स में HTML लिंटर सेक्शन जोड़ें और विभिन्न लिंटर को लिंक प्रदान करें?

@quantumpacket जैसा कि आपने tag-self-close उल्लेख किया है हमेशा एक से दूसरे को चुनने के लिए कम से कम कुछ औचित्य होता है और यहाँ नहीं है जहाँ समुदाय का वजन वैसे ही हो सकता है जैसे वे बॉयलरप्लेट की सामग्री पर कर सकते हैं? जहां कोई औचित्य नहीं है, हम बस उस नियम को नहीं जोड़ते हैं। संदर्भ के लिए यदि हम सभी कोड शैली को JS https://github.com/rcorp/standard-project-structure/issues/6 पर विशेष रूप से AirBNB के लिए

मैं पूरी तरह से आपकी बात मानता हूं, लेकिन ये सिर्फ नियम हैं। जिन्हें हम नहीं चुनते हैं, वे लागू नहीं होते हैं। तो यह एक बहुत ही उदार दृष्टिकोण हो सकता है। और .htmlhintrc से नियमों को जोड़ने / हटाने के लिए डेवलपर्स के लिए एक बॉयलरप्लेट

@ gaurav21r इस

किन मानों को चुनना है, शुरुआती बिंदु परियोजना से ही स्पष्ट होगा। साझा किए गए उदाहरणों के मामले में @quantumpacket- हम दोहरे उद्धरण चिह्नों का उपयोग करते हैं, खाली विशेषताओं का उपयोग करते हैं और स्वयं को बंद नहीं करते हैं। वहां से, मुझे यकीन है कि लोगों की राय होगी।

@roblarsen हम पीआर के साथ योगदान करना पसंद करेंगे। हमने पहले ही नियम के लिए एक अच्छा शुरुआती आधार चुना है। https://github.com/rcorp/standard-project-structure/issues/13

इसका उपयोग बड़े-बड़े एक-दो जोड़े करते हैं। मैं देखता हूँ कि क्या यह बॉयलरप्लेट से मेल खाता है और बहुत अधिक मत है। बाकी हम पीआर में ही चर्चा कर सकते हैं!

इस मुद्दे पर कोई प्रगति?

@ gaurav21r कोई अपडेट? यदि नहीं, तो इस पर कोई और रोक लगाना चाहता है?

@roblarsen अगर ऐसा होता है कि @ gavav21r आगे नहीं बढ़ पा रहा है तो मुझे इसे करने में खुशी होगी।

@AlexxNica अच्छा लगता है। हम हमेशा मदद से प्यार करते हैं।

बहुत देर से प्रतिक्रिया के लिए क्षमा करें! @roblarsen @AlexxNica 15 तक ऐसा करने की कोशिश करेगा। यदि नहीं, तो जो कोई भी मदद करने में प्रसन्न होगा!

कोई चिंता नहीं!

15 वां आया और गया! यह खुला है जो कोई भी इसे करने की कोशिश करना चाहता है!

क्या हमें यकीन है कि HTMLHint वहाँ से बाहर सबसे अच्छा विकल्प है?

@AlexxNica मुझे इस मोर्चे पर शून्य अनुभव है, इसलिए मैं सवारी के लिए हूं। जो कोई भी इसे लेना चाहता है, वह यहां कुछ चर्चा खोल सकता है और मैं पूरी कोशिश करूंगा कि युद्ध के रूप में प्रतिक्रिया प्रदान करूं, लेकिन यह निश्चित रूप से कुछ ऐसा है जो समुदाय के हाथों में है।

प्रोजेक्ट में अधिक कोड जोड़ने से पहले हमें इस पर एक अच्छी नज़र डालनी होगी। इससे पहले कि हम कोई कार्रवाई करें, चीजें सुनिश्चित हों:

क्या इसे लागू करने की आवश्यकता को उचित ठहराने के लिए पर्याप्त मददगार है?
· क्या प्रेषण और रखरखाव करना आसान है?
· क्या यह किसी / हमारे द्वारा परीक्षण किया गया था?
क्या हम वास्तविक मॉडल पर वास्तविक सुधार देखते हैं?
क्या हमने यह देखने के लिए हमारे कोड के खिलाफ परीक्षण चलाए कि क्या हमें विश्लेषक के अनुरूप होने के लिए कुछ भी बदलना नहीं होगा? (ताकि उपयोगकर्ताओं को स्क्रीन पर उनके मॉनिटर से अधिक त्रुटियों के साथ फंस न सकें)
· क्या इसकी दीर्घकालिक उपस्थिति होगी? (मुझे नहीं लगता कि किसी ऐसी चीज़ को लागू करना एक अच्छा विचार है जो समय की ठोस मात्रा के लिए मौजूद नहीं होगी)
· इसके उपयोग में आसानी क्या है?

@roblarsen सकें, आपको इस पर लेबल बदलने पर विचार? मुझे लगता है कि " awaiting feedback " और (शायद) " HTML " अधिक उपयुक्त होगा।

मैंने उन को जोड़ा। यह अभी भी मदद चाहता है और अभी भी एक नई सुविधा है। मैं व्यक्तिगत रूप से इसे छूने नहीं जा रहा हूं, इसलिए यह निश्चित रूप से कुछ है जिसे समुदाय को चलाना होगा।

मुझे लगता है कि यहां दो प्रश्न हैं:

• क्या हमें उपयोगकर्ताओं के लिए src / dist फोल्डर में .htmlhintrc शामिल करना चाहिए?
  HTMLHint का केवल वास्तव में पूर्ण, संकलित HTML पृष्ठों का उपयोग करने का इरादा है (उदाहरण के लिए, यह डिफ़ॉल्ट रूप से जांचा जाता है कि हर फ़ाइल में <title> टैग है, इसलिए यह वास्तव में अधिकांश सर्वर साइड या अस्थायी भाषा के लिए उपयुक्त नहीं है। इसलिए) मुझे लगता है कि यह सीमित मूल्य का है क्योंकि बहुत से उपयोगकर्ता Angular, React, PHP, ASP या तरल जैसी टेम्प्लेटिंग भाषाओं का उपयोग कर रहे हैं जहां यह या तो कई त्रुटियां देगा या बिल्कुल भी काम नहीं करेगा। उपयोगकर्ता इसे प्रदर्शित नहीं करने के लिए सभी नियमों को संपादित कर सकता है। लेकिन फिर उस तरह के उद्देश्य को भी इसमें शामिल किया जाता है। और सभी उपयोगकर्ताओं को इसका उपयोग करने के लिए अपनी IDE के लिए एक प्लगइन स्थापित करने की आवश्यकता होगी। मुझे नहीं लगता कि पर्याप्त उपयोगकर्ता शुद्ध HTML में वेब पेजों को कोडित कर रहे हैं बिना वारंट शामिल करना इसका समावेश (मैं व्यक्तिगत रूप से एचटीएमएल ईमेल का उपयोग करते समय केवल एचटीएमएल ईमेल का उपयोग करता हूं - कीड़े खोजने के लिए महान) - और हम किसी भी जेएस या सीएसएस लिंटर / हंटर कॉन्फिग फाइलों को शामिल नहीं करते हैं।

• त्रुटियों के लिए जाँच करने के लिए क्या हमें निर्माण प्रणाली में HTMLHint शामिल करना चाहिए?
  हां, मुझे लगता है कि यह एक अच्छा विचार हो सकता है। हमारी निर्माण प्रणाली वर्तमान में गुलप का उपयोग कर रही है और इसे एकीकृत करने के लिए एक एनपीएम पैकेज है: https://www.npmjs.com/package/gulp-htmlhint। मैं अगले कुछ दिनों में इस पर गौर करूंगा। यह HTML त्रुटियों के लिए जाँच करेगा जब संकलन और एक साइट को तैनात करने से पहले मुद्दों को खोजने के लिए फायदेमंद हो सकता है।

टेम्प्लेटिंग भाषाओं के साथ html लिंटर का उपयोग करने में असमर्थता एक ऐसी चीज है जो हमें हमेशा इसका उपयोग करने से रोकती है। प्रतिक्रिया एक और कहानी है, क्योंकि jsx को प्रभावी रूप से ESLint के साथ जोड़ा जा सकता है।

लाइनिंग बिल्ड प्रोजेक्ट के लिए फायदेमंद लगता है, लेकिन एंड यूज़र के लिए ऐसा नहीं है। लेकिन कुछ भी नहीं से बेहतर लगता है, कम से कम यह बॉयलरप्लेट के स्रोत में कभी-कभी त्रुटियों को रोक देगा।

Btw, मुझे ऐसे तुच्छ कार्यों के लिए गुलप का उपयोग करने के कारण नहीं दिखते। लिंटर के लिए अतिरिक्त परतों से बचने के लिए और npm test ( उदाहरण देखें) से सीधे कॉल करना हमेशा आसान और अधिक विश्वसनीय होता है।

IMO, आपको गैर-मानक टूल से दूर रहना चाहिए।

ऐसा लगता है कि आप किसी भी सत्यापनकर्ता का उपयोग नहीं करते हैं, और मैं अनुभव से बोल रहा हूं क्योंकि बूटस्ट्रैप v4-dev पर उन्होंने htmlhint पर स्विच किया था जो मूल रूप से किसी भी वास्तविक त्रुटियों को नहीं पकड़ता था।

मेरा सुझाव आधिकारिक सत्यापनकर्ता vnu.jar का उपयोग करना होगा, भले ही इसके लिए जावा की आवश्यकता हो। आपके पास एक रैपर स्क्रिप्ट हो सकती है जो जावा उपलब्ध होने पर इसे चलाएगी।

मैंने हाल ही में बूटस्ट्रैप में एक समान परिवर्तन किया (देखें https://github.com/twbs/bootstrap/pull/24149) क्योंकि मैं इस तथ्य से नाराज था कि हम मूल रूप से htmlhint के साथ किसी भी सत्यापन के बिना थे।

HTMLHint दुर्भाग्य से अब सक्रिय रूप से बनाए नहीं रखा गया है (https://github.com/yaniswang/HTMLHint) और जैसा कि @XhmikosR कहता है - इस मुद्दे को बंद करने के लिए मैं वोट देता हूं, इसलिए मुद्दे हैं।

क्रिकेट्स + ऊपर