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

@ m-allanson هل هناك مناقشة / قضية حول كيفية التعامل مع هذا؟ لم أراه في الرابط الذي أدرجته. أشعر بالفضول لسماع محادثات حول كيفية التعامل مع القيام بذلك على مضيف مثل Netlify واستخدام CMS مثل Wordpress / Drupal الذي يتطلب حاليًا الكثير من طلبات HTTP أثناء الإنشاء.

AFAIK لن تتمكن من استخدام الإنشاءات المتزايدة على netlify لأن الدلائل .cache و public لا يتم حفظها بين الإصدارات ، لذلك ستعمل دائمًا على بناء نظيف

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

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

نخطط لأن يصبح موقعنا أكبر حجمًا ، لذلك نحن نختبر Gatsby على نطاقات أكبر. لقد حاولنا القيام بشيء مثل هذا path: './src/pages/${subPath}', حيث يكون المسار الفرعي هو process.argv[3] . يعمل هذا بشكل جيد عندما نستضيف أجزاء من موقعنا gatsby develop . كما أنه يتحايل على مشاكل كومة الذاكرة عند استخدام gatsby build لموقع صفحة 5k +. لكي يكون حلاً حقًا ، فمن المحتمل أن يعتمد على القدرة على تحديد دليل فرعي للمخرجات داخل المجلد العام: https://github.com/gatsbyjs/gatsby/pull/4756

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

robertschneiderman لقد واجهنا مشكلة الذاكرة أيضًا. لقد اقتربنا من 1500 صفحة ، لكن عددًا غير معقول من الصور (مدونة التصميم). لقد قمنا بإيقاف تشغيل خرائط المصدر ، وأوقفنا تنزيل ملفات الصور ، ولكن في النهاية اضطررنا إلى تعديل أمر الإنشاء لزيادة الذاكرة المخصصة لمثيل العقدة. عبر العلم --max_old_space_size .

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

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

تتمثل فائدة استخدام Gatsby على موقع React القياسي المستند إلى واجهة برمجة التطبيقات في أنني سأقضي جزءًا بسيطًا من الوقت في بناء وصيانة واجهة برمجة تطبيقات البيانات ونظام إدارة الحالة الذي يقوم بتحميل البيانات البعيدة وتخزينها. (نظرًا لأنني أخطط لنشر هذا التطبيق لمواقع متعددة ذات حجم مماثل ، يبدو أن هذا يمثل فائدة قيّمة للغاية.)

يتمثل الجانب السلبي لاستخدام Gatsby في هذه الحالة في حقيقة أن الموقع بأكمله سيحتاج إلى إعادة بنائه حتى لأحدث تحديث للمحتوى غير ذي أهمية. هل نسيت إضافة فاصلة؟ إعادة بناء كل 5000 صفحة! من يعرف حتى كم من الوقت سيستغرق ذلك؟ هذه مشكلة أكبر عند التفكير في تجربة مستخدمي CMS - لقد اعتادوا على رؤية التغييرات تظهر على الموقع فور حفظهم. مع Gatsby ، نتطلع إلى الانتظار لبضع دقائق (على الأقل) قبل ظهور التغيير.

إذا كانت هناك طريقة لتشغيل إصدارات لمجموعة فرعية من الصفحات ، فستجعل Gatsby الاختيار الواضح والنهائي. في هذه اللحظة ، رغم ذلك ، إنها عملية بيع صعبة.

راجع للشغل ، لقد كنت أعمل كثيرًا على تحسين السرعات لبناء مواقع أكبر للإصدار v2. في الإصدار 2 التجريبي الأحدث - قد تتمكن من إنشاء 5000 صفحة في <1:30. سيكون هناك المزيد من التحسينات في السرعة قادمة.

هذا مذهل KyleAMathews! أنا بالتأكيد أتطلع إلى ذلك! اسمحوا لي أن أعرف ما إذا كنت تريد الاختبار مقابل مدونة ثقيلة الصور

KyleAMathews 5K جميل لكننا نحتاج 1M

إذا أردنا تجميع أجزاء من الموقع بشكل منفصل ، فيمكننا تعيين العلامات على الإنشاء بحيث تعرف عقدة gatsby فقط إنشاء أجزاء الموقع المحددة. يمكننا بعد ذلك إعادة إضافة الملفات الثابتة التي تم إنشاؤها <a href> أساسي بدلاً من <Link to > .

أتساءل عما إذا كان بإمكاننا جعل <Link to> يعمل عند الارتباط بالملفات التي تم إنشاؤها مسبقًا إذا دمجنا بعضًا من data.json في وقت الإنشاء. النظر في ذلك قليلا في الوقت الراهن.

لا داعي للقلق بشأن وقت الإنشاء ، ولكن مع حجم الملفات الثابتة التي أحتاج إلى تحميلها لأي تحديث ، أطلقنا محفظة مرئية كبيرة مع Gatsby والموقع الثابت للتحميل يزيد عن 150 ميغابايت
في الغالب من الصور.
هذا يجعل الموقع غير متاح حوالي 40 دقيقة أثناء التحديث
إن إتاحة إعادة بناء جزء من الموقع هي بالتأكيد ميزة من شأنها تعزيز Gatsby.
أخطط لاستخدام Gatsby لموقع جديد ، لكنني سأقسم الموقع إلى جزء ثابت وديناميكي باستخدام نظام php CMS التقليدي للجزء الإخباري.

rbmedia ، قد ترغب في التفكير في مضيف يقوم بتبديل النشر مثل Netlify بحيث يظل موقعك الحالي قيد التشغيل حتى يصبح الإصدار الجديد جاهزًا.

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

أي أخبار بشأن هذه المسألة؟ نحن نخطط لموقع يحتوي على حوالي 100 ألف صفحة وستكون الإنشاءات المتزايدة رائعة.

اجعل مسارًا آخر كمجلد صفحة ثابت افتراضي ، وليس "/ عام".
بعد تشغيل gatsby build ، انسخ ../public/* إلى المسار الافتراضي.

مرحبا!

لقد ساد الهدوء هذه القضية. الهدوء المخيف. 👻

نتلقى الكثير من المشكلات ، لذلك نقوم حاليًا بإغلاق المشكلات بعد 30 يومًا من عدم النشاط. لقد مرت 20 يومًا على الأقل منذ آخر تحديث هنا.

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

شكرًا لكونك جزءًا من مجتمع Gatsby! 💪💜

ما زلت لا أعتقد أن هذا تم إصلاحه / دعمه في Gatsby. أي أخبار @ TeamGatsby؟

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

هل يتتبع Gatsby حاليًا عقد GraphQL التي يتم استردادها في صفحة معينة؟ إذا كان الأمر كذلك ، فقد يبدو أنه من الممكن إضافة عمليات إعادة بناء تزايدي بناءً على التغييرات في البيانات. هذا نصف العمل ، أليس كذلك؟

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

coreyward نعم ، يتتبع Gatsby كل عقدة يتم إرجاعها لاستعلام (عبر تبعية الصفحة- حل الحل). هذا هو ما يمنح قدرة gatsby develop على إعادة تشغيل الاستعلامات فقط من أجل البيانات المتغيرة. لا نقوم حاليًا بحفظ هذه المعلومات على القرص ، لذا لم يتم استخدامها مقابل gatsby build حتى الآن ، لكن هذه هي الخطة بالتأكيد.

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

mattbloomfield لدينا المزيد من العملاء المهتمين بهذا الأمر ، لذلك لدينا هذا في أعلى قائمة الأولويات.

نحن نطبق gatsby مع دروبال 8 backend باستخدام البرنامج المساعد gatsby-source-graphql ، والأداء ليس مشكلة حتى الآن ، مع 4000 صفحة تقريبًا مدمجة في أقل من 30 ثانية. نحن نسحب جميع البيانات في عقدة gatsby بدلاً من تشغيل الآلاف من StaticQuerys ، وتجاوز معالجة الصور في الوقت الحالي.

""
نجاح تشغيل استعلامات Graphql - 3.088 ثانية - 4008/4008 1311.56 استفسار / ثانية
نجاح كتابة بيانات الصفحة - 0.070 ثانية
نجاح كتابة بيانات إعادة التوجيه - 0.001 ثانية
نجاح إنشاء البيان والرموز ذات الصلة - 0.117 ثانية
النجاح على PostBootstrap - 0.127 ثانية

انتهى تحميل معلومات التمهيد - 15.751 ثانية

نجاح إنشاء حزم جافا سكريبت و CSS - 3.361 ثانية
نجاح بناء HTML ثابت للصفحات - 6.906 ثانية - 4006/4006 609.25 صفحة / ثانية
معلومات تم البناء في 26.047 ثانية

أقوم حاليًا بتقييم استخدام Gatsby لتسريع موقع Rails 3.x القديم الذي يستضيفه Heroku وهو بطيء مثل دبس السكر. يحتوي على حوالي مليون صفحة ، لذا فإن الإنشاءات المتزايدة هي الطريقة الوحيدة التي ستعمل بها. لا تتغير معظم الصفحات ، لذا فإن جعلها ثابتة تبدو وكأنها فوز كبير ، ولكن الصفحات الجديدة تتم إضافتها باستمرار ويتم تحرير بعض الصفحات القديمة. يتوقع المستخدمون رؤية التغييرات في غضون ثوان. كان أملي أن أضيف فقط ما يكفي من الكود إلى تطبيق ريلز لجعله خادم JSON API ، وإنشاء واجهة أمامية جديدة مع Gatsby ، مع أصول ثابتة مستضافة في مكان ما مثل Netlify أو S3.

كنت أفكر في أنني سأكون قادرًا على القيام بشيء مثل تشغيل بناء Gatsby تزايدي عبر عامل طابور العمل. يعرف خادم واجهة برمجة تطبيقات Rails متى يتم تحديث الصفحة ، لذا سينشئ "مهمة تحديث الصفحة" باستخدام page_id (مفتاح في قاعدة بيانات postgres) ، ويمرر العامل ذلك إلى Gatsby باستخدام متغير ENV بشيء مثل PAGE_ID=1235 gatsby build . سأستخدم ENV var داخل createPages () للبحث فقط عما هو مطلوب لتلك الصفحة الواحدة وإنشائها. سيتم نقل ملف (ملفات) الإخراج الناتج إلى المضيف الثابت (آمل أن يكون هناك خطاف بناء لذلك). إذا لم يتم تعيين PAGE_ID var ، فسيتم إنشاء جميع الصفحات كالمعتاد.

إذا تم حذف صفحة ، فإن واجهة برمجة تطبيقات Rails ستنشئ وظيفة إما تحذف الأصول مباشرة من المضيف الثابت ، أو ربما هناك شيء مطلوب من Gatsby لذلك ما زلت أقوم بتشغيله باستخدام متغير ENV مختلف. (أعتقد أنني سأحتاج إلى مسار الصفحة على الأقل).

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

لدينا نسخة ألفا. إنها ليست عمليات بناء تدريجية حتى الآن ولكن على الأقل الطريق إلى الأمام.
يمكنك استخدامه عن طريق تثبيت npm install --save gatsby@per-page-manifest

مزيد من المعلومات:
https://github.com/gatsbyjs/gatsby/pull/13004

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

سم مكعبKyleAMathewsMoocar لإعطاء تفسير أفضل من هذا.

Pinging هذا ، حيث مرت بضعة أشهر منذ آخر تحديث ويبدو أنه مكان العمل. أرى أن تفكيك page-data.json قد بدأ ، وأنا أستخدمه.

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

wardpeetMoocar أنا غير متأكد من هو الشخص الأنسب / قائمة لبينغ على هذا، ولكن أرى أنك على حد سواء كونها مشاركة نشاطا من المشروع هنا. أي تحديثات للهدف الأساسي من هذه التذكرة؟

الحصول على محادثة جيدة مع الإنشاءات المتزايدة وكيف يمكن تسليمها https://twitter.com/dominicfallows/status/1169152367964643328؟s=19

الحصول على محادثة جيدة مع الإنشاءات المتزايدة وكيف يمكن تسليمها https://twitter.com/dominicfallows/status/1169152367964643328؟s=19

TLDR ؛

أكد KyleAMathews أن Gatsby يعمل على ميزات بناء تدريجية مستضافة في Gastsby Cloud.

إصدار "Gatsby Enterprise" المُستضاف ذاتيًا / محليًا ، مع إنشاءات تدريجية ، ممكن ، لكنهم لا يعملون عليه بعد ...

Dominic Fallows - 4 سبتمبر - يقدم معظم البائعين الذين نختارهم خيار الإدارة الذاتية / في أماكن العمل ، كما يفعل Gatsby OSS. يسعدنا أن ندفع مقابل ذلك ، كما نفعل مع حل Gatsby Enterprise Cloud المحلي منك.

كايل ماثيوز - 4 سبتمبر - نعم بالتأكيد - لدينا مسار واضح تمامًا لدعم الإصدارات الأولية لما نقوم به - كل ذلك Kubernetes لذا يجب أن يكون ممكنًا - لكن onprem يضيف الكثير من النفقات العامة عندما نعمل في البداية فقط على شحن شيء يعمل 😅

دومينيك فالوز - 4 سبتمبر - هذه أخبار سارة للاستماع إليها! آسف إذا فاتني ذلك الذي تمت مناقشته في مكان آخر ، لكن خارطة الطريق الأولي هذه ستكون مفيدة للغاية للشركات والمطورين على حد سواء.

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

إنه لأمر مؤسف لأنه يمنع استخدام Gatsby كأداة للناشرين حيث نتحدث عن ملايين الصفحات الأساسية وأخرى مماثلة أو صفحات مفهرسة.

ألن يكون من المنطقي "إخراج" حالة الاستخدام هذه كمشروع منفصل باستخدام نفس المفاهيم / الأساسية؟

صنع أو كسر ميزة لقرارات 2020. يبدو أنه مكان جيد لاستثمار كل أموال رأس المال الاستثماري 😀

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

نتفق مع أعلاه! يتم دمج Gatsby في حل تدوين سريع وسهل أو ينفذ عمليات إنشاء تدريجية / أسرع ويصبح جاهزًا للمؤسسات.

صحيح تماما؛ تتصادم مع هذا مرارًا وتكرارًا في مشاريع أكبر. بدون الإنشاءات الإضافية ، لا يعد Gatsby خيارًا.

يعمل البناء الإضافي على Gatsby Cloud على إصلاح هذه المشكلات. يمكنك الاشتراك في النسخة التجريبية الخاصة هنا https://www.gatsbyjs.com/builds-beta/

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

سأكون قلقًا بشأن الإيحاء بأن الإنشاءات الإضافية ستكون متاحة فقط على خدمة Gatsby المستضافة بدلاً من كونها متاحة للاستخدام بشكل مستقل.

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

يجب على المستثمرين استعادة أموالهم بطريقة ما. 🙄

محاولة بناء موقع كبير جدا 140 ألف + صفحات

gatsby build جيد إلى حد ما ... لكن إجراء النشر مؤلم (zeit.co)

لست متأكدًا من كيفية إضافة تصنيف إلى هذا ، لكنني أضع هذا الأمر على أنه لا يزال يمثل مشكلة.

gomflo هل هناك طريقة يمكنني من خلالها بناء موقعك؟ قد يكون هناك بعض الثمار المعلقة لحلها لتحسين أوقات البناء :) لا وعود.

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

سأكون قلقًا بشأن الإيحاء بأن الإنشاءات الإضافية ستكون متاحة فقط على خدمة Gatsby المستضافة بدلاً من كونها متاحة للاستخدام بشكل مستقل.

إعادة هذا ^: إذا كان gatsby repo موجودًا في gitlab وليس github ، فهل سأتمكن من استخدام ميزات gatsby cloud / build؟

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

فهل سيكون لدينا تحديث جزئي مستقل أم لا توجد فرص؟ ربما هناك طريقة أخرى لتحديث بضع صفحات فقط وعدم إعادة بناء المشروع بأكمله؟

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

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

إليكم العلاقات العامة https://github.com/gatsbyjs/gatsby/pull/20785

مزيد من التحديث للعلاقات العامة: https://github.com/gatsbyjs/gatsby/pull/20785#issuecomment -579355927

علاقات عامة جديدة ، مع التركيز على التغييرات الإضافية في البيانات https://github.com/gatsbyjs/gatsby/pull/21523

مع دمج # 21523 وإتاحة الإنشاءات الإضافية في Gatsby Cloud ، أعتقد أن هذه المشكلة قد تم حلها. إنه لا يدعم جميع عمليات سير العمل ، لكنني سأغلق هذا الآن وقد يكون من الأفضل فتح مشكلة جديدة في المستقبل للمساعي المستقبلية إذا لزم الأمر.

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

هل يجب إغلاقها حقًا؟

استنادًا إلى https://github.com/gatsbyjs/gatsby/issues/5496#issuecomment -641005662 ، لا أعتقد أن هذه المشكلة يجب أن تظل مغلقة ، ولا أفهم سبب إزالة التصنيف not stale .

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