Gatsby: [fsevents bug] عالق في "المصدر وتحويل العقد" / "createPagesStatefully" على نظام MacOS

تم التحديث - لقد اختبرت التعليق على ملف gatsby-node.js وتطور البناء في مناسبة واحدة ، ولكن بعد ذلك حاولت مرة أخرى وفعلت ذلك وعلق في نفس المكان مرة أخرى.

هل هناك أي احتمال أن يكون هذا بسبب جهاز الكمبيوتر القديم الخاص بي ، 2010 Macbook Pro (تمت ترقيته إلى 8 جيجابايت من ذاكرة الوصول العشوائي و SSD) ، لم يوقفني بعد ولكني أعرف أن أيامه محدودة. هذه هواية بالنسبة لي ولدي أطفال صغار ، لذا لم تكن الدولارات موجودة لإنفاقها على جهاز كمبيوتر جديد لأن هذا الجهاز يعمل بشكل جيد مع Ram و SSD المحدثين.

لقد حاولت العودة مرة أخرى إلى الإصدار 2.13.52 من برنامج gatsby والذي كان الإصدار الأخير الذي كنت مستقرًا عليه ، وقد حاولت أيضًا العودة للرد 16.8.6.

من المثير للاهتمام أنني نجحت في بناء مرة واحدة عندما عادت إلى رد الفعل على 16.8.6 ولكن بعد تلك المرة الأولى ، أغلقت المكالمة في نفس المكان وهو سلوك غريب حقًا بالنسبة لي.

يمكنني أيضًا ، نادرًا ، بدون سبب أن أفهم أن أجعلها تبني بشكل جيد. لا يبدو أن هناك قافية أو سببًا لحدوث ذلك. لقد أمضيت بضع ساعات في البحث عن أنماط أو أخطاء قد تسبب ذلك ولكني لم أجد شيئًا. لقد راجعت https://github.com/gatsbyjs/gatsby/issues/6654 وجربت بعض العناصر هناك دون جدوى.

لقد حصل لي هذا أحد أكثر الأخطاء التي واجهتها على الإطلاق لأن السلوك يبدو أنه يتغير دون أن يكون هناك تغيير واضح في الكود. في بعض الحالات يتوقف البناء عند المصدر ويقوم بتحويل العقد (60٪ من الوقت) ، وفي بعض الحالات يتم تعليقه عند Create Pages Statefully (20٪) ، وفي بعض الحالات يتم الإنشاء بنجاح (20٪). لقد جعلته يعرض كل هذه السلوكيات الثلاثة دون تغيير سطر من التعليمات البرمجية.

لقد قمت بتكرار هذا السلوك في مدونة gatsby-starter-blog أيضًا ، وهو أمر غريب حقًا. مرة أخرى ، يجعلني أعتقد أن هذه مشكلة من جانبي محليًا. ومن المثير للاهتمام أنها معلقة فقط عند createPagesStatefully .

لقد بدأت الآن في التفكير في أن لها علاقة بمكتبة تم تحديثها بواسطة البيرة المنزلية تلقائيًا - أي مكتبة ليس لدي أدنى فكرة عنها ولكنها الشيء الوحيد الذي يمكنني التفكير فيه والذي لم أختبره.

فيما يلي قائمة بالأشياء التي جربتها حتى الآن:

• تغيير إصدارات العقدة ، جربت 12 و 10 و 8

• بالعودة إلى نقطة سابقة في سجل الالتزام الخاص بي والتي كانت تعمل - ما زالت تفشل الآن.

• التعليق على المكونات الإضافية ومناطق ملف gatsby-config

• التعليق على محتويات gatsby-node.js الخاصة بي

• اختبرها مرة أخرى على Netlify ، ما زالت مبنية بنجاح ، وهو ما يجعلني أعتقد أنه يجب أن يكون لها علاقة بجهاز الكمبيوتر الخاص بي.

• حذف 4 صفحات من دليل src / pages ووضع ملف index.mdx أساسي جدًا

• حذف جميع node_module وقفل الملفات ، وإعادة التثبيت

• إعادة تشغيل الكمبيوتر

• إنشاء مساحة عمل جديدة من الغزل مع نسخ جديدة للموضوع / بداية من Github.

• اختبار gatsby-starter-blog ، سلوك مشابه لكنه معلق عند createPagesStatefully

مرحبا،

لا يمكنني فعل الكثير ولكن أؤكد أنني أرى هذه المشكلة في عدد من مقبلات غاتسبي. وكما أشرت ، فإنه في بعض الأحيان يقرر فقط بناء أو إيقاف البناء ، والتعليق إما عند "عقد المصدر وتحويله" أو إنشاء صفحات الحالة.

محبط للغاية ويؤدي إلى محاولة أكثر المحاولات شنيعة لإصلاحه.

لم أشهد هذه المشكلة ولكن هذا يبدو محرجًا وأود حقًا معرفة سبب هذا السلوك من جانبك.

تجهيز
يجب أن تحاول استخدام مصحح أخطاء العقدة للوصول إلى جذر المشكلة. ستبدو المهمة في الحزمة الخاصة بك. json هكذا. إذا كنت تستخدم VSCode ، فيمكنك تمكين "Auto Attach" لاستخدام مصحح الأخطاء الداخلي مع هذه المهمة (تأكد من استخدام الجهاز الداخلي لهذا الغرض)

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

سيعمل التصحيح بالطبع مع أي IDE ، فقط تأكد من إرفاق مصحح الأخطاء بشكل صحيح.

1. البديل: الحد الأدنى من الاستنساخ
لقد ذكرت createPagesStatefully كمصدر للمشكلة. إذا كنت متأكدًا من أن هذا هو مصدر المشكلة ، فربما يمكنك إنشاء مشروع صغير جدًا لإعادة إنتاجه. تخلص من جميع المبتدئين ، فقط استخدم gatsby مباشرة واستخدم createPagesStatefully حتى gatsby-node.js مع بعض الأمثلة التي تحاكي الأشياء التي يقوم بها المبتدئين. ثم ابدأ gatsby وقم بتصحيحه من خلال فحص العقدة.

بهذه الطريقة قد تجد مكان تعليقها.

2. بديل: داخل مشروعك / بادئ الأمر
يمكنك بالطبع محاولة تصحيح المشكلة داخل مشروعك بنفس التقنية. ولكن ربما لديك مشاكل متعددة تتراكم وتشوش وجهة نظرك حول سبب المشاكل. لذلك سأحاول دائمًا الحصول على الحد الأدنى من التكاثر قبل البدء في التصحيح.

حظا طيبا وفقك الله.

لذلك ... واجهت سلوكًا غريبًا مع ملفات القفل. ربما يمكن لشخص يعرف المزيد أن يوجهني في الاتجاه الصحيح. في عملية محاولة الوصول إلى الحد الأدنى من بناء العمل ، جردت أساسًا إلى تثبيت Gatsby "مرحبًا بالعالم" وما زال لا يعمل وهو أمر غريب حقًا.

حيث أصبح الأمر أكثر غرابة هو أن عالم gatsby-starter-hello الفعلي يعمل ويبني بشكل جيد على جهاز الكمبيوتر الخاص بي. ولكن ... إذا قمت بحذف ملف القفل وحصلت على خيوط لإعادة إنشاء ملف قفل جديد ، فسيبدأ البناء بالفشل ، ويتدلى من المصدر ويحول العقد. يمكنني الحصول على الحد الأدنى من التنفيذ والبناء إذا قمت بنسخ ملف القفل من "hello-world" واستخدمت هذا. لذا فإن نظريتي الحالية هي أن هناك نوعًا من مشكلة الإصدار في ملفات القفل الخاصة بي والتي تسبب هذه المشكلة ولكني عالق هنا.

لقد حذفت أيضًا جميع تثبيتات البيرة المنزلية وأعدت تثبيت العقدة والغزل والبوابة وما إلى ذلك فقط للتأكد من أنها ليست نوعًا من الأعمال المضحكة هناك.

شكرًا ehowey على رفع هذا .... اعتقدت أنه أنا فقط لأنه متقطع تمامًا (ولكنه يحدث أكثر من 50 ٪ من الوقت). فعلت نفس الشيء الذي حاولت تصحيحه الموقف. عندما أعلق على ⠙ source and transform nodes فهذا يعني عادة أن أضطر إلى قتل الجهاز الطرفي

إذا وجدت شيئًا سأخبرك به. وسأشاهد هذا الخيط أيضًا.

georgiee - شكرًا لك على معلومات البحث. سأرى ما إذا كان بإمكاني الحصول على تصحيح أخطاء العقدة بالعمل مع WebStorm.

أنا أيضا أحب فكرتك عن الحد الأدنى من التكاثر. لكن هذا سيستغرق بعض الوقت بينما أفهم غاتسبي بشكل أعمق قليلاً.

حاليًا يتم تعليقه على "عقد المصدر وتحويله". نادرًا ما يؤدي ذلك إلى إنشاء صفحات بحالة وتعليق هناك. وإلا فإنه يبني بشكل طبيعي.

أواجه حاليًا نفس المشكلة بعد إجراء "ترقية الغزل" لإصلاح تبعية ضعيفة. هذا هو إعدادي:

النظام:
نظام التشغيل: macOS 10.15
وحدة المعالجة المركزية: (4) x64 Intel (R) Core (TM) i7-7567U CPU @ 3.50 جيجاهرتز
شل: 5.7.1 - / bin / zsh
الثنائيات:
العقدة: 12.8.1 - / usr / local / bin / node
الغزل: 1.17.3 - / usr / local / bin / yarn
npm: 6.10.3 - / usr / local / bin / npm
اللغات:
بايثون: 2.7.16 - / usr / local / bin / python
المتصفحات:
الكروم: 76.0.3809.132
فايرفوكس: 68.0.2
سفاري: 13.0
الحزم:
غاتسبي: ^ 2.13.42 => 2.14.7
gatsby-background-image: ^ 0.8.3 => 0.8.6
صورة gatsby: ^ 2.2.7 => 2.2.15
gatsby-plugin-manifest: ^ 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-plugin-offline: ^ 2.2.5 => 2.2.10
gatsby-plugin-response-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-plugin: ^ 2.3.2 => 2.3.5
gatsby-plugin-webfonts: ^ 1.1.0 => 1.1.0
gatsby-note-images: ^ 3.1.10 => 3.1.19
جاتسبي - ملاحظة - نسبي - صور - v2: ^ 0.1.5 => 0.1.5
gatsby-NOTE-responsive-iframe: ^ 2.2.5 => 2.2.10
نظام ملفات جاتسبي المصدر: ^ 2.1.6 => 2.1.18
ملاحظة غاتسبي محول: ^ 2.6.12 => 2.6.19
محول غاتسبي شارب: ^ 2.2.5 => 2.2.12

أواجه حاليًا نفس المشكلة بعد إجراء "ترقية الغزل" لإصلاح تبعية ضعيفة. هذا هو إعدادي:

تحديث: تمكنت من إصلاح الأشياء من خلال استعادة ملف "yarn.lock" القديم.

@ hbthen3rd

تحديث: تمكنت من إصلاح الأشياء من خلال استعادة ملف "yarn.lock" القديم.

تجربتي هي أن المشكلة يمكن أن تختفي دون سبب واضح فقط للعودة لاحقًا. قد تجد المشكلة تعود على الرغم من استعادة yarn.lock. ابقنا على اطلاع.

هنا هو الحد الأدنى من التكاثر باستخدام gatsby-starter-hello-world:

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

ملف القفل الحالي المضمن في الريبو هو الملف الذي فشل بالنسبة لي. لقد قمت أيضًا بتضمين نسخ في الريبو yarn-working.lock و yarn-notworking.lock . نأمل أن يسهل ذلك على شخص ما استكشاف الأخطاء وإصلاحها.

بيئتي الحالية:

النظام:
نظام التشغيل: macOS High Sierra 10.13.6
وحدة المعالجة المركزية: (2) x64 Intel (R) Core (TM) 2 Duo CPU P8600 @ 2.40 جيجاهرتز
شل: 3.2.57 - / بن / باش
الثنائيات:
العقدة: 10.16.3 - / usr / local / bin / node
الغزل: 1.17.3 - / usr / local / bin / yarn
npm: 6.10.3 - / usr / local / bin / npm
اللغات:
بايثون: 2.7.10 - / usr / bin / python
المتصفحات:
الكروم: 76.0.3809.132
Firefox: 67.0.2
سفاري: 12.1.2
الحزم:
غاتسبي: ^ 2.13.73 => 2.15.0
الحزم:
غاتسبي كلي: 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 أي حظ في

تضمين التغريدة

كما قد تتخيل ، نظرًا لطبيعة هذه المشكلة مرة أخرى ، فأنا متردد في الإبلاغ عنها. إليك مثال على ذلك:

بعد حذف دليل node_modules ، حذف yarn.lock ثم التشغيل
npx yarn-upgrade-all
و
yarn install
كل شيء بخير.

ثم ، الآن فقط ، ردا على رسالتك ، حاولت
yarn start
النتيجة: توقف مرة أخرى عند
source and transform nodes

أفترض أن هناك شيئين منطقيين يجب القيام بهما:

1. اتبع نصيحةgeorgiee للحصول على تصحيح أخطاء Webstorm
   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 لذلك أعتقد أنها مشكلة تبعية أو تعارض في ملفات gatsby الأساسية.

ehowey هنا gatsby info الذي طلبته

النظام:
نظام التشغيل: macOS 10.14.6
وحدة المعالجة المركزية: (4) x64 Intel (R) Core (TM) i7-5557U CPU @ 3.10GHz
شل: 3.2.57 - / بن / باش
الثنائيات:
العقدة: 12.9.1 - / usr / local / bin / node
الغزل: 1.17.3 - / usr / local / bin / yarn
npm: 6.11.2 - / usr / local / bin / npm
اللغات:
بايثون: 2.7.16 - / usr / local / bin / python
المتصفحات:
الكروم: 76.0.3809.132
Firefox: 68.0.1
سفاري: 12.1.2
الحزم:
غاتسبي: ^ 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-plugin-manifest: ^ 2.2.9 => 2.2.10
gatsby-plugin-offline: ^ 2.2.10 => 2.2.10
gatsby-plugin-response-helmet: ^ 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-note-images: ^ 3.1.19 => 3.1.19
gatsby-note-prismjs: ^ 3.3.9 => 3.3.9
نظام ملفات جاتسبي المصدر: ^ 2.1.18 => 2.1.18
ملاحظة غاتسبي محول: ^ 2.6.19 => 2.6.19
محول شارب غاتسبي: ^ 2.2.12 => 2.2.12
الحزم:
غاتسبي كلي: 2.7.40

كنت أواجه نفس المشكلة: تم إنشاء الموقع بشكل لا تشوبه شائبة على Netlify ، ولكن تم تعليقه على جهاز التطوير الخاص بي باستخدام كل من gatsby build و gatsby develop .

بعد التلاعب بإصدارات الحزمة ، لاحظت أن إرجاع gatsby-plugin-sitemap من الإصدار 2.2.10 إلى 2.2.9 قد أصلح المشكلة بالنسبة لي. من الغريب أن بعض الأشخاص هنا لديهم مشكلات مع 2.2.9 ، مما قد يعني أن المشكلة تكمن في مكان آخر.

تحرير: تحدث مبكرًا جدًا ، لا يزال Gatsby معلقًا عند خطوتي "المصدر وتحويل العقد" و "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 حل المشكلة.

ما زلت أقوم ببعض الصيد ، وأحاول معرفة ذلك. لا تزال مشكلة بالنسبة لي. هل يعرف أي شخص ما إذا كان هذا قد يتعلق بالتبديل من babel 7.0.0 -> 7.5.5. حدث هذا التبديل في الوقت الذي بدأت فيه في مواجهة هذا الخطأ ويتزامن معي بدأت أرى مشاكل ... لقد كنت أحاول الحصول على قرارات الغزل للعمل من أجل ربط إصدارات babel في 7.0.0 ولكن لم تنجح في ذلك هذا بعد.

أعتقد أنه يمكنني تقديم بعض الأفكار - لقد بدأت أواجه هذه المشكلة عندما ، في منتصف الطريق من خلال إضافة المكونات الإضافية إلى مشروع ، قمت بتحديث gatsby-cli في نافذة طرفية أخرى. نجح تشغيل gatsby clean في مشروعي.

من https://github.com/gatsbyjs/gatsby/issues/6385#issuecomment -531949380 - أرى أيضًا هذه المشكلة ولكن gatsby clean لم يحلها. يبدو أنه قد يكون مجرد طباعة CLI معلقة ، ولهذا السبب يؤدي تغيير حجم الجهاز إلى إصلاحه ؟؟ 🤷‍♂ 😕 ❓❗️

يبدو أن تغيير حجم نافذة المحطة الطرفية يصلح لي! لم أختبرها على نطاق واسع للغاية ، هل يمكن لبعض الأشخاص الآخرين الذين يعانون من هذه المشكلة أن يجربوها أيضًا؟ يا له من خلل غريب وربما حل غريب.

أواجه نفس المشكلة بالضبط - يتعطل gatsby في "عقد المصدر وتحويله" أو "createPagesStatefully" في كثير من الأحيان ، ولا أستخدم أي مكونات إضافية للمصدر. لقد واجهت مؤخرًا فقط إصلاح "تغيير حجم النافذة الطرفية" وأنا محير بنسبة 140٪ حول كيفية إصلاح هذا الأمر له ، لكنه يفعل ذلك. هذا يبدو وكأنه قضية خطيرة جدا!

JaKXz - شكرا لك! هذا كان يقود لي المكسرات. يبدو أن الإصلاح يقوم بتغيير حجم النافذة الطرفية في رمز VS. ما عليك سوى سحبها لأعلى أو لأسفل قليلاً وستنطلق مهمة التطوير بسعادة. لقد اختبرت في حالتين مختلفتين كل من الغزل و npm ، ومساحات العمل وليس. يبدو أنه يعمل في كل تلك الحالات بالنسبة لي. يبدو أيضًا أنه يتجمد أو يتعطل عند createPagesStatefully أكثر من source and transform nodes الآن بالنسبة لي. سأترك المشكلة مفتوحة في الوقت الحالي ، وقد يلزم حل هذه المشكلة بطريقة أقل "اختراقًا" بواسطة شخص لديه معرفة أكثر مني بالكيفية.

ehowey لدي نفس المشكلة ونقل نافذة المحطة الطرفية في أعمال vscode (لم أستطع تصديق ذلك عند قراءة هذه المشكلة حتى جربت نفسي).
هل تعرف ما إذا كان يحدث فقط على VS Code؟

لدي هذه المشكلة على iTerm 2 ، لذا فهي ليست خاصة برمز VS.

كانت مشكلتي أيضًا في iTerm 2

محطة Webstorm ، محطة Mac ، iTerm

هل عمل إصلاح المحطة الطرفية لتغيير الحجم معكم جميعًا في بيئات تطوير مختلفة؟

من ناحيتي ، عملت عملية تغيير حجم الجهاز على iTerm و VSCode (استغرق الأمر بضع محاولات لإعادة إنتاج المشكلة على iTerm)

تعمل خدعة تغيير الحجم الطرفية بشكل موثوق بالنسبة لي في iTerm 2.

نعم ، تغيير حجم iTerm 2 يعمل بشكل مثالي

إذا عمل تغيير الحجم ، أظن أن هذا الخطأ مرتبط بالمخزن المؤقت ، في مكان ما يحتاج إلى تدفق stdout.

يبدو هذا النوع من المشكلات المتعلقة بـ kernel + shell. ربما تتفاعل العقدة بطريقة ما مع النواة و / أو الصدفة. أقول هذا فقط لأنني لا أستطيع تكرار المشكلات باستخدام Linux أو Windows. لا يمكنني العثور على أي مشكلات معروفة ، لذلك إما أ) إنها مزيج من أنماط التعليمات البرمجية الفريدة لـ Gatsby + التفاعل مع النظام ، أو ب) لا أعرف السؤال الصحيح الذي يجب طرحه بعد.

إذا أدى تغيير حجم الجهاز إلى حل المشكلة ، فقد يكون هناك خلل بين العقدة و 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 للمتابعة. فقط افعل هذا حتى يتوقف ... إذا توقف.

نظرًا لطبيعة حلقة الحدث ، أراهن أنها لن تتعطل حتى أثناء التصحيح. ربما تكون هذه المقاطعات كافية لإبقائها على المسار الصحيح. يمكن أن تكون الأخطاء غير المتزامنة بمثابة ألم حقيقي لتعقبها. إذا لم يتم تعليقه أثناء استخدام مصحح الأخطاء ، فاستبدل هذا السطر debugger بـ:

reporter.log(plugin.resolve);

نأمل أن يؤدي ذلك إلى شيء ما. سيكون من الجيد معرفة ما هو المكون الإضافي الذي تسبب في الحظر. إذا تمكنا من معرفة ذلك ، فقد نتمكن من معرفة ما يجب تحسينه / إعادة بنائه لفرز ذلك.

يعمل تغيير الحجم بالنسبة لي أيضًا ، فأنا أستخدم zsh كصدفة VSCode الخاصة بي.

@ Js-Brecht - شكرًا لك على الوقت الذي أمضيته في الرد المفصل. لم أكن متأكدًا بالضبط من المكان الذي من المفترض أن أدخل فيه kill -SIGWINCH ${pid} . لم أستطع فعل ذلك أثناء عملية الإنشاء.

مع مصحح الأخطاء ، ظهر الكود التالي ... أبعد مني لفهمه كثيرًا. لقد علقت بالفعل في مصحح الأخطاء ولكن لا يزال يعمل .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 ، باستخدام Terminal ، يعمل تغيير الحجم بالنسبة لي.

ehowey فقط حتى أعلم أنني gatsby-source-filesystem هو الجاني ، وهو أمر منطقي بالنسبة لي ... خاصة بسبب مشكلات gatsby الحالية ذات الصلة.

أرغب في معرفة ما إذا كان المكون الإضافي يمكنه التعامل مع تشغيل اختباري. إذا توقفت أثناء إجراء الاختبارات ، فأعتقد أن هذه ستكون طريقة سهلة لمعرفة مكان الفشل. إذا لم يكن الأمر كذلك ، حسنًا ... سيتعين عليك فقط إجراء بعض التشريح / التصحيح ، والذي سيكون صعبًا بالنسبة لي ، لأنني لا أملك نظام MacOS.

هل يمكنك تنزيل مستودع 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} من مثيل shell آخر. عندما يتوقف البناء ، افتح نافذة / علامة تبويب طرفية أخرى ، وقم بتشغيل الأمر من هناك. يجب أن يعمل هذا المقتطف الصغير:

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 آسف للردود الأبطأ ... هذه في الحقيقة مجرد هواية جانبية أفعلها في أوقات الفراغ في المساء.

لذلك قمت بتشغيل نفس الشيء داخل لعبة gatsby hello starter - مثل العظام المجردة كما يمكنك الحصول عليها. عذرًا ، لقد قمت بتشغيله من قبل في مساحة العمل الرئيسية الخاصة بي في مشروع كنت أواجه مشكلات فيه. لقد قمت بتكرارها مسبقًا في البداية على الرغم من أنني لا أعتقد أنها تتعلق بمكوِّن إضافي بل بشيء في صميم برنامج gatsby.

إنها معلقة على المصدر وتحويل العقد مما يمنحني الإخراج التالي:

< 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

كملاحظة جانبية - عندما أستخدم أمر التصحيح ، فإنه يتم تعليقه على المصدر وتحويل العقد. عندما أستخدم تطوير gatsby ، يتم تعليقه في الغالب في createPagesStatefully الآن بالنسبة لي. آسف أعلم أن هذا أمر غريب حقًا. لأكون صادقًا ، لست متأكدًا من مقدار العمل الذي يستحقه من نهاية الأشياء. تعمل خدعة تغيير حجم نافذة المحطة الطرفية في كل مرة بالنسبة لي وللآخرين. إنه إصلاح سريع ولكن يجب ألا يؤثر على العديد من المستخدمين وإلا ستغمر المشكلات.

وقد بدأ هذا يحدث هنا أيضًا. تحل خدعة _resize the terminal_ الأمر ؛ غريب جدا!

+1 لا يعمل في iTerm2 ، لكنه يعمل في Terminal 🤷‍♂️

ehowey يتم تحديد غالبية ما يحدث أثناء

هل يمكنني أن أجعلك تغير هذه الخطوط؟

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

يرجى تشغيل هذا ، ونسخ / لصق الناتج بالكامل (قد يرفقه بإجابتك كملف .txt ). سيكون أكثر تفصيلاً إلى حد كبير ، ومن المحتمل أن تكون الكثير من المعلومات غير ضرورية ، ولكن 🤷‍♂.

بعد القيام بذلك ، أود معرفة ما إذا كانت زيادة مجموعة مؤشرات ترابط العقدة تحدث فرقًا. لقد لاحظت مشكلات أخرى تذكر نفس الشيء أو مشكلات مشابهة. تحدث في الغالب في source and transform ، ويتحدث البعض عن أن هذه المرحلة تستغرق إلى الأبد ، أو تغلق تمامًا. لذلك ، أريد أن أرى ما إذا كان هناك نوع من الجمود في نظام الملفات io ... يتم إلغاء الوصول غير المتزامن إلى نظام الملفات عن طريق العقدة إلى مؤشرات ترابط مختلفة ، وبشكل افتراضي ، تحتوي العقدة فقط على مجموعة من 4 مؤشرات ترابط لمساحة المستخدمين. إذا كان هؤلاء يملأون ، ويحتاج إلى القيام بمزيد من التفريغ ، فستنتظر المهام في قائمة الانتظار في حلقة الحدث الرئيسي ، في انتظار سلسلة رسائل. من المحتمل أن يؤدي هذا إلى توقف البرنامج بأكمله ... حتى يصبح الموضوع متاحًا. يحتفظ Gatsby بذاكرة تخزين مؤقت على نظام الملفات ، لذلك ربما يكون هناك تصادم يحدث في مكان ما ، وإذا كان هناك نوع من الجمود يحدث ، فربما تنتظر الخيوط مهلة / مقاطعة قبل الانتقال ، وإذا كان هناك العشرات (أو المئات ، حتى) من أحداث الوصول إلى نظام الملفات ، فقد ينتظرون جميعًا نفس المهلة ، ويتسببون في تراكم كل شيء. يمكنك أن ترى أن هذا قد يتسبب في زيادة أوقات الانتظار بسرعة كبيرة.

قد تساعد زيادة حجم التجمع في التخفيف من بعض حركة المرور ... أو قد يحدث بنفس الطريقة ، فقط مع المزيد من سلاسل الرسائل 😆.
جرب الأمر التالي:

UV_THREADPOOL_SIZE=10 gatsby develop

@ Js-Brecht لا يبدو أن تغيير حجم تجمع مؤشرات الترابط يحدث فرقًا كبيرًا.
لقد حصلت على الناتج التالي من الأمر القياسي gatsby develop بالتغييرات التي ذكرتها أعلاه. لا يزال في بداية عالم hello-world gatsby.

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() . يبدو أن هذا مناسب ، نظرًا لأنه مترجم إلى MacOS نظرًا لكونه عملية Mac هي fsevents ، ويبدو أن الإنشاء فشل في الوحدات النمطية التي يتم استخدامه فيها ، أو في الوحدات النمطية التي تقوم بكتابة / معالجة الملفات التي يحتمل مشاهدتها.

chokidar.watch() موجود في gatsby-source-filesystem أيضًا ، وهذا هو المكان الذي فشل فيه مع الريبو الآخر الخاص بك ،ehowey؛ ناهيك عن أن gatsby-source-filesystem لم يتم استدعاؤه في الحد الأدنى من الريبو الخاص بك ، وهو نوع يفسر سبب تجاوزه لـ source and transform . هناك حالات لـ chokidar قبل internal-data-bridge ، لكنني أعتقد أن المواقع التي لا تؤثر على البنية (مثل query-watcher ). ومع ذلك ، أعتقد أن internal-data-bridge هو سبب تعليقه أثناء تشغيل مصحح الأخطاء ؛ وفي مسار مباشر ، كان من المحتمل أن يؤثر على مراحل لاحقة من البناء.

اسمحوا لي أن أعرف ما إذا كان هذا يعمل على إصلاح المشكلات ، أو حتى إذا أدى ذلك إلى جعلها أبعد مما كانت عليه. :تمنيت:

@ Js-Brecht أنت تحصل في مكان ما! ركضت gatsby develop الأرجح 15 مرة. لم يتم تعليقه مطلقًا على source and transform nodes أو createPagesStatefully لكن يبدو أنه توقف ، ربما 2/10 مرات ، على start webpack server . يمكنني أن أتصادم مع خدعة تغيير الحجم الطرفية أيضًا. هل من المحتمل أن تكون قد فاتتك مثيل chokidar / fsevents الذي قد يتعلق بـ start webpack server ؟

كملاحظة جانبية ، يبدو أيضًا أنه يتحرك عبر خطوات عملية التطوير بشكل أسرع من ذي قبل إذا كان لذلك أي علاقة به؟

من الجيد حقًا سماع ذلك. لقد تركت مثيلًا واحدًا من chokidar ، عن قصد ، وبعد أن ينتهي مباشرة من التمهيد ويبدأ الخادم. إنه في node_modules/gatsby/dist/commands/develop.js قرب نهاية الدالة startServer() . أنا لست على جهاز كمبيوتر الآن ، أو سأعطيك فرقًا.

يمكنك العثور على السطر الدقيق بالقيام بما يلي:

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

كنت متأكدًا تمامًا من أنه إذا تم إصلاح هذا التمهيد ، فسيتعين تعليقه على الخادم. اسمحوا لي أن أعرف ما إذا كان هذا التغيير يجعله يعمل بشكل موثوق به ، وسأرسل العلاقات العامة وأعتني بإعلام الناس بذلك.

أنا في الواقع لست مندهشا من أنه يجعله يعمل بشكل أسرع. بناء على المجردة المشروع عادة يأخذ مني ربما الثانية، ورأيت بعض أوقات التشغيل طويلة مجنون لمراحل معينة في إخراج التصحيح الخاص بك. fsevents المفترض أن يقوم

@ شبيبة بريشت قبعتي تنفجر لك. ليس لدي أي فكرة عن كيفية إخراجك لهذا الأرنب من القبعة وتم إصلاح الخلل مثل هذا غريب من مسافة بعيدة ولكن العمل الجيد! سأنتظر حتى يقوم الفرق بإجراء تغييرات على 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

إذا كان أي شخص يستخدم LokiJS ولم يؤد تغيير حجم الجهاز إلى إصلاحه ، فمن المحتمل جدًا أن تكون المشكلة التي وجدتها.

مرحبًا يا شباب ، ehowey ، يرجى مراجعة PR # 17938. إذا كان أي شخص على استعداد للاختبار ، يرجى القيام بذلك ، وإسقاط خط على PR.

يمكنك قطع الريبو الخاص بي واستخدامه كمصدر gatsby في موقعك باستخدام gatsby-dev-cli . أولاً ، تحتاج إلى 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 صباحًا - 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 محليًا على الإطلاق عند بدء تشغيل lumen. تظل معلقة على 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

يجب أن يؤدي ذلك إلى تعطيل fsevents على نظام MacOS ، والذي يبدو أنه حل بديل موثوق.

@ Js-Brecht أؤكد أنه يبدو أنه يعمل على إصلاحه بشكل دائم أكثر من الحلول الأخرى المذكورة هنا. شكرا للمشاركة.

steinitz تقول "المزيد" بشكل دائم. هل تقصد أن تقول إنه لا يزال يحدث عند استخدام هذا المفتاح؟

@ Js-Brecht لا ، آسف أن تكون غير واضح.

كنت ألمح إلى حقيقة أن الحلول الأخرى ، بما في ذلك الحلول الخاصة بي ، بدت وكأنها تعمل لفترة من الوقت لكن المشكلة عادت. مع الحل الخاص بك ، قمت بإثارة ذلك من خلال إجراء تغييرات وإعادة تشغيل gatsby (مع تحسيناتك) ولكن البناء يستمر في العمل.

بعد قولي هذا ، كانت هذه رحلة أفعوانية لذا ما زلت مستعدًا عاطفيًا: ابتسم: لعودة المشكلة.

لنكون واضحين: جيد حتى الآن.

عفوًا ، تحديث: لقد أعدت تشغيل WebStorm لإجراء اختبار نهائي قبل نشر هذا والآن يتم تعليقه على source and transform nodes في محطة WebStorm.

لأي شخص آخر يجد هذه المشكلة ، حاول

CHOKIDAR_USEPOLLING=1 gatsby develop

يجب أن يؤدي ذلك إلى تعطيل fsevents على نظام MacOS ، والذي يبدو أنه حل بديل موثوق.

@ Js-Brecht أنا أستخدم ubutu 18.04 وأواجه نفس المشكلة من حين لآخر. هل هناك أي اقتراح لنظام التشغيل الخاص بي؟ هل يمكنك تقديم بعض التفاصيل حول الأسباب المحتملة لهذه المشكلة؟

تم حل هذه المشكلة بفضل العمل الدؤوب لـ @ Js-Brecht وRomanHotsiy. لقد كانت مشكلة في المنبع في fsevents ، تتجاوز بكثير ما كان بإمكاني اكتشافه بنفسي ، ويجب إصلاحها في التحديثات المستقبلية بمجرد تنفيذ هذه التغييرات والانتقال من fsevents إلى gatsby نفسه. في الوقت الحالي ، هناك حل بديل موثوق به وهو تغيير حجم النافذة الطرفية ، وهناك طريقة لإصلاح ذلك في الريبو نفسه الذي تمت مناقشته هنا: https://github.com/gatsbyjs/gatsby/pull/17938 ولكن عليك إعادة ذلك إصلاح بعد أي تغييرات على مجلد node_modules الخاص بك وقد لا يستحق العمل اعتمادًا على عدد مرات تحديث إصدارات الحزمة الخاصة بك.

سأترك المشكلة مفتوحة حتى ينتقل الإصلاح في اتجاه مجرى النهر إلى gatsby نفسه.

@ Boty22 لا يستخدم Ubuntu fsevents ، لذلك من المحتمل أن يكون شيئًا مختلفًا. تمت مصادفة بعض المشكلات عند استرداد البيانات من موقع بعيد ؛ راجع # 6654 و # 17940 للحصول على بعض التفاصيل حول إصلاح مشكلات التزامن.

سؤال سريع: هل تغيير حجم الجهاز الطرفي مفيد؟ إذا كان الأمر كذلك ، فقد يكون _ شيئًا _ مشابهًا لهذه المشكلة.

@ Js-Brecht تغيير حجم المحطة لا يساعد في Ubuntu. أقوم باسترداد البيانات من جدول AirTable باستخدام البرنامج المساعد gatsby-source-airtable BTW

يمكن أن يكون مشكلة. تحقق من هذا التعليق . إذا لم يفلح ذلك ، فقد يكون من الأفضل فتح تذكرة جديدة

steinitz آسف ، فاتني تعليقك. هل يمكنك تجربة الإصلاح الموضح في # 17938؟ بشكل أكثر تحديدًا ، هنا وهنا . إذا لم ينجح الأمر ، فمن المحتمل أن يكون هناك المزيد في حالتك.

لم تواجه أي مشاكل مع CHOKIDAR_USEPOLLING=1 gatsby develop منذ ذلك الحين.

شكرًا على الحل البديل @ Js-Brecht

أرى هذا أيضًا مع 2.15.28 عندما أقوم بإنشاء gatsby. هل أحتاج إلى إيقاف تطوير gatsby في المحطة الأخرى؟ إنه يحدث بشكل متقطع

حدث مرة أخرى بدون تشغيل خادم dev. لدي مدونة بسيطة من متابعة البرنامج التعليمي للمدونة.

يبدو أن كل شوط آخر تقريبًا. أنا على جهاز Mac بالمناسبة

canvaspixels هل تغيير حجم النافذة الطرفية يؤدي إلى https://github.com/gatsbyjs/gatsby/pull/17938#issuecomment -540661991

RomanHotsiy التي

مرحبًا بالجميع ، تم نشر النسخة المصححة من fsevents . يجب أن تكون قادرًا على حذف ملف yarn.lock وتشغيل الغزل مرة أخرى. يجب أن تلتقط كل من تبعياتك تلقائيًا [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 . يجب أن يعيد ذلك إنشاء ملف القفل بالإصدار الصحيح من fsevents ، دون لمس أي شيء آخر

اه انتظر. هذا فقط إذا كان لديك chokidar كاعتماد مباشر 🙄. نسيت. karlhorky هو الحق

أنا أستخدم npm . كان حذف node_modules وتشغيل npm i --save [email protected] ثم npm i بمثابة الحيلة لي. استغرق بدء التشغيل 19 ثانية وأنا أستخدم gatsby-lumen-starter كقاعدة.

-- تعديل:

لقد أنهيت بالفعل ما كنت أعمل عليه ، ودفعت إلى Netlify ولم أتمكن تمامًا من الإنشاء بسبب fsevents ( error [email protected]: The platform 'linux' is incompatible with this module ).

لقد قمت بالتبديل إلى yarn وكان لدي نفس المشكلة لذا قمت بإزالة الغزل fsevents بالكامل ، والآن يعمل كل من local و netlify ...

حصلت على نفس المشكلة ولم تستطع تتبع السبب. هذا يحدث لي سواء على أجهزة Mac أو أجهزة الكمبيوتر. يمكن أن تحاول ربط هذا بسرعة الإنترنت ، ولكن هذا حدث لي أيضًا عندما كنت متصلاً بشبكة عالية السرعة. ما يبدو أنه يعمل بالنسبة لي الآن هو إضافة هذا في حسدتي

GATSBY_CONCURRENT_DOWNLOAD=5

وتشغيله باستخدام --v8-pool-size=128

في حالتي ، يبدو أنه موجه جدار الحماية الخاص بي على OSX. إذا كنت سريعًا بما يكفي للسماح أو أرفض الاتصالات القادمة من الخارج ، فسوف تنجح بلا عيب. المشكلة هي أن مربع الحوار الفوري ينبثق لجزء من الثانية ويختفي مع استمرار Gatsby ثم يفشل في التعلق بإحدى الخطوات العديدة المذكورة أعلاه.
خيارات:

• تعطيل جدار الحماية (عدم وجود ذلك)
• وضع غاتسبي في القائمة البيضاء (غير متسق عبر المشاريع والترقيات)
• ابحث عن طريقة للتوقف عند المطالبة حتى يحدد المستخدم الخيار
• عنوان الربط الافتراضي للمضيف المحلي (يجب ألا يتطلب المطالبة بقبول الاتصالات الواردة).

thomasthep عنوان الربط الافتراضي لخادم dev هو المضيف

بشكل عام لا ينبغي أن يكون هناك أي اتصالات "قادمة من الخارج" ؛ حتى عندما يقوم المكون الإضافي بجمع معلومات من مصدر خارجي ، فإن الاتصال ينشأ من مضيفك المحلي ، وليس من مصدر خارجي ، وعادة ما يتم قبول ذلك باعتباره "اتصالًا راسخًا" من قِبل معظم جدران الحماية ، حسب تجربتي ، نظرًا لأن معظم جدران الحماية مهيأة لقبول أي اتصالات صادرة.

أستطيع أن أرى هذا يحدث إذا تم تكوين جدار الحماية الخاص بك لحظر العمليات ، بدلاً من مجرد الاتصالات. في هذه الحالة ، ستكون العقدة هي التي يجب إدراجها في القائمة البيضاء.

ستحتاج إلى مزيد من المعلومات لفهم سبب حدوث ذلك لك حقًا. من المحتمل أن يكون فتح تذكرة جديدة أكثر فعالية. كان هذا الأمر يتعلق بـ fsevents على نظام MacOS الذي تسبب في حدوث مشكلات ، وقد تمت معالجة ذلك ، وهذا هو سبب إغلاقه الآن. أي شيء لا يتعلق بـ fsevents يجب أن يكون له بالفعل مشكلته الخاصة ، لجذب الاهتمام الذي يستحقه.

بالنسبة للسجل ، يمكن أن يحدث هذا أيضًا إذا كان لديك خادم GraphQL يعمل في وضع التصحيح وتم إيقافه عند نقطة توقف.

للسجل: بدأ هذا يحدث لي عندما أضفت gatsby-source-s3-image ووصل دلو s3 إلى أكثر من 100 صورة. يمر عبر جميع الصور البالغ عددها 145 صورة في المرحلة source and transform nodes ثم يتوقف هناك إلى الأبد. لا يزال هذا يحدث ، لقد جربت الإصلاحات أعلاه. لحسن الحظ ، فإنه يعمل بعد 5-6 محاولات لذلك لم يتم حظري.

عملت إعادة تحجيم نافذة المحطة بشكل غريب بالنسبة لي

بالنسبة لي ، يبدو أن تقييد التنزيلات المتزامنة كما هو موضح هنا مفيد.

أضفت السطر التالي إلى ملف .env الخاص بي. الافتراضي هو 200.
GATSBY_CONCURRENT_DOWNLOAD=50

لست متأكدًا مما إذا كان يحل مشكلتك ولكن ربما يساعد شخصًا ما :)

@ rishabhaggarwal2 هناك مشكلة مماثلة يبدو أنها قد تكون ما GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop ؟

شكرا لك ، هذا أصلحها بالنسبة لي. منذ أن كنت أسحب الكثير من المحتوى من موقع ويب تابع لجهة خارجية ، ظل معلقًا عند تنزيل المحتوى. (97٪ - قريبة جدا حتى الآن)