Gatsby: [fsevents बग] मैक पर "स्रोत और रूपांतरित नोड्स" / "createPagesStatefully" पर अटक गया

अपडेट किया गया - मैंने gatsby-node.js फ़ाइल पर टिप्पणी करते हुए परीक्षण किया और बिल्ड एक अवसर पर आगे बढ़ गया, लेकिन फिर मैंने फिर से कोशिश की और यह कर रहा था और यह फिर से उसी स्थान पर अटक गया।

क्या मेरे प्राचीन कंप्यूटर, 2010 मैकबुक प्रो (8 जीबी रैम और एसएसडी में अपग्रेड) के कारण ऐसा कोई मौका है, मुझे अभी तक नहीं रोका गया है लेकिन मुझे पता है कि इसके दिन सीमित हैं। यह मेरे लिए एक शौक है और मेरे पास छोटे बच्चे हैं इसलिए एक नए कंप्यूटर पर खर्च करने के लिए डॉलर नहीं है क्योंकि यह उन्नत राम और एसएसडी के साथ ठीक काम किया है।

मैंने वापस गैट्सबी 2.13.52 पर वापस लौटने की कोशिश की है, जो कि पिछले संस्करण था जिस पर मैं स्थिर था, मैंने 16.8.6 पर प्रतिक्रिया करने के लिए पुन: प्रयास करने का भी प्रयास किया है।

दिलचस्प बात यह है कि मैंने इसे एक बार सफलतापूर्वक बनाया था जब मैंने 16.8.6 पर प्रतिक्रिया दी थी, लेकिन उसके बाद पहली बार यह उसी जगह पर लटका हुआ था जो वास्तव में मेरे लिए अजीब व्यवहार है।

मैं भी, शायद ही कभी, बिना किसी कारण के मैं ठीक करने के लिए इसे प्राप्त कर सकता हूं। ऐसा होने पर कोई तुक या तर्क नहीं लगता है। मैंने कुछ घंटे बिताए जो पैटर्न या त्रुटियों की तलाश में थे जो इस कारण हो सकते हैं लेकिन कुछ भी नहीं मिला। मैंने https://github.com/gatsbyjs/gatsby/issues/6654 की समीक्षा की और वहां कुछ वस्तुओं को आजमाया।

यह मुझे मेरे द्वारा सामना किए गए सबसे अजीब बगों में से एक के लिए मिला है क्योंकि व्यवहार कोड में परिवर्तन योग्य परिवर्तन के बिना बदलने लगता है। कुछ मामलों में बिल्ड स्रोत पर लटक जाता है और नोड्स (60% समय) को बदल देता है, कुछ मामलों में यह क्रिएट पेज स्टेटस (20%) पर लटकाता है, कुछ मामलों में यह सफलतापूर्वक (20%) बनाता है। मैंने कोड की एक पंक्ति को बदले बिना इन तीनों व्यवहारों को प्रदर्शित किया है।

मैंने इस व्यवहार को गैट्सबी-स्टार्टर-ब्लॉग में भी दोहराया है, जो वास्तव में अजीब है। फिर से यह मुझे लगता है कि यह मेरे स्थानीय स्तर पर एक मुद्दा है। दिलचस्प है कि यह केवल createPagesStatefully लटका है।

मैं अब यह सोचना शुरू कर रहा हूं कि इसका लाइब्रेरी से कुछ लेना-देना है जो होमबॉर्न द्वारा स्वचालित रूप से अपडेट हो जाता है - जिसका मुझे कोई पता नहीं है लेकिन यह केवल एक चीज है जिसके बारे में मैं सोच सकता हूं कि मैंने परीक्षण नहीं किया है।

यहां उन चीजों की एक सूची दी गई है जो मैंने अब तक कोशिश की हैं:

• नोड संस्करण बदलते हुए, 12, 10 और 8 की कोशिश की

• मेरे प्रतिबद्ध इतिहास में एक पिछले बिंदु पर लौटकर काम कर रहा था - यह अभी भी विफल रहता है।

• Gatsby-config के प्लग-इन और क्षेत्रों पर टिप्पणी करना

• मेरी gatsby-node.js की सामग्री पर टिप्पणी करना

• Netlify पर इसे फिर से टेस्ट करें, अभी भी सफलतापूर्वक बनाया गया है, जो मुझे लगता है कि यह मेरे कंप्यूटर के साथ कुछ करना होगा।

• मेरे src / Pages डायरेक्टरी में 4 पेज डिलीट करना और एक बहुत ही बुनियादी index.mdx फाइल में डालना

• सभी नोड_मॉड्यूल और लॉक फ़ाइलों को हटाना, पुनः इंस्टॉल करना

• कंप्यूटर को पुनरारंभ करना

• जीथब से थीम / स्टार्टर के नए क्लोन के साथ एक नया यार्न कार्यक्षेत्र बनाना।

• परीक्षण gatsby- स्टार्टर-ब्लॉग, समान व्यवहार लेकिन यह createPagesStatefully पर लटका हुआ है

नमस्ते,

मैं बहुत कम कर सकता हूं लेकिन पुष्टि करता हूं कि मैं इस मुद्दे को कई गैट्सबाय स्टार्टर्स पर देख रहा हूं। और, जैसा कि आप बताते हैं, यह कभी-कभी निर्माण करने या निर्माण को रोकने का फैसला करता है, या तो "स्रोत और ट्रांसफ़ॉर्म नोड्स" पर लटका या createPagesStatefully।

काफी निराशा और इसे ठीक करने के लिए सबसे अपमानजनक प्रयास करने के लिए अग्रणी।

मैं इस समस्या का गवाह नहीं था लेकिन यह अजीब लगता है और मैं वास्तव में आपके पक्ष में इस व्यवहार का कारण जानना चाहूंगा।

तैयारी
आपको समस्या की जड़ तक पहुँचने के लिए नोड डीबगर का उपयोग करने का प्रयास करना चाहिए। आपके package.json में एक कार्य इस तरह दिखेगा। यदि आप VSCode का उपयोग कर रहे हैं तो आप इस कार्य के साथ आंतरिक डीबगर का उपयोग करने के लिए "ऑटो अटैच" को सक्षम कर सकते हैं (सुनिश्चित करें कि आप इस उद्देश्य के लिए आंतरिक टर्मिनल का उपयोग करते हैं)

"start:debug": "node --inspect=127.0.0.1:9232 node_modules/.bin/gatsby develop",

डिबगिंग निश्चित रूप से किसी भी आईडीई के साथ काम करेगा सुनिश्चित करें कि आप अपने डिबगर को सही तरीके से संलग्न करते हैं।

1. वेरिएंट: न्यूनतम प्रजनन
आपने समस्या के स्रोत के रूप में createPagesStatefully उल्लेख किया है। यदि आप सुनिश्चित हैं कि समस्या का स्रोत शायद आप इसे पुन: पेश करने के लिए एक बहुत छोटी परियोजना बना सकते हैं। सभी शुरुआतओं को खोदें, बस सीधे गैट्सबी का उपयोग करें और createPagesStatefully उपयोग gatsby-node.js कुछ उदाहरणों के साथ करें जो आपके शुरुआती चीजों की नकल करते हैं। फिर गैट्सबी शुरू करें और इसे नोड निरीक्षण के माध्यम से डिबग करें।

इस तरह आप पा सकते हैं कि यह कहाँ लटका हुआ है।

2. वैकल्पिक: अपनी परियोजना / स्टार्टर के अंदर
आप निश्चित रूप से एक ही तकनीक के साथ अपनी परियोजना के अंदर समस्या को दूर करने की कोशिश कर सकते हैं। लेकिन शायद आपके पास कई समस्याएं हैं जो समस्याओं के कारण पर आपके विचार को स्टैकिंग और धुंधला कर रही हैं। इसलिए मैं हमेशा डिबग शुरू करने से पहले एक न्यूनतम प्रजनन प्राप्त करने की कोशिश करूंगा।

सौभाग्य।

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

जहां यह और भी विचित्र था कि वास्तविक गैट्सबी-स्टार्टर-हैलो-वर्ल्ड मेरे कंप्यूटर पर ठीक काम करता है और निर्माण करता है। लेकिन ... अगर मैं लॉक फ़ाइल को हटा देता हूं और नई लॉक फ़ाइल को फिर से बनाने के लिए यार्न प्राप्त करता हूं, तो निर्माण विफल हो जाता है, स्रोत पर लटका और नोड्स को बदल देता है। अगर मैं "हैलो-वर्ल्ड" से लॉक फ़ाइल की प्रतिलिपि बनाता हूं और इसका उपयोग करता हूं, तो मैं अपना स्ट्रिप डाउन और न्यूनतम कार्यान्वयन प्राप्त कर सकता हूं। इसलिए मेरा वर्तमान सिद्धांत यह है कि मेरी लॉक फ़ाइलों में किसी प्रकार की संस्करण समस्या है जो इस समस्या का कारण बन रही है, लेकिन मैं यहां फंस गया हूं।

मैंने अपने सभी होमब्रेव इंस्टाल्स को भी डिलीट कर दिया और नोड, यार्न, गिट इत्यादि को फिर से इंस्टॉल कर दिया। बस यह सुनिश्चित करने के लिए कि यह मजाकिया व्यापार का कुछ हिस्सा नहीं था।

इसे बढ़ाने के लिए धन्यवाद @ehowey .... मुझे लगा कि यह सिर्फ मेरे लिए है क्योंकि यह काफी रुक-रुक कर (लेकिन 50% से अधिक समय होता है)। आपने जैसा किया वैसा ही करने की कोशिश की और स्थिति को खराब कर दिया। जब मैं ⠙ source and transform nodes पर लटकता हूं तो इसका मतलब आमतौर पर मेरे टर्मिनल को मारना होता है।

अगर मुझे कुछ मिला तो मैं आपको बता दूंगा। और मैं यह धागा भी देखूंगा।

@georgiee - जानकारी जानकारी के लिए धन्यवाद। मैं देखने जा रहा हूं कि क्या मुझे वेबस्टॉर्म के साथ काम करने वाला नोड डिबगिंग मिल सकता है।

मुझे न्यूनतम प्रजनन का आपका विचार भी पसंद है। लेकिन जब मैं गैट्सबी को थोड़ा और गहराई से समझूंगा तो मुझे समय लगेगा।

वर्तमान में यह "स्रोत और रूपांतरण नोड्स" पर लटका हुआ है। शायद ही कभी, यह बनाने के लिए बनाता है। अन्यथा यह सामान्य रूप से बनाता है।

मैं वर्तमान में एक कमजोर निर्भरता को ठीक करने के लिए "यार्न अपग्रेड" करने के बाद उसी समस्या का सामना कर रहा हूं। यहाँ मेरा सेट अप है:

प्रणाली:
OS: macOS 10.15
CPU: (4) x64 Intel (R) कोर (TM) i7-7567U CPU @ 3.50GHz
शैल: 5.7.1 - / बिन / zsh
बायनेरिज़:
नोड: 12.8.1 - / usr / स्थानीय / बिन / नोड
यार्न: 1.17.3 - / usr / स्थानीय / बिन / यार्न
npm: 6.10.3 - / usr / स्थानीय / बिन / npm
भाषाएँ:
पायथन: 2.7.16 - / usr / स्थानीय / बिन / अजगर
ब्राउज़र:
क्रोम: 76.0.3809.132
फ़ायरफ़ॉक्स: 68.0.2
सफारी: 13.0
npmPackages:
gatsby: ^ 2.13.42 => 2.14.7
gatsby-background-image: ^ 0.8.3 => 0.8.6
gatsby- छवि: ^ 2.2.7 => 2.2.15
gatsby- प्लगइन-प्रकट: ^ 2.2.4 => 2.2.10
gatsby-plugin-netlify: ^ 2.1.4 => 2.1.10
gatsby-plugin-netlify-cms: ^ 4.1.6 => 4.1.12
gatsby- प्लगइन-ऑफ़लाइन: ^ 2.2.5 => 2.2.10
gatsby-plugin-reaction-helmet: ^ 3.1.2 => 3.1.5
gatsby-plugin-reaction-svg: ^ 2.1.1 => 2.1.2
gatsby-plugin-sass: ^ 2.1.3 => 2.1.12
gatsby-plugin-sharp: ^ 2.2.9 => 2.2.18
gatsby- प्लगइन-टाइपोग्राफी: ^ 2.3.2 => 2.3.5
gatsby-plugin-webfonts: ^ 1.1.0 => 1.1.0
gatsby-comment-images: ^ 3.1.10 => 3.1.19
gatsby- टिप्पणी-सापेक्ष-चित्र-v2: ^ 0.1.5 => 0.1.5
gatsby- टिप्पणी-उत्तरदायी-iframe: ^ 2.2.5 => 2.2.10
gatsby-source-filesystem: ^ 2.1.6 => 2.1.18
gatsby- ट्रांसफार्मर-टिप्पणी: ^ 2.6.12 => 2.6.19
गैट्सबी-ट्रांसफार्मर-शार्प: ^ 2.2.5 => 2.2.12

मैं वर्तमान में एक कमजोर निर्भरता को ठीक करने के लिए "यार्न अपग्रेड" करने के बाद उसी समस्या का सामना कर रहा हूं। यहाँ मेरा सेट अप है:

अपडेट: मैं अपनी पुरानी "यार्न.लॉक" फ़ाइल को पुनर्स्थापित करके चीजों को ठीक करने का प्रबंधन करता हूं।

@ hbthen3rd

अपडेट: मैं अपनी पुरानी "यार्न.लॉक" फ़ाइल को पुनर्स्थापित करके चीजों को ठीक करने का प्रबंधन करता हूं।

मेरा अनुभव है कि समस्या बिना किसी स्पष्ट कारण के केवल बाद में वापस जाने के लिए दूर जा सकती है। यार्न को बहाल करने के बावजूद आपको समस्या वापस आ सकती है। हमें जानकारी देते रहिए।

यहाँ गैट्सबी-स्टार्टर-हैलो-वर्ल्ड का उपयोग करते हुए एक न्यूनतम प्रजनन है:

https://github.com/ehowey/gatsby-test-lockfiles

रेपो में शामिल वर्तमान लॉक फ़ाइल मेरे लिए विफल है। मैंने yarn-working.lock और yarn-notworking.lock के रेपो में प्रतियां भी शामिल की हैं। उम्मीद है कि यह किसी के लिए समस्या निवारण के लिए आसान बनाता है।

मेरा वर्तमान परिवेश:

प्रणाली:
OS: macOS हाई सिएरा 10.13.6
सीपीयू: (2) x64 इंटेल (आर) कोर (टीएम) 2 डुओ सीपीयू P8600 @ 2.40GHz
शैल: ३.२.५.5 - / बिन / बैश
बायनेरिज़:
नोड: 10.16.3 - / usr / स्थानीय / बिन / नोड
यार्न: 1.17.3 - / usr / स्थानीय / बिन / यार्न
npm: 6.10.3 - / usr / स्थानीय / बिन / npm
भाषाएँ:
पायथन: 2.7.10 - / usr / बिन / अजगर
ब्राउज़र:
क्रोम: 76.0.3809.132
फ़ायरफ़ॉक्स: 67.0.2
सफारी: 12.1.2
npmPackages:
gatsby: ^ 2.13.73 => 2.15.0
npmGlobalPackages:
गैट्सबी-क्लि: 2.7.40

मैं एक ही मुद्दे का अनुभव कर रहा हूं।

कुछ दिशा मुझे मिल गई है:

1. gatsby-plugin-sitemap 2.2.9 से 2.2.6 अपग्रेड करने से yarn develop साथ समस्या हल हो गई।

   • यह अजीब है क्योंकि gatsby-plugin-sitemap को विकास के निर्माण को प्रभावित नहीं करना चाहिए।

2. yarn build अभी भी काम नहीं करते हैं, लेकिन जब मैं gatsby-plugin-sitemap अपने कॉन्फ़िगर को निकालता हूँ, yarn build फिर से काम करता है।

@sharvit मैं रिपोर्ट कर सकता हूं कि यह मेरे मामले में काम नहीं आया। खुशी है कि यह आपके लिए तय हो गया है, मुझे लगता है कि यह अंततः लॉक फ़ाइलों के साथ कुछ करना है और कुछ अजीब संस्करण लॉक फ़ाइल के आंत्र में गहरी जारी करते हैं।

मैं एक काम के निर्माण में वापस लाने में कामयाब रहा हूं, ज्यादातर समय, शायद 8/10 बार एक पुरानी लॉक फाइल में लौटकर और कुछ कॉपी और पेस्ट करके। मैं अब CTRL + C को बिल्ड को छोड़ने के लिए मजबूर कर सकता हूं अगर यह लटका हुआ है जो मैं इस प्रक्रिया में एक बिंदु पर नहीं कर सकता। मुझे नहीं पता कि इसे लॉक फ़ाइल में क्या ठीक किया गया है, लेकिन मुझे लगता है कि सुराग मैं एक लॉक फ़ाइल की दो प्रतियों के साथ ऊपर पोस्ट किया गया है, एक जो काम करता है और एक ऐसा नहीं है। यह एक बग का एक अजीब जानवर है। आमतौर पर कंप्यूटर में जमीन की चीजें आश्वस्त होकर काम करती हैं या काम नहीं करती हैं।

@steinitz अपने अंत पर कोई भाग्य? मेरे पास वही था जिसका आप उल्लेख करते हैं। यह बेहतर, बहुत अच्छा लग रहा था, लेकिन सही नहीं है और अब लगभग हर बार फिर से असफल हो रहा है। बहुत निराशा होती है।

@ इहो

जैसा कि आप कल्पना कर सकते हैं, इस समस्या की फिर से ऑफ-ऑफ प्रकृति के कारण, मुझे रिपोर्ट करने में संकोच हो रहा है। यहाँ बिंदु में एक मामला है:

नोड_मॉड्यूल निर्देशिका को हटाने के बाद, यार्न को हटाकर फिर चल रहा है
npx yarn-upgrade-all
तथा
yarn install
सब कुछ ठीक था।

फिर, अभी, आपके संदेश के जवाब में, मैंने कोशिश की
yarn start
परिणाम: यह फिर से लटक जाता है
source and transform nodes

मुझे लगता है कि करने के लिए दो समझदार चीजें हैं:

1. वेबस्टॉर्म डिबगिंग के साथ काम करने के लिए @georgiee की सलाह लें
   node --inspect और देखें कि क्या मैं किसी भी स्पष्ट समस्याओं को देख सकता हूं
2. Gatsby को थोड़ी देर के लिए यह देखने के लिए सेट करें कि कोई स्मार्ट व्यक्ति समस्या हल करता है या नहीं

अपडेट करें:

ctl-C उपरोक्त अटकी प्रक्रिया (जो अटकी हुई प्रक्रिया को रोकने के लिए उपयोग नहीं किया गया था जो दोगुना कष्टप्रद था)।
तब yarn start createPagesStatefully पर अटक गया।
ctl-C'd फिर, एक और yarn start - source and transform nodes पर अटक गया
ctl-C'd एक बार (इसके नरक के लिए) - इस बार yarn start ने काम किया और यह चल रहा है

पता नहीं क्या है कि बनाने के लिए, लेकिन वहाँ यह है।

यह वही है जो मैं देख रहा हूं, आज रात यह बदतर लगता है शायद 1/10 बार या उससे कम सफलतापूर्वक निर्माण हो। एक प्रोग्रामिंग / कोडिंग के नजरिए से यह सुपर अजीब व्यवहार है। यह कुछ दिनों पहले बेहतर तरीके से काम करता दिख रहा था, जो आज 2.15.1 पर है और आज 2.15.6 पर है। मुझे यह भी आश्चर्य है कि हम सभी साझा करते हैं कि इस बग का कारण क्या है। क्या आप gatsby info --clipboard कमांड चला सकते हैं और इसे पोस्ट कर सकते हैं?

यह स्पष्ट रूप से सुपर व्यापक नहीं है अन्यथा रिपोर्ट्स की बाढ़ आ जाएगी लेकिन यह भी मेरे जैसा नहीं है जैसा कि मैंने मूल रूप से सोचा था। हम सभी यार्न का उपयोग करने लगते हैं, जो मेरे लिए एक आवश्यकता है क्योंकि मैं एक यार्न कार्यक्षेत्र में थीम पर काम कर रहा हूं। मैं अभी भी इसे gatsby-starter-hello-world पर पुन: पेश करने में सक्षम हूं, इसलिए मेरा मानना ​​है कि यह मुख्य गैट्सबी फाइलों में कुछ निर्भरता का मुद्दा या संघर्ष है।

@ehowey यहाँ gatsby info अनुरोध किया है

प्रणाली:
OS: macOS 10.14.6
CPU: (4) x64 Intel (R) कोर (TM) i7-5557U CPU @ 3.10GHz
शैल: ३.२.५.5 - / बिन / बैश
बायनेरिज़:
नोड: 12.9.1 - / usr / स्थानीय / बिन / नोड
यार्न: 1.17.3 - / usr / स्थानीय / बिन / यार्न
npm: 6.11.2 - / usr / स्थानीय / बिन / npm
भाषाएँ:
पायथन: 2.7.16 - / usr / स्थानीय / बिन / अजगर
ब्राउज़र:
क्रोम: 76.0.3809.132
फ़ायरफ़ॉक्स: 68.0.1
सफारी: 12.1.2
npmPackages:
gatsby: ^ 2.14.3 => 2.14.7
gatsby- छवि: ^ 2.2.14 => 2.2.15
gatsby-plugin-feed: ^ 2.3.9 => 2.3.9
gatsby-plugin-i18n: ^ 1.0.1 => 1.0.1
gatsby-plugin-less: ^ 3.0.2 => 3.0.4
gatsby- प्लगइन-प्रकट: ^ 2.2.9 => 2.2.10
gatsby-plugin-offline: ^ 2.2.10 => 2.2.10
gatsby- प्लगइन-प्रतिक्रिया-हेलमेट: ^ 3.1.5 => 3.1.5
gatsby-plugin-robots-txt: ^ 1.5.0 => 1.5.0
gatsby-plugin-sharp: ^ 2.2.18 => 2.2.18
gatsby-plugin-sitemap: ^ 2.2.9 => 2.2.9
gatsby-comment-images: ^ 3.1.19 => 3.1.19
gatsby-comment-prismjs: ^ 3.3.9 => 3.3.9
gatsby-source-filesystem: ^ 2.1.18 => 2.1.18
gatsby- ट्रांसफार्मर-टिप्पणी: ^ 2.6.19 => 2.6.19
गैट्सबी-ट्रांसफार्मर-शार्प: ^ 2.2.12 => 2.2.12
npmGlobalPackages:
गैट्सबी-क्लि: 2.7.40

मैं एक ही मुद्दा रहा था: साइट Netlify पर निर्दोष रूप से बनाया गया था, लेकिन दोनों gatsby build और gatsby develop साथ मेरी विकास मशीन पर लटका दिया गया।

पैकेज संस्करणों के साथ खेलने के बाद, मैंने देखा कि संस्करण 2.2.10 से 2.2.9 तक gatsby-plugin-sitemap का पुनरावृत्ति करना मेरे लिए समस्या तय की। अजीब तरह से पर्याप्त है, यहाँ कुछ लोगों को 2.2.9 के साथ समस्या है, जिसका मतलब है कि समस्या कहीं और रहती है।

संपादित करें: बहुत जल्द ही बोला गया, गैट्सबी अभी भी "स्रोत और रूपांतरित नोड्स" और "createPagesStatefully" चरणों में लटका है, हालांकि बहुत कम बार।

@goblindegook इस विशेष मुद्दे के साथ एक सामान्य पैटर्न लगता है। क्योंकि मुद्दा आता है और जाता है, प्रतीत होता है मौसम के साथ, दिन का समय, बूट होने के बाद का समय ... आप विश्वास कर सकते हैं कि आपने जो कुछ किया है, उसने इसे ठीक किया है - केवल इसे पुनरावृत्ति करने के लिए।

इस समस्या का अनुभव करते हुए, gatsby-plugin-sitemap 2.2.6 तक डाउनग्रेड किया गया और लगता है कि इसे ठीक कर लिया गया है

FWIW, मैं यह भी अनुभव कर रहा हूं, लेकिन yarn और न ही gatsby-plugin-sitemap उपयोग कर रहा हूं।

मेरे gatsby info के मामले में यह मदद करता है:

  System:
    OS: macOS 10.14.6
    CPU: (4) x64 Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 12.9.1 - /usr/local/bin/node
    npm: 6.11.2 - /usr/local/bin/npm
  Languages:
    Python: 3.7.4 - /usr/local/opt/python/libexec/bin/python
  Browsers:
    Chrome: 76.0.3809.132
    Firefox: 68.0.1
    Safari: 12.1.2
  npmPackages:
    gatsby: ^2.15.1 => 2.15.1 
    gatsby-cli: ^2.7.41 => 2.7.41 
    gatsby-image: ^2.2.15 => 2.2.15 
    gatsby-plugin-catch-links: ^2.1.6 => 2.1.6 
    gatsby-plugin-google-tagmanager: ^2.1.7 => 2.1.7 
    gatsby-plugin-manifest: ^2.2.12 => 2.2.12 
    gatsby-plugin-offline: ^3.0.0 => 3.0.0 
    gatsby-plugin-react-helmet: ^3.1.5 => 3.1.5 
    gatsby-plugin-sass: ^2.1.12 => 2.1.12 
    gatsby-plugin-sharp: ^2.2.18 => 2.2.18 
    gatsby-remark-images: ^3.1.19 => 3.1.19 
    gatsby-source-filesystem: ^2.1.18 => 2.1.18 
    gatsby-transformer-remark: ^2.6.19 => 2.6.19 
    gatsby-transformer-sharp: ^2.2.12 => 2.2.12 
    gatsby-transformer-yaml: ^2.2.7 => 2.2.7 
  npmGlobalPackages:
    gatsby-cli: 2.7.41

मेरे लिए, gatsby clean साथ कैश की सफाई से समस्या हल हो गई।

मैं अभी भी कुछ शिकार कर रहा हूं, यह पता लगाने की कोशिश कर रहा हूं। फिर भी मेरे लिए एक समस्या है। क्या किसी को पता है कि यह बाबेल 7.0.0 -> 7.5.5 से स्विच से संबंधित हो सकता है। यह स्विच उस समय के आसपास हुआ जब मैंने इस बग का अनुभव करना शुरू किया और समस्याओं को देखने के लिए शुरुआत के साथ मेरे साथ मेल खाता है ... मैं 7.0.0 पर बेबल संस्करणों को खूंटे के लिए काम करने के लिए यार्न के प्रस्तावों को प्राप्त करने की कोशिश कर रहा हूं, लेकिन इसके साथ सफलता नहीं मिली है यह अभी तक।

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

https://github.com/gatsbyjs/gatsby/issues/6385#issuecomment -531949380 से - मैं भी इस मुद्दे को देख रहा हूं लेकिन gatsby clean ने इसे हल नहीं किया। ऐसा लगता है कि यह सिर्फ सीएलआई प्रिंटआउट लटका हो सकता है, यही कारण है कि टर्मिनल का आकार बदलना इसे ठीक करता है ?? 😕🤷♂ 🤷 😕

टर्मिनल विंडो का आकार बदलना मेरे लिए इसे ठीक करता है! मैंने इसे बड़े पैमाने पर परीक्षण नहीं किया है, क्या इस समस्या वाले कुछ अन्य लोग भी इसे आज़मा सकते हैं? क्या एक अजीब बग और संभावित अजीब समाधान।

मैं ठीक उसी मुद्दे का सामना कर रहा हूं - गैट्सबी "स्रोत और ट्रांसफ़ॉर्म नोड्स" पर अटक जाता है या "createPagesStatefully" अक्सर, और मैं _not_ किसी भी स्रोत प्लगइन्स का उपयोग कर रहा हूं। मैंने हाल ही में "रीसाइज़ टर्मिनल विंडो" फिक्स का सामना किया और 140% से चकरा गया कि कैसे यह इसे ठीक करता है, लेकिन यह करता है। यह एक बहुत गंभीर मुद्दे की तरह लगता है!

@JaXXz - धन्यवाद! यह मुझे पागल कर रहा था। यह वीएस कोड में टर्मिनल विंडो को आकार देता है। बस इसे थोड़ा ऊपर या नीचे खींचें और विकास कार्य को खुशी के साथ करें। मैंने यार्न और एनपीएम, वर्कस्पेस और नहीं दोनों अलग-अलग मामलों के एक जोड़े में परीक्षण किया। मेरे लिए उन सभी मामलों में काम करने लगता था। यह मेरे लिए अब source and transform nodes तुलना में createPagesStatefully अधिक बार रुकने या लटकने का भी लगता है। मैं इस मुद्दे को अभी के लिए खुला छोड़ देने जा रहा हूं, इसे कम "हैकी" तरीके से तय करने की आवश्यकता हो सकती है, जिसके बारे में कोई और जानता हो कि मेरे साथ कैसा है।

@ मेरे पास एक ही मुद्दा है और vscode कार्यों में टर्मिनल विंडो को स्थानांतरित करना (इस मुद्दे को पढ़ने पर विश्वास नहीं कर सकता जब तक कि मैंने खुद कोशिश नहीं की)।
क्या आपको पता है कि यह केवल वीएस कोड पर होता है?

मेरे पास iTerm 2 पर यह मुद्दा है, इसलिए यह VS कोड विशिष्ट नहीं है।

मेरा मुद्दा भी iTerm 2 में रहा है

वेबस्टॉर्म टर्मिनल, मैक टर्मिनल, iTerm

क्या विभिन्न देव परिवेशों में आप सभी के लिए रीसाइज़िंग टर्मिनल फिक्स काम था?

मेरे अंत में, टर्मिनल का आकार बदलकर iTerm और VSCode पर काम किया (iTermerm पर इस मुद्दे को पुन: पेश करने के लिए कुछ प्रयास किए)

रिज़ॉर्ट टर्मिनल ट्रिक iTerm 2 में मेरे लिए मज़बूती से काम करती है।

हां, iTerm 2 का आकार बदलना पूरी तरह से काम करता है

यदि कार्यों का आकार बदल रहा है, तो मुझे संदेह है कि यह बग संबंधित बफर है, कहीं न कहीं स्टडआउट फ्लश की जरूरत है।

इस तरह का प्रतीत होता है जैसे कि कर्नेल + शेल संबंधित समस्या। संभवतः किसी तरह नोड आपके कर्नेल और / या आपके शेल के साथ इंटरैक्ट करता है। मैं केवल यह कहता हूं क्योंकि मैं लिनक्स या विंडोज का उपयोग करके मुद्दों को दोहराने के लिए प्रतीत नहीं कर सकता। मैं किसी भी ज्ञात मुद्दे को खोजने के लिए प्रतीत नहीं कर सकता, इसलिए या तो क) यह कोड पैटर्न के कुछ संयोजन है जो गैट्सबी + सिस्टम के साथ बातचीत के लिए अद्वितीय है, या बी) मुझे अभी तक पूछने के लिए सही सवाल नहीं पता है।

यदि टर्मिनल का आकार बदलना समस्या को हल करता है, तो यह नोड के बीच कुछ गड़बड़ हो सकता है और kqueue घटना लूप में एक ब्लॉक का कारण बनता है। टर्मिनल का आकार बदलने से प्रक्रिया एक SIGWINCH सिग्नल भेजती है, जो ईवेंट लूप को बाधित करता है, जो इसे मुक्त करता है और इसे जारी रखने की अनुमति देता है।

जब आप फ्रीज़ करते हैं तो क्या आप kill -SIGWINCH ${pid} रनिंग प्रक्रिया पर चलने का प्रयास कर सकते हैं? टर्मिनल का आकार बदलने के समान कार्य करना चाहिए।

मुझे इस बात में भी दिलचस्पी है कि सभी गोले में ऐसा होता है या नहीं। अब तक की जानकारी के आधार पर, यह bash और zsh में विफल रहा है, और यह संभवतः सभी टर्मिनल एमुलेटर के बीच के सामान्य कारकों में से एक है। क्या आप लोग sh , csh , ksh , tcsh , आदि ... की कोशिश कर सकते हैं?

यदि समस्या सभी शेल में होती है, तो मुझे लगता है कि यह कर्नेल नोड के ईवेंट लूप को संभालने का तरीका है। यह भी हो सकता है कि यह एक आंतरायिक समस्या क्यों है। यदि कुछ फ़ंक्शन को प्रोसेसर समय कम मिलता है (हो सकता है कि चर प्रणाली लोड के कारण), तो यह बहुत लंबे समय के लिए ब्लॉक हो सकता है, और शायद कर्नेल कहीं घटना नोड का पुन: उपयोग करने की कोशिश करता है, जिसके परिणामस्वरूप गतिरोध होता है? मैं एपी के इंटर्नल से सुपर परिचित नहीं हूं, लेकिन मैं शर्त लगाता हूं कि source and transform nodes काफी फाइलसिस्टम IO गहन है। इसका मतलब है कि वहाँ शायद बहुत अधिक भार हो रहा है, इसलिए कौन जानता है कि वास्तव में निचले स्तर पर क्या हो रहा है।

मुझे लगता है कि इस बग के सतह क्षेत्र को कम करने की कोशिश करना एक अच्छा विचार होगा। यह source and transform nodes में सबसे अधिक बार होता है, ऐसा लगता है, इसलिए हो सकता है कि इसे संकुचित करने की कोशिश करें कि क्या प्लगइन अवरुद्ध है। निम्नलिखित पंक्तियों को node_modules/gatsby/dist/utils/api-runner-node.js जोड़ने का प्रयास करें:

+ 347       if (api === `sourceNodes`) {
+ 348         debugger;
+ 349       }
  350       resolve(runAPI(plugin, api, Object.assign({}, args, {
  351         parentSpan: apiSpan
  352       })));

फिर node inspect node_modules/.bin/gatsby develop चलाएं। यह शुरू होते ही टूट जाएगा, इसलिए आपको c हिट करना होगा जब आप debug> प्रॉम्प्ट पर पहुँचेंगे, और इसे जारी रखने के लिए प्रतीक्षा करेंगे। यह उस पर टूट जाता है debugger लाइन, लिखने exec console.log(plugin) , और ध्यान दें कि यह में कहते हैं resolve । फिर जारी रखने के लिए c मारा। बस इसे तब तक करें जब तक कि यह लटका न हो ... यदि यह लटका हुआ है।

इवेंट लूप की प्रकृति के कारण, मैं शर्त लगाता हूं कि यह डीबगिंग के दौरान लटका भी नहीं होगा। वे व्यवधान शायद इसे एक ट्रैक पर रखने के लिए पर्याप्त हैं। Async बग नीचे ट्रैक करने के लिए एक वास्तविक दर्द हो सकता है। यदि यह डिबगर का उपयोग करते समय लटका नहीं है, तो उस debugger लाइन को इसके साथ बदलें:

reporter.log(plugin.resolve);

उम्मीद है कि इससे कुछ बदल जाएगा। यह देखना अच्छा होगा कि ब्लॉक किस प्लगइन का कारण बन रहा है। यदि हम इसका पता लगा सकते हैं, तो हम यह पता लगाने में सक्षम हो सकते हैं कि इसे छांटने के लिए क्या अनुकूलित / निष्क्रिय किया जाना चाहिए।

मेरे लिए भी काम करता है आकार बदलना, मैं अपने VSCode शेल के रूप में zsh का उपयोग करता हूं।

@ जेएस-ब्रेख्त - इस तरह की विस्तृत प्रतिक्रिया के लिए समय निकालने के लिए धन्यवाद। मुझे यकीन नहीं था कि मैं kill -SIGWINCH ${pid} इनपुट करने वाला था। मैं निर्माण प्रक्रिया के दौरान ऐसा नहीं कर सका।

Withe डिबगर निम्न कोड से बाहर आया ... मेरे लिए इससे अधिक समझ बनाने के लिए। मैं वास्तव में डिबगर में फंस गया लेकिन .exit अभी भी काम कर रहा था।

⠋ source and transform nodes
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(

< {
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/internal-plugins/internal-data-bridge',
<   id: 'a5079d69-ba80-53dc-82f9-0f440bd5448c',
<   name: 'internal-data-bridge',
<   version: '1.0.0',
<   pluginOptions: { plugins: [] },
<   nodeAPIs: [ 'sourceNodes', 'onCreatePage' ],
<   browserAPIs: [],
<   ssrAPIs: []
< }
< ⠋ source and transform nodes
debug> undefined
debug> c
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(
⠦ source and transform nodes
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(
{
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-plugin-mdx',
<   id: '479d2e25-5a33-5a59-a290-cf1877d39ee5',
<   name: 'gatsby-plugin-mdx',
<   version: '1.0.43',
<   pluginOptions: {
<     plugins: [ [Object] ],
<     extensions: [ '.md', '.mdx' ],
<     defaultLayouts: {
<       default: '/Users/erichowey/Coding/gatsby-catalyst/themes/gatsby-theme-catalyst-core/src/components/layout.js'
<     },
<     gatsbyRemarkPlugins: [ [Object], [Object], [Object] ],
<     remarkPlugins: [ [Function: slug] ]
<   },
<   nodeAPIs: [
<     'sourceNodes',
<     'onCreateNode',
<     'onCreatePage',
<     'onCreateWebpackConfig',
<     'resolvableExtensions',
<     'preprocessSource',
<     'onCreateBabelConfig',
<     'onPreBootstrap',
<     'onPostBootstrap'
<   ],
<   browserAPIs: [ 'wrapRootElement' ],
<   ssrAPIs: [ 'wrapRootElement' ],
<   pluginFilepath: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-plugin-mdx'
< }
< ⠦ source and transform nodes
debug> undefined
{
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-plugin-mdx',
<   id: '479d2e25-5a33-5a59-a290-cf1877d39ee5',
<   name: 'gatsby-plugin-mdx',
<   version: '1.0.43',
<   pluginOptions: {
<     plugins: [ [Object] ],
<     extensions: [ '.md', '.mdx' ],
<     defaultLayouts: {
<       default: '/Users/erichowey/Coding/gatsby-catalyst/themes/gatsby-theme-catalyst-core/src/components/layout.js'
<     },
<     gatsbyRemarkPlugins: [ [Object], [Object], [Object] ],
<     remarkPlugins: [ [Function: slug] ]
<   },
<   nodeAPIs: [
<     'sourceNodes',
<     'onCreateNode',
<     'onCreatePage',
<     'onCreateWebpackConfig',
<     'resolvableExtensions',
<     'preprocessSource',
<     'onCreateBabelConfig',
<     'onPreBootstrap',
<     'onPostBootstrap'
<   ],
<   browserAPIs: [ 'wrapRootElement' ],
<   ssrAPIs: [ 'wrapRootElement' ],
<   pluginFilepath: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-plugin-mdx'
< }
< ⠦ source and transform nodes
debug> undefined
debug> c
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(
{
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-transformer-sharp',
<   id: '822bdf7b-a95a-5885-9351-158705910ac3',
<   name: 'gatsby-transformer-sharp',
<   version: '2.2.16',
<   pluginOptions: { plugins: [] },
<   nodeAPIs: [
<     'onCreateNode',
<     'setFieldsOnGraphQLNodeType',
<     'onPreExtractQueries',
<     'sourceNodes'
<   ],
<   browserAPIs: [],
<   ssrAPIs: [],
<   pluginFilepath: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-transformer-sharp'
< }

⠋ source and transform nodes
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(

< {
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/internal-plugins/internal-data-bridge',
<   id: 'a5079d69-ba80-53dc-82f9-0f440bd5448c',
<   name: 'internal-data-bridge',
<   version: '1.0.0',
<   pluginOptions: { plugins: [] },
<   nodeAPIs: [ 'sourceNodes', 'onCreatePage' ],
<   browserAPIs: [],
<   ssrAPIs: []
< }
< ⠋ source and transform nodes
debug> undefined
debug> c
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(
{
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-source-filesystem',
<   id: '339022db-842c-55bd-8e87-d84bd74a175a',
<   name: 'gatsby-source-filesystem',
<   version: '2.1.26',
<   pluginOptions: { plugins: [], name: 'src', path: 'src/' },
<   nodeAPIs: [ 'sourceNodes', 'setFieldsOnGraphQLNodeType' ],
<   browserAPIs: [],
<   ssrAPIs: [],
<   pluginFilepath: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-source-filesystem'
< }
< ⠋ source and transform nodes
debug> undefined
⠹ source and transform nodes
debug> exec console.log(plugin)
c
c

macOS Sierra, टर्मिनल का उपयोग करते हुए, मेरे लिए काम कर रही है।

@ehowey बस इसलिए मुझे पता है कि मैं आपको सही ढंग से समझ रहा हूं, जब आपने डिबगर में थे तब यह लटका था? उस मामले में, यह मुझे gatsby-source-filesystem तरह लगता है जो अपराधी है, जो मुझे समझ में आता है ... विशेष रूप से मौजूदा, संबंधित, गैट्सबी मुद्दों के कारण।

मैं देखना चाहता हूँ कि क्या प्लगइन परीक्षण चलाने को संभाल सकता है। यदि यह परीक्षण चलाते समय लटका हुआ है, तो मुझे लगता है कि यह देखने का एक आसान तरीका होगा कि यह कहाँ विफल हो रहा है। यदि नहीं, तो ठीक है ... बस कुछ विच्छेदन / डिबगिंग करना होगा, जो मेरे लिए मुश्किल होगा, क्योंकि मेरे पास मैकओएस नहीं है।

क्या आप मुख्य gatsby रेपो डाउनलोड कर सकते हैं, और gatsby-source-filesystem परीक्षण चला सकते हैं?

> git clone [email protected]:gatsbyjs/gatsby.git gatsby-js
> cd gatsby-js
> yarn bootstrap
> yarn jest -- -i './packages/gatsby-source-filesystem/src'

इसके अलावा, क्या आप अपने न्यूनतम प्रजनन भंडार के साथ यह सब कर रहे हैं? मैं देखता हूं कि gatsby-plugin-mdx दो बार चला गया था, इसलिए मुझे बताता है कि यह नंगे पैर का भंडार नहीं है। एक आदर्श दुनिया में, यह बात नहीं होनी चाहिए, लेकिन मुझे लगता है कि जितना संभव हो उतना सरल सेटअप चलाना बेहतर होगा। यदि आप इसे न्यूनतम रेपो के साथ मज़बूती से विफल करने के लिए नहीं पा सकते हैं, तो जो भी सबसे अधिक लगातार (एक ही स्थान पर, हर बार (या पास)) विफल रहता है

😉

kill -SIGWINCH ${pid} को किसी अन्य शेल इंस्टेंस से चलाया जाना चाहिए। जब बिल्ड हैंग होता है, तो एक और टर्मिनल विंडो / टैब खोलें, और वहां से कमांड चलाएं। यह थोड़ा स्निपेट काम करना चाहिए :

pid=$(ps -ef |grep -E 'node.*index\.js develop' |awk '{ print $2 }').
kill -SIGWINCH $pid

# Can also be run like this
kill -SIGWINCH $(ps -ef |grep -E 'node.*index\.js develop' |awk '{ print $2 }')

यदि त्रुटियाँ हैं, तो अलग से कमांड चलाने का प्रयास करें:

# Run first
ps -ef grep -E 'node.*index\.js develop'
# Example output
     UID     PID    PPID  TTY        STIME COMMAND
********   39928       1 cons0    06:47:38 /path/to/node /path/to/gatsby-cli/lib/index.js develop
# Second column is the pid you want
kill -SIGWINCH 39928

यदि आप परीक्षण चलाने के बाद खाली हाथ आते हैं, तो मुझे लगता है कि कोर डंप होना उपयोगी होगा, इसलिए हम स्टैक ट्रेस प्राप्त कर सकते हैं। लेकिन, एक समय में एक कदम।

@ Js-Brecht धीमी प्रतिक्रियाओं के लिए क्षमा करें ... यह वास्तव में सिर्फ एक पक्ष है जो मैं शाम को खाली समय में करता हूं।

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

यह स्रोत पर लटकता है और नोड्स को निम्न आउटपुट देता है:

< success onPreBootstrap - 0.102 s
⠋ source and transform nodes
break in node_modules/gatsby/dist/utils/api-runner-node.js:362
 360       return new Promise(resolve => {
 361         if (api === `sourceNodes`) {
>362           debugger
 363         }
 364         resolve(

< {
<   resolve: '/Users/erichowey/Coding/my-hello-world-starter/node_modules/gatsby/dist/internal-plugins/internal-data-bridge',
<   id: 'a5079d69-ba80-53dc-82f9-0f440bd5448c',
<   name: 'internal-data-bridge',
<   version: '1.0.0',
<   pluginOptions: { plugins: [] },
<   nodeAPIs: [ 'sourceNodes', 'onCreatePage' ],
<   browserAPIs: [],
<   ssrAPIs: []
< }
< ⠋ source and transform nodes
debug> undefined

< success source and transform nodes - 25.137 s

यहाँ मामला है कि मददगार है में gatsby जानकारी कमांड से एक डंप है:

  System:
    OS: macOS High Sierra 10.13.6
    CPU: (2) x64 Intel(R) Core(TM)2 Duo CPU     P8600  @ 2.40GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 12.9.1 - /usr/local/bin/node
    Yarn: 1.17.3 - /usr/local/bin/yarn
    npm: 6.10.3 - /usr/local/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Chrome: 76.0.3809.132
    Firefox: 67.0.2
    Safari: 13.0.1
  npmPackages:
    gatsby: ^2.15.22 => 2.15.22 
  npmGlobalPackages:
    gatsby-cli: 2.7.47

एक साइड नोट के रूप में - जब मैं आपके डीबग कमांड का उपयोग करता हूं तो यह स्रोत पर लटक जाता है और नोड्स को बदल देता है। जब मैं गैट्सबी के विकास का उपयोग करता हूं, तो यह ज्यादातर मेरे लिए अब CreatePagesStatefully पर लटका हुआ है। क्षमा करें, मुझे पता है कि यह वास्तव में अजीब है। सच कहूं तो मुझे यकीन नहीं है कि यह आपके काम के लायक है। टर्मिनल विंडो ट्रिक का आकार बदलना मेरे और अन्य लोगों के लिए हर समय काम करता है। यह एक हैकेड फिक्स है लेकिन यह बहुत से उपयोगकर्ताओं को प्रभावित नहीं कर रहा है अन्यथा मुद्दों की बाढ़ आ जाएगी।

यह यहाँ पर भी होने लगा है। _Resize टर्मिनल_ ट्रिक इसे हल करता है; बहुत अजीब!

+1 iTerm2 में काम नहीं करता है, लेकिन टर्मिनल में काम करता है

@ehowey बिल्ड के दौरान जो कुछ हो रहा है उसका अधिकांश भाग एक प्लगइन या किसी अन्य द्वारा परिभाषित किया गया है। निर्भरता के रूप में उनके साथ गैट्सबी जहाज; मुझे लगता है कि उन्हें कोर प्लगइन्स माना जा सकता है। गैट्सबी कोर एक एपीआई को उजागर करता है, जो प्लगइन्स में परिभाषित एंडपॉइंट्स की तलाश करता है, और उन्हें तर्कों की एक श्रृंखला देता है जिसमें कोर में परिभाषित कार्यों / वस्तुओं को शामिल किया जाता है। तो हाँ, जो हो रहा है वह कोर में हो सकता है, लेकिन इसे पहले एक प्लगइन को कॉल करना होगा, और उन प्लगइन्स को एपीआई के लिए एक विशिष्ट संदर्भ परिभाषित करना होगा। मैं उस संदर्भ को निर्धारित करने की कोशिश कर रहा हूं जो बिल्ड हैंगिंग में होता है, और यह भी सत्यापित करने की आवश्यकता है कि समस्या प्लगइन में ही नहीं हो रही है।

क्या मैं आपको इन पंक्तियों को बदलने के लिए प्राप्त कर सकता हूँ?

 360       return new Promise(resolve => {
-361         if (api === `sourceNodes`) {
-362           debugger
-363         }
+364         reporter.log(`${api}\t${plugin.name}`)
 365         resolve(

कृपया इसे चलाएं, और पूरे आउटपुट को कॉपी / पेस्ट करें (केवल .txt फ़ाइल के रूप में इसे अपनी प्रतिक्रिया में संलग्न कर सकते हैं)। यह काफी अधिक क्रियात्मक होगा, और बहुत सारी जानकारी संभवतः अनावश्यक होगी, लेकिन more♂♂।

आपके द्वारा ऐसा किए जाने के बाद, मैं यह देखना चाहूंगा कि क्या नोड के थ्रेड पूल में वृद्धि से फर्क पड़ता है। मैंने अन्य मुद्दों पर ध्यान दिया है जो समान या समान मुद्दों का उल्लेख करते हैं। ज्यादातर वे source and transform , और कुछ उस चरण के बारे में हमेशा के लिए बात करते हैं, या पूरी तरह से बंद कर देते हैं। इसलिए, मैं यह देखना चाहता हूं कि क्या यह फाइलसिस्टम io में किसी प्रकार का गतिरोध होता है ... एसिंक्रोनस फाइल सिस्टम एक्सेस को नोड द्वारा अलग-अलग थ्रेड में लोड किया जाता है, और, डिफ़ॉल्ट रूप से, नोड में केवल उपयोगकर्ताओं के लिए 4 थ्रेड्स का एक पूल होता है। यदि वे भरते हैं, और इसे किसी भी अधिक उतार-चढ़ाव करने की आवश्यकता होती है, तो कार्य मुख्य ईवेंट लूप में पंक्तिबद्ध हो जाएगा, एक थ्रेड का इंतजार करना होगा। यह, संभवतः, पूरे कार्यक्रम को एक ठहराव तक ला सकता है ... जब तक कि एक धागा उपलब्ध नहीं हो जाता। गैट्सबी फाइलसिस्टम पर एक कैश रखता है, इसलिए शायद कहीं एक टक्कर हो रही है, और अगर किसी तरह का गतिरोध हो रहा है, तो शायद थ्रेड्स आगे बढ़ने से पहले एक टाइमआउट / रुकावट की प्रतीक्षा कर रहे हैं, और यदि दर्जनों (या सैकड़ों, यहां तक) हैं फाइलसिस्टम एक्सेस ईवेंट्स के लिए, वे सभी एक ही टाइमआउट की प्रतीक्षा कर रहे थे, और सब कुछ ढेर हो गया। आप देख सकते हैं कि यह प्रतीक्षा समय को तेज़ी से बढ़ने का कारण बन सकता है।

पूल का आकार बढ़ाने से कुछ यातायात को कम करने में मदद मिल सकती है ... या, यह सिर्फ उसी तरह हो सकता है, जैसे कि अधिक थ्रेड्स के साथ।
निम्नलिखित कमांड आज़माएं:

UV_THREADPOOL_SIZE=10 gatsby develop

@ Js-Brecht थ्रेड पूल का आकार बदलने से बहुत फर्क नहीं पड़ा।
मुझे आपके द्वारा ऊपर उल्लिखित परिवर्तनों के साथ मानक gatsby develop कमांड से निम्न आउटपुट मिलता है। अभी भी बुनियादी हैलो-वर्ल्ड गैट्सबी स्टार्टर पर।

Erics-MBP:my-hello-world-starter erichowey$ gatsby develop
success open and validate gatsby-configs - 0.050 s
success load plugins - 0.119 s
success onPreInit - 0.036 s
success initialize cache - 0.050 s
success copy gatsby files - 0.281 s
onPreBootstrap  load-babel-config
success onPreBootstrap - 0.131 s
sourceNodes     internal-data-bridge
success source and transform nodes - 0.105 s
success Add explicit types - 0.030 s
success Add inferred types - 0.186 s
success Processing types - 0.145 s
success building schema - 0.535 s
success createPages - 0.032 s
createPagesStatefully   dev-404-page
onCreatePage    internal-data-bridge
onCreatePage    prod-404
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
onCreatePage    internal-data-bridge
onCreatePage    prod-404
success createPagesStatefully - 9.098 s
success onPreExtractQueries - 0.030 s
success update schema - 0.129 s
success extract queries from components - 0.336 s
success write out requires - 0.057 s
success write out redirect data - 0.044 s
success onPostBootstrap - 0.045 s
⠀
info bootstrap finished - 16.437 s
⠀
success run static queries - 0.038 s
success run page queries - 0.109 s — 2/2 27.65 queries/second
onCreateWebpackConfig   webpack-theme-component-shadowing
onCreateWebpackConfig   webpack-theme-component-shadowing
success start webpack server - 1.506 s — 1/1 4.63 pages/second
 DONE  Compiled successfully in 4699ms

यह एक उदाहरण है जहां यह createPagesStatefully पर लटका हुआ है। मुझे टर्मिनल विंडो को आकार देकर बिल्ड जारी रखने के लिए मिला। क्या internal-data-bridge कोई मौका है जो किसी तरह से अपराधी हो सकता है? यह दोनों आज्ञाओं की विशेषता थी जो आपने मुझे अब तक चलाने के लिए कहा है।

क्या आप दिखा सकते हैं कि यह किस लाइन पर लटका था?

createPagesStatefully dev-404-page

मुझे 100% यकीन नहीं है कि क्या dev-404-page हिस्सा अभी तक था, लेकिन यह createPagesStatefully के पहले उदाहरण पर लटका हुआ था

धन्यवाद। अगर आपको कोई आपत्ति नहीं है तो मैं अब कुछ और बदलावों की कोशिश करना चाहूंगा।

कृपया निम्न फ़ाइलों में संकेतित लाइनों को अपडेट करें:

node_modules/gatsby/dist/internal-plugins/internal-data-bridge/gatsby-node.js

- 114   chokidar.watch(pathToGatsbyConfig).on(`change`, () => {
+ 114   chokidar.watch(pathToGatsbyConfig, { useFsEvents: false }).on(`change`, () => {

node_modules/gatsby/dist/internal-plugins/dev-404-page/gatsby-node.js

- 30     chokidar.watch(source).on(`change`, () => copy()).on(`ready`, () => done());
+ 30     chokidar.watch(source, { useFsEvents: false }).on(`change`, () => copy()).on(`ready`, () => done());

node_modules/gatsby-page-utils/dist/watch-directory.js

  26               chokidar.watch(glob, {
  27                 cwd: path,
+ 28                 useFsEvents: false,
  29               }).on("add", function (path) {

node_modules/gatsby/dist/utils/get-static-dir.js

- 51   chokidar.watch(staticDir).on(`add`, path => {
+ 51   chokidar.watch(staticDir, { useFsEvents: false }).on(`add`, path => {

node_modules/gatsby/dist/query/query-watcher.js

- 237   watcher = chokidar.watch([slash(path.join(rootDir, `/src/**/*.{js,jsx,ts,tsx}`)), ...packagePaths]).on(`change`, path => {
+ 237   watcher = chokidar.watch([slash(path.join(rootDir, `/src/**/*.{js,jsx,ts,tsx}`)), ...packagePaths], { useFsEvents: false }).on(`change`, path => {

मुझे इसमें संदेह है कि chokidar गलती हो सकती है। इसे लगभग एक महीने पहले v3.x में अपग्रेड किया गया था, और ऐसा लगता है कि या तो उन्होंने fsevents का उपयोग करना शुरू कर दिया, या उन्होंने कुछ ऐसा किया जिससे fsevents संबंध में कुछ गलत व्यवहार हुआ। वे कुछ खुले मुद्दों के समान हैं जिनका हम यहाँ सामना कर रहे हैं, chokidar.watch() का उपयोग करते समय नोड लटका हुआ है। यह फिट लगता है, क्योंकि यह fsevents मैक प्रक्रिया होने के कारण MacOS के लिए स्थानीय है, और बिल्ड का उपयोग उन मॉड्यूल में विफल हो रहा है जहां इसका उपयोग किया जा रहा है, या फ़ाइल लिखने / प्रसंस्करण करने वाले मॉड्यूल में संभावना है कि देखा जा रहा है।

chokidar.watch() gatsby-source-filesystem में भी मौजूद है, और यह वह जगह है जहाँ यह आपके अन्य रेपो, @ehowey के साथ विफल हो रहा था; उल्लेख नहीं करने के लिए, gatsby-source-filesystem को आपके न्यूनतम रेपो में नहीं बुलाया जा रहा है, जो बताता है कि यह source and transform पिछले क्यों बना रहा है। वहाँ के उदाहरण हैं chokidar से पहले internal-data-bridge , लेकिन मैं स्थानों है कि निर्माण को प्रभावित करने वाले नहीं कर रहे हैं पर लगता है (उदाहरण के लिए query-watcher )। हालाँकि, मेरा मानना ​​है कि internal-data-bridge वह कारण है जो डिबगर चलाते समय लटका हुआ था; और सीधे चलने के दौरान, यह निर्माण के बाद के चरणों को प्रभावित करने की संभावना थी।

मुझे बताएं कि क्या यह मुद्दों को ठीक करता है, या यहां तक ​​कि अगर यह इसे आगे की तुलना में बनाता है। :आशा करना:

@ जेएस-ब्रेख्त आपको कहीं मिल रहे हैं! मैं gatsby develop शायद 15 बार भागा। यह कभी भी source and transform nodes या createPagesStatefully पर लटका नहीं था लेकिन यह start webpack server पर, शायद 2/10 बार लटका हुआ लगता था। मैं इसे रिसाइकिलिंग टर्मिनल चाल के साथ-साथ टक्कर दे सकता था। कोई भी मौका जो आपने चोकीदार / छद्म का उदाहरण याद किया जो start webpack server से संबंधित होगा?

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

यह सुनने में वाकई अच्छा है। मैंने उद्देश्य पर, चोकीदार का एक उदाहरण छोड़ दिया, और यह बूटस्ट्रैप को समाप्त करने और सर्वर को शुरू करने के बाद सही है। यह node_modules/gatsby/dist/commands/develop.js startServer() फ़ंक्शन के अंत में

आप ऐसा करके सटीक रेखा पा सकते हैं:

cat node_modules/gatsby/dist/commands/develop.js |grep -n ‘chokidar’

मुझे पूरा यकीन था कि अगर यह बूटस्ट्रैप तय करता है, तो यह अभी भी सर्वर पर लटका रहेगा। मुझे पता है कि अगर बदल रहा है तो यह मज़बूती से चलता है, और मैं एक पीआर प्रस्तुत करूँगा और लोगों को बताने का ध्यान रखूँगा।

मैं वास्तव में आश्चर्यचकित नहीं हूं कि यह तेजी से चलता है। एक नंगे पैर की परियोजना पर निर्माण आमतौर पर मुझे शायद एक सेकंड लगता है, और मैंने आपके डिबग आउटपुट में कुछ चरणों के लिए कुछ पागल लंबे रनटाइम्स देखे। fsevents चीजों को गति देने के लिए माना जाता है, और सीपीयू से बहुत अधिक भार उठाते हैं, लेकिन वहाँ कुछ अजीब चल रहा है जो इसके बजाय अटक जाता है।

@ Js-Brecht मेरी टोपी आपसे दूर जाती है। मुझे नहीं पता है कि आपने उस खरगोश को एक टोपी से कैसे निकाला और बग ने इस तरह के एक अजीब को दूर से तय किया लेकिन अच्छा काम किया! मैं develop.js में परिवर्तन करने के लिए पर्याप्त रूप से प्रतीक्षा करूंगा क्योंकि मैं गलत चीज़ को बदलना नहीं चाहता, लेकिन मुझे संदेह है कि इसे ठीक कर देगा क्योंकि यह सर्वर को एक युगल शुरू करने पर बहुत अंतिम चरण में लटका हुआ था। समय का।

ये रहा अंतर:

node_modules/gatsby/dist/commands/develop.js

- 337   chokidar.watch(watchGlobs).on(`change`, async () => {
+ 337   chokidar.watch(watchGlobs, { useFsEvents: false }).on(`change`, async () => {

मैं वास्तव में आपकी मदद की सराहना करता हूं, इन सभी परीक्षणों को चला रहा हूं। यह एक मुश्किल रहा है, लेकिन यह MacOS के आंतरिक क्षेत्रों में खुदाई करने का एक अवसर रहा है, और मुझे हमेशा नई चीजें सीखने में मज़ा आता है:

कृपया मुझे बतायेँ कि यह कैसा चलेगा; पूरी तरह से अभी तक जंगल से बाहर नहीं: पसीना_ मुस्कुराहट:।

काम करता है! मैंने सिर्फ gatsby develop 10+ बार भागा और यह त्रुटिपूर्ण काम किया। इसे देखने में आपकी मदद के लिए धन्यवाद। उम्मीद है कि यह हमारे अनुभव करने वाले समूह के लिए सुधार के लिए बनाता है!

महान! यहाँ थोड़ी देर में, जब मुझे कुछ मिनट मिल गए हैं, तो मैं एक साथ पीआर रखूंगा। एक बार यह हो जाने के बाद, आप मेरे रेपो के साथ gatsby-dev-cli का उपयोग करने में सक्षम होंगे ताकि आपके पास काम करने का माहौल बना रहे जब तक कि एक पैच प्रकाशित न हो जाए (यदि आप gatsby-dev-cli परिचित नहीं हैं, तो मैं कर सकता हूँ मदद)। मैं आपको वैसे भी परिवर्तनों का परीक्षण करने के लिए भर्ती करने का प्रयास कर सकता हूं, क्योंकि मेरे पास सही ओएस नहीं है ... इस मुद्दे पर अनुभव करने वाले इस धागे पर हर किसी के लिए समान है।

जब यह हो जाएगा तो मैं यहाँ वापस पोस्ट करूँगा।

मुझे एक और अलग मुद्दा मिला है जो इस लक्षण का भी कारण बनता है - https://github.com/gatsbyjs/gatsby/issues/17935

अगर कोई भी लोकीज का उपयोग कर रहा है और टर्मिनल का आकार बदल रहा है, तो यह ठीक नहीं है, यह काफी संभावना है कि मुझे जो मुद्दा मिला है।

हे लोग, @ehowey , कृपया PR # 17938 देखें। यदि कोई भी परीक्षण करने के लिए तैयार है, तो कृपया पीआर पर एक लाइन छोड़ें।

आप मेरे रेपो को सहला सकते हैं, और इसे gatsby-dev-cli का उपयोग करके अपनी साइट में gatsby स्रोत के रूप में उपयोग कर सकते हैं। सबसे पहले, आपको gatsby-dev-cli

# Use your package manager of choice, and install globally
npm install -g gatsby-dev-cli

फिर, बस रेपो को क्लोन करें, और इसे बूटस्ट्रैप करें।

git clone --single-branch -b macos-fsevents-fix https://github.com/Js-Brecht/gatsby
cd gatsby
yarn bootstrap
# Set the target repo path for gatsby-dev
gatsby-dev -p "${PWD}"

फिर उस साइट पर जाएं जहां आप रेपो का उपयोग करना चाहते हैं, और gatsby-dev चलाएं

# Disable file watching, unless you intend on making changes to the gatsby repo
gatsby-dev --scan-once

मेरे मामले में, मैं OSX और IntelliJ का उपयोग कर रहा हूं, मुझे यह करना होगा:

• IntelliJ में प्रोजेक्ट बंद करें
• पुनः प्रयास करें ( npm start )
• और इंटेलीज में परियोजना को फिर से खोलना
  मुझे लगता है कि समस्या IntelliJ अनुक्रमण फ़ाइलों के साथ संबंधित है

@steinitz , @rheinardkorf , @ hbthen3rd , @sharvit , @JaKXz , @emilyaviva , @MaximeHeckel

आप में से कोई भी # 17938 परीक्षण के लिए तैयार है?

जब मैं घर पर होता हूं तो मुझे आज रात को देख लेना चाहिए। इस पर आपके सभी काम के लिए धन्यवाद!
1 अक्टूबर, 2019 को 10:23 AM -0600, जेरेमी अलब्राइट नोटिफिकेशन @github.com, ने लिखा:

@steinitz , @rheinardkorf , @ hbthen3rd , @sharvit , @JaKXz , @emilyaviva , @MaximeHeckel
आप में से कोई भी # 17938 परीक्षण के लिए तैयार है?
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

इसके लिए फिक्स पर कोई अपडेट? यह स्रोत पर ठंड है और मेरे और मेरे दोस्त के लिए नोड्स को बदलने के बाद [Firebase Source] Fetching data for ... की कोशिश की

दुर्भाग्य से टर्मिनल का आकार बदलना हमारे लिए ठीक नहीं लगता

@ rishabhaggarwal2 एक ऐसा ही मुद्दा है जो लगता है कि यह वही हो सकता है जो आप अनुभव कर रहे हैं, जहां यह ऑनलाइन स्रोत से डेटा प्राप्त करते समय लटका होगा। क्या आप GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop का उपयोग करने का प्रयास कर सकते हैं?

यह देखकर भी। लुमेन स्टार्टअप पर स्थानीय रूप से gatsby develop नहीं चला सकते। createPageStatefully या source and transform nodes लटकाए रखता है

macOS Mojave 10.14.6
Gatsby CLI version 2.7.7
Gatsby version 2.14.1

किसी और को इस मुद्दे को खोजने के लिए, प्रयास करें

CHOKIDAR_USEPOLLING=1 gatsby develop

MacOS पर fsevents को अक्षम करना चाहिए, जो एक विश्वसनीय समाधान लगता है।

@ Js-Brecht मैं इस बात की पुष्टि करता हूं कि इसे यहां बताए गए अन्य वर्कआर्ड से अधिक स्थायी रूप से ठीक करना प्रतीत होता है। साझा करने के लिए धन्यवाद।

@steinitz आप स्थायी रूप से "अधिक" कहते हैं। क्या आपके कहने का मतलब यह है कि यह तब भी होता है जब आप उस स्विच का उपयोग करते हैं?

@ जेएस-ब्रेख्त नो, सॉरी टू बी अस्पष्ट।

मैं इस तथ्य से अवगत था कि मेरे स्वयं सहित अन्य वर्कअराउंड कुछ समय के लिए काम करने लगे, लेकिन समस्या वापस आ गई। आपके समाधान के साथ मैंने इसे बदलकर और फिर से चल रहे गैट्सबी (आपके संवर्द्धन के साथ) विकसित करके उकसाया, लेकिन निर्माण कार्य जारी है।

उस ने कहा, यह एक रोलरकोस्टर की सवारी है, इसलिए मैं भावनात्मक रूप से तैयार रहता हूं: मुस्कुराओ: समस्या को वापस करने के लिए।

स्पष्ट होना: अब तक, इतना अच्छा।

ओह, अद्यतन: मैंने इसे पोस्ट करने से पहले एक अंतिम परीक्षण के लिए WebStorm को फिर से लॉन्च किया और अब इसे WebStorm टर्मिनल में source and transform nodes पर लटका दिया गया है।

किसी और को इस मुद्दे को खोजने के लिए, प्रयास करें

CHOKIDAR_USEPOLLING=1 gatsby develop

MacOS पर fsevents को अक्षम करना चाहिए, जो एक विश्वसनीय समाधान लगता है।

@ Js-Brecht मैं ubutu 18.04 का उपयोग कर रहा हूं और मैं कभी-कभी उसी समस्या में चल रहा हूं। क्या मेरे OS के लिए कोई सुझाव है? क्या आप इस समस्या के संभावित कारणों के बारे में कुछ विवरण देंगे?

इसे @ Js-Brecht और @RomanHotsiy के मेहनती काम की बदौलत हल किया गया है। यह fsevents में एक अपस्ट्रीम मुद्दा था, इससे परे कि मैं अपने दम पर क्या कर सकता था, और इन परिवर्तनों को लागू होने के बाद भविष्य के अपडेट में तय किया जाना चाहिए और fsevents से gatsby में ही माइग्रेट करना चाहिए। अभी के लिए एक विश्वसनीय समाधान टर्मिनल विंडो का आकार बदलना है, अपने रेपो में इसे ठीक करने का एक तरीका है जो यहां चर्चा की गई है: https://github.com/gatsbyjs/gatsby/pull/17938 हालाँकि आपको इसे फिर से करना होगा। अपने नोड_मॉडल्स फ़ोल्डर में किसी भी बदलाव के बाद ठीक करें और हो सकता है कि आप अपने पैकेज संस्करणों को कितनी बार अपडेट करें, इसके आधार पर यह काम के लायक न हो।

मैं इस मुद्दे को तब तक खुला छोड़ दूंगा जब तक कि फिक्स डाउनस्ट्रीम में खुद ही नहीं चला जाता।

@ Boty22 उबंटू fsevents उपयोग नहीं करता है, इसलिए यह शायद कुछ अलग है। दूरस्थ स्थान से डेटा प्राप्त करते समय कुछ मुद्दों का सामना किया गया है; समसामयिक मुद्दों को ठीक करने के कुछ विवरणों के लिए # 6654 और # 17940 देखें।

त्वरित प्रश्न: क्या आपके टर्मिनल का आकार बदलने में मदद करता है? यदि ऐसा है, तो यह इस मुद्दे के समान _something_ हो सकता है।

@ जेएस-ब्रेख्त टर्मिनल का आकार उबंटू के लिए मदद नहीं करता है। मैं प्लगइन गैट्सबी-सोर्स-एयरटेबल बीटीडब्ल्यू का उपयोग करके एक एयरटेबल टेबल से डेटा पुनर्प्राप्त कर रहा हूं

यह समस्या हो सकती है। इस टिप्पणी को देखें । यदि वह काम नहीं करता है, तो नया टिकट खोलने के लिए बेहतर हो सकता है

@steinitz क्षमा करें, मैं आपकी टिप्पणी से चूक गया। क्या आप # 17938 में बताए गए फिक्स को आजमा सकते हैं? अधिक विशेष रूप से, यहां और यहां । यदि यह काम नहीं करता है, तो संभवतः आपके मामले में अधिक चल रहा है।

उल्लेख के बाद से CHOKIDAR_USEPOLLING=1 gatsby develop साथ कोई समस्या नहीं थी।

@ Js-Brecht वर्कअराउंड के लिए धन्यवाद

मैं इसे 2.15.28 के साथ देख रहा हूं जब मैं गैट्सबाय का निर्माण करता हूं। क्या मुझे दूसरे टर्मिनल में गैट्सबी विकसित करने से रोकने की आवश्यकता है? यह रुक-रुक कर हो रहा है

चल रहे देव सर्वर के बिना फिर से हुआ। मुझे ब्लॉग ट्यूटोरियल का अनुसरण करने से एक सरल ब्लॉग मिल गया है।

यह लगभग हर दूसरे रन के लिए लगता है। मैं एक मैक btw पर हूँ

@canvaspixels आपके निर्माण को बदल रहा है? यदि हां, तो कृपया इसे आज़माएं और हमें बताएं कि क्या इससे https://github.com/gatsbyjs/gatsby/pull/17938#issuecomment -540661991 मदद मिली

@RomanHotsiy कि वास्तव में यह तरह! धन्यवाद!

हे सब लोग, fsevents का पैच संस्करण प्रकाशित किया गया है। आपको बस अपने यार्न.लॉक फ़ाइल को हटाने में सक्षम होना चाहिए, और यार्न को फिर से चलाना चाहिए। आपकी प्रत्येक निर्भरता को स्वचालित रूप से [email protected] लेना चाहिए, जिससे समस्या का समाधान होना चाहिए।

सावधान रहें - अपने पूरे yarn.lock फ़ाइल को हटाने से अन्य पैकेज भी अपग्रेड हो सकते हैं।

आप उपयोग कर रहे हैं एक और अधिक सटीक विकल्प yarn बस से संबंधित लाइनों को हटाने के लिए है fsevents में yarn.lock और फिर से चलाने के yarn । इससे केवल प्रभावित पैकेज अपग्रेड किया जाएगा। इसलिए उदाहरण के लिए, मैंने निम्नलिखित पंक्तियों को हटा दिया:

- 
- fsevents@^2.0.6:
-   version "2.0.7"
-   resolved "https://registry.yarnpkg.com/fsevents/-/fsevents-2.0.7.tgz#382c9b443c6cbac4c57187cdda23aa3bf1ccfc2a"
-   integrity sha512-a7YT0SV3RB+DjYcppwVDLtn13UQnmg0SWZS7ezZD0UjnLwXmy8Zm21GMVGLaFGimIqcvyMQaOJBrop8MyOp1kQ==

ऐसा करने का दूसरा तरीका यार्न के resolutions फ़ीचर (https://yarnpkg.com/lang/en/docs/selective-version-resolutions/) का उपयोग करना है। निम्नलिखित को अपने package.json जोड़कर और फिर yarn चलाकर, यह सकर्मक निर्भरता को भी उन्नत करेगा और आपके yarn.lock फ़ाइल को अद्यतन करेगा:

  "resolutions": {
    "fsevents": "^2.1.1"
  }

आपके द्वारा ऐसा करने के बाद और आपका लॉकफ़ाइल अपडेट हो जाने पर, आप resolutions प्रॉपर्टी को package.json फिर से निकाल सकते हैं।

संपादित करें: पिछले, निर्देशों का गलत संस्करण निकाला गया।

आप yarn upgrade chokidar@latest भी चला सकते हैं। कि बिना किसी और चीज को छुए, फेजवेट के सही संस्करण के साथ लॉक फाइल को फिर से बनाना चाहिए

अरे रुको। केवल तभी यदि आपके पास प्रत्यक्ष निर्भरता ch के रूप में चोकीदार है। भूल गया। @karlhorky सही है

मैं npm का उपयोग कर रहा हूं। हटाया जा रहा है node_modules , चल npm i --save [email protected] और फिर npm i मेरे लिए चाल किया था। स्टार्टअप के लिए 19s लिया और मैं एक आधार के रूप में gatsby-lumen-starter का उपयोग कर रहा हूं।

- संपादित करें:

मैंने वास्तव में जो काम किया था, उसे नेटलीज़ पर धकेल दिया और fsevents ( error [email protected]: The platform 'linux' is incompatible with this module ) होने के कारण यह पूरी तरह से असमर्थ हो गया।

मैंने yarn स्विच किया और एक ही मुद्दा था इसलिए मैंने यार्न को fsevents पूरी तरह से हटा दिया, और अब स्थानीय और netlify दोनों काम कर रहे हैं ...

एक ही मुद्दा मिला और कारण को ट्रैक नहीं कर सका। यह मेरे लिए मैक और पीसी दोनों पर होता है। इसे इंटरनेट स्पीड से संबंधित करने का प्रयास कर सकते हैं, हालांकि मेरे साथ भी ऐसा हुआ जब मैं हाई स्पीड नेटवर्क से जुड़ा था। मेरे लिए अभी जो काम करना प्रतीत हो रहा है, वह यह है कि मुझे अपने एनवी में जोड़ना है

GATSBY_CONCURRENT_DOWNLOAD=5

और --v8-pool-size=128 का उपयोग करके चल रहा है

मेरे मामले में यह लगता है कि मेरा फ़ायरवॉल ओएक्सएक्स पर शीघ्र है। अगर मैं बाहर से आने वाले कनेक्शन को अनुमति देने या अस्वीकार करने के लिए पर्याप्त तेज हूं, तो यह त्रुटिपूर्ण रूप से सफल होगा। समस्या यह है कि त्वरित संवाद एक दूसरे विभाजन के लिए पॉप अप करता है और गैट्सबी के रूप में जारी रहता है और फिर ऊपर उल्लिखित कई चरणों में से एक पर लटका हुआ विफल रहता है।
विकल्प:

• फ़ायरवॉल अक्षम करें (ऐसा नहीं होने पर)
• श्वेतसूची गैट्सबी (परियोजनाओं और उन्नयन के अनुरूप नहीं)
• जब तक उपयोगकर्ता विकल्प का चयन नहीं करता है, तब तक संकेत पर रुकने का एक तरीका खोजें
• डिफ़ॉल्ट लोकलहोस्ट के लिए बाइंड एड्रेस (आने वाले कनेक्शन को स्वीकार करने के लिए संकेत की आवश्यकता नहीं होनी चाहिए)।

@thomasthep देव सर्वर के लिए डिफ़ॉल्ट बाइंड का पता पहले से ही लोकलहोस्ट है। यह बाहरी कनेक्शन के लिए भी नहीं सुनता है जब तक कि आप इसे अपने आउट-फेसिंग आईपी पते (या 0.0.0.0) का उपयोग करने के लिए नहीं कहते हैं। और फिर भी, यह बूट सर्वर को तब तक शुरू नहीं करता है जब तक कि बूटस्ट्रैप / बिल्ड नहीं किया जाता है। यदि यह बूटस्ट्रैप है, जो फ़ायरवॉल प्रॉम्प्ट का कारण बन रहा है, तो यह आपके द्वारा उपयोग किए जा रहे प्लगइन्स के साथ अधिक करना होगा, क्योंकि गैट्सबी अपनी डिफ़ॉल्ट स्थिति में इंटरनेट तक नहीं पहुंचता है।

आम तौर पर बोलने वाले "बाहर से आने वाले" कोई भी कनेक्शन नहीं होना चाहिए; यहां तक ​​कि जब कोई प्लगइन किसी बाहरी स्रोत से जानकारी एकत्र कर रहा होता है, तो कनेक्शन आपके स्थानीय होस्ट से उत्पन्न होता है, बाहरी स्रोत से नहीं, और यह आमतौर पर मेरे फायरवॉल द्वारा "फ़ायरवॉल कनेक्शन" के रूप में स्वीकार किया जाता है, क्योंकि अधिकांश फायरवॉल कॉन्फ़िगर किए गए हैं किसी भी आउटगोइंग कनेक्शन को स्वीकार करने के लिए।

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

वास्तव में समझने के लिए अधिक जानकारी की आवश्यकता होगी कि आपके साथ ऐसा क्यों हो रहा है। हालांकि, नया टिकट खोलना अधिक प्रभावी होगा। इस समस्या के कारण MacOS पर fsevents किया जाना था, और इसे संबोधित किया गया है, इसीलिए इसे अब बंद कर दिया गया है। fsevents से संबंधित कुछ भी वास्तव में अपना स्वयं का मुद्दा नहीं होना चाहिए, जिस पर वह ध्यान देने योग्य है।

रिकॉर्ड के लिए यह तब भी हो सकता है यदि आपके पास आपका ग्राफक्यूएल सर्वर डिबग मोड में चल रहा है और यह ब्रेकपॉइंट पर बंद हो गया है।

रिकॉर्ड के लिए: यह मेरे साथ तब होने लगा जब मैंने gatsby-source-s3-image जोड़ा और s3 बाल्टी 100 से अधिक छवियों तक पहुँच गई। यह source and transform nodes मंच पर सभी 145 छवियों के माध्यम से जाता है और फिर हमेशा के लिए वहीं लटक जाता है। यह अभी भी हो रहा है, मैंने ऊपर दिए गए सुधारों की कोशिश की है। सौभाग्य से, यह 5-6 प्रयासों के बाद काम करता है इसलिए मैं अवरुद्ध नहीं हूं।

अजीब तरह से टर्मिनल विंडो का आकार बदलना मेरे लिए काम कर गया

मेरे लिए, यहाँ वर्णित समवर्ती डाउनलोड को सीमित करने से मदद मिलती है।

मैंने अपनी .env फ़ाइल में निम्न पंक्ति जोड़ी है। डिफ़ॉल्ट 200 है।
GATSBY_CONCURRENT_DOWNLOAD=50

यकीन नहीं होता कि यह आपकी समस्या को हल करता है लेकिन शायद यह किसी की मदद करता है :)

@ rishabhaggarwal2 एक ऐसा ही मुद्दा है जो लगता है कि यह वही हो सकता है जो आप अनुभव कर रहे हैं, जहां यह ऑनलाइन स्रोत से डेटा प्राप्त करते समय लटका होगा। क्या आप GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop का उपयोग करने का प्रयास कर सकते हैं?

धन्यवाद, इसने मेरे लिए इसे ठीक कर दिया। चूंकि मैं थर्ड पार्टी वेबसाइट से एक टन सामग्री खींच रहा था, इसलिए यह सामग्री डाउनलोड करने पर लटका रहा। (97% - अब तक बंद हुआ)