مراجعة Puppeteer 24.16: أتمتة للمتصفح بتركيز على Chrome من دون تنسيق للزحف

Puppeteer مكتبة Node من Google لتشغيل متصفح Chrome حقيقي من جافاسكربت — أنت تكتب الأتمتة، وChrome DevTools Protocol ينقل الأوامر، ومتصفح كامل يعرض الصفحة قبل أن تقرأ منها بايتًا واحدًا. تعيش عند puppeteer/puppeteer على GitHub: مرخّصة بـ Apache-2.0، مكتوبة بـ TypeScript، وتحمل نحو 95.3 ألف نجمة (95,307 يوم أخذت اللقطة). موقعها الرسمي مقتضب عن قصد — "واجهة جافاسكربت للتحكم بـ Chrome (وتجريبيًا Firefox)" — وهي عبارة تخبرك ما هي، وبنفس القدر من الفائدة، ما ليست عليه.

شغّلت Puppeteer 24.16.0 عبر نفس خادم fixture والعروض العامة التي نستخدمها لكل مكتبة أتمتة متصفح: كتالوج ثابت بترقيم صفحات، ومقال، وكتالوج مُعروض عبر جافاسكربت، وJSON API، ومسار يعيد 500، ورسم بياني صغير للزحف، بالإضافة إلى Books to Scrape وQuotes to Scrape. أدت مهمة العرض بنظافة ودون مبالغة. لكنها تركت مهمة واحدة بالضبط على مكتبي — نفس المهمة التي تتركها كل مكتبة متصفح بلا واجهة — والصدق بشأن تلك الفجوة هو معظم ما يفصل مراجعة مفيدة عن بيان صحفي.

برز رقم واحد أكثر من أرقام الاسترجاع نفسها. في صفحة يصل محتواها من endpoint بصيغة JSON، استخرجت Puppeteer السجلات الثمانية كاملة دون استخراج من DOM إطلاقًا — شغّلت fetch داخل الصفحة وقرأت كائن الاستجابة مباشرة. هذا، إلى جانب العرض الأصلي مع لقطات شاشة تعمل، هو شكل الأداة الحقيقي: محرك عرض Chrome ناضج، لا إطار عمل زحف، والفرق مهم قبل أن تكتب سطرًا واحدًا.

ما هي Puppeteer فعليًا (وماذا تنافس)

تصنيف الفئة يقوم بعمل حقيقي هنا، فلنبدأ به. Puppeteer هي مكتبة أتمتة متصفح. تُشغّل Chrome، وتفتح الصفحات، وتترك جافاسكربت الصفحة يعمل، ثم تسلّمك النتيجة المُعروضة لتقرأها أو تلتقط لها لقطة شاشة. هذا هو السبب الكامل وراء اللجوء إليها بدلاً من عميل HTTP مع مُحلِّل HTML: تريد الصفحة بعد تنفيذ سكربتاتها، لا القالب الفارغ الذي يرسله الخادم أولاً.

من حيث الشكل، تنافس مكتبات المتصفح الحقيقي الأخرى — Playwright وSelenium — لا أطر عمل الزحف مثل Scrapy ولا أدوات تحويل إلى Markdown لنماذج اللغة. إن وجّهت Puppeteer إلى ألف رابط وتوقعت أن تُصفّهم في طابور، وتزيل تكرارهم، وتضبط سرعتهم بأدب، وتكتب مجموعة بيانات، فأنت أحضرت محرك عرض لمشكلة زحف. ستعرض كل صفحة بشكل جميل ولن تدير أي تنسيق. (هذا حد نطاق، لا خلل — سأعود إليه، لأنه أهم شيء يجب استيعابه قبل تبني الأداة.)

خرجت Puppeteer من فريق Chrome في Google، ولهذا فهي مُصمَّمة لتُقدِّم Chrome أولاً، ولهذا تُقرَأ واجهتها كقفاز رفيع مُستعمَل جيدًا فوق بروتوكول التصحيح الخاص بالمتصفح نفسه. إنها قديمة بما يكفي لتكون مملة بالمعنى الجيد: الدوال التي تحتاجها مستقرة منذ سنوات، والتوثيق شامل، والنظام البيئي حولها عميق.

العرض الأصلي ونمط fetch داخل الصفحة

سلوكان يستحقان الإبراز من جدول النتائج لأنهما يحددان كيف ستستخدم الأداة فعليًا.

أولاً، العرض الأصلي. عاد الكتالوج المُعروض عبر جافاسكربت — صفحة تبني شبكة منتجاتها على جانب العميل بعد التحميل — بنتيجة 8/8، مع لقطة شاشة كاملة للصفحة محفوظة على القرص. كان الإعداد بسيطًا لكنه تضمّن انتظار المحتوى الهدف بعد goto. أعادت صفحة Quotes to Scrape JS العامة كل الاقتباسات العشرة بنفس النمط. هذه نتائج fixture، لا درجة استرجاع عرض عامة.

ثانيًا، حمّل fixture الخاص بـ JSON API منتجات من /api/dynamic-products. تشغيل fetch من نفس الأصل عبر page.evaluate أعاد السجلات الثمانية كاملة دون تحليل صفوف مُعروضة. هذا نمط تقييم متصفح عام، لا ميزة اكتشاف خاصة بـ Puppeteer. يمكنه تبسيط الاستخراج حين تكون endpoint وعقد الطلب معروفَين؛ لكن ترويسات المصادقة، وtokens وقت التشغيل، وسياسة credentials، وCORS/CSP، وservice workers، والترقيم قد تجعل طلب التطبيق مختلفًا رغم ذلك.

الشيء الثالث الذي يجب حمله معك ليس رقمًا بل إطارًا: Puppeteer محرك عرض Chrome ناضج، وهي ليست زاحفًا. كلا النصفين صحيح، والنصف الثاني هو ما تتجاهله معظم المقالات.

كيف تتحدث Puppeteer مع Chrome

على Chrome، تستخدم Puppeteer Chrome DevTools Protocol (CDP)، وهو قناة JSON عبر WebSocket تستخدمها أدوات تطوير المتصفح نفسها. يبدأ puppeteer.launch() تشغيل Chrome ويفتح اتصال ذلك البروتوكول؛ وتكشف استدعاءات مثل goto و$$eval وscreenshot عمليات المتصفح عبر واجهة أعلى مستوى. يتبع دعم Firefox مسار WebDriver BiDi الموصوف أدناه، لذا ليست كل عملية في Puppeteer أمر CDP بالضرورة.

يُشغّل page.evaluate دالة داخل سياق الصفحة، لذا يستخدم fetch('/api/...') النسبي أصل تلك الصفحة وقد يعيد استخدام الكوكيز وحالة الجلسة المؤهَّلة. لكنه لا يُعيد إنتاج ترويسات التفويض التي يصنعها التطبيق، ولا خيارات الطلب، ولا tokens، ولا سلوك service worker تلقائيًا. في هذا الـ fixture من نفس الأصل أعاد JSON مباشرة؛ أما طلبات الإنتاج فتحتاج فحص عقدها الفعلي.

وهذا أيضًا سبب ثقل Puppeteer. كل صفحة تبويب متصفح حقيقي خلفه محرك عرض حقيقي. هذا يمنحك الدقة في الصفحات الثقيلة بجافاسكربت، ويكلّفك ذاكرة وزمن بدء تشغيل مقارنة بجلب HTTP فقط. لا يوجد عرض مجاني؛ CDP فقط يجعل الفاتورة واضحة للقراءة.

سؤال المحرك، بصراحة

هناك اختصار شائع يقول إن Puppeteer "حصرية لـ Chrome". بالنسبة للإصدار الذي اختبرته، هذا غير صحيح، وتصحيحه يغيّر المقارنة.

كتب كل من Chrome for Developers وMozilla عن تحوّل Firefox عند صدوره. الإصدار الذي شغّلته، 24.16.0، متقدم بوضوح على v23، لذا فإن "حصرية لـ Chrome" تُقلِّل مما يأتي فعليًا في الصندوق. غياب WebKit، إلى جانب حداثة قصة تعدد المحركات نسبيًا مقارنة بـ Playwright، هو الفارق الحقيقي في الاتساع — لا "محرك واحد مقابل ثلاثة".

مسار Firefox/BiDi موثَّق ومتاح في الإصدار الذي اختبرته، لكنني لم أشغّل fixtures الخاصة بي عبره، لذا أُبلغ عن قدرة، لا قياس. إن كان عرض Firefox عنصرًا حاسمًا لأهدافك، تحقق منه على صفحاتك الخاصة قبل الالتزام. للقراء الذين يريدون المقارنة الكاملة وجهًا لوجه في نطاق المحرك واللغة، تُشغّل مقارنتنا بين Playwright وPuppeteer المكتبتين عبر نفس الاختبارات وتحسم سؤال "أيهما" هناك؛ أما هنا فالموضوع Puppeteer وحدها.

واقع الإعداد والتثبيت: المتصفح هو الجزء الثقيل

يُنزِّل مسار npm install puppeteer الافتراضي إصدار Chrome for Testing متوافقًا. يمكن تخطي هذا السلوك أو إعادة توجيهه عبر الإعداد، ويمكن للمستخدمين توجيه Puppeteer إلى ملف تنفيذي آخر، لذا تعتمد مطابقة الإصدار على خيار النشر. كان تنزيل المتصفح أثقل جزء في هذا التثبيت؛ ولا تُعامَل لقطة تدقيق مدير الحزم كخاصية أمنية دائمة.

هذا التجميع التلقائي مكسب راحة حقيقي وتكلفة حجم حقيقية، ويستحق ذكر الجانبين. المكسب: لا تبحث عن متصفح متوافق ولا تُثبِّت الإصدارات يدويًا؛ يمنحك npm install زوجًا يعمل مباشرة. التكلفة: أنت تنزّل متصفحًا كاملاً، فخصّص له مساحة قرص وعرض نطاق، خصوصًا في CI حيث تدفع ذاكرة التخزين المؤقت الباردة هذا الثمن مع كل مُشغِّل جديد.

وهذا أيضًا تباين حقيقي مع Playwright، التي تفصل الخطوتين — تُثبِّت المكتبة، ثم تُشغِّل npx playwright install منفصلاً لجلب إصدارات متصفحها. لا أحد الأسلوبين مؤلم؛ إنهما فقط يفشلان بطرق مختلفة. أمر Puppeteer الواحد قد يفاجئك بحجمه على اتصال محدود، بينما خطوة Playwright الثانية قد تفاجئك بأن تُنسى. اعرف أيًا منهما تُشغِّل.

نتائج التجربة العملية

شُغِّل كل اختبار مقابل خادم fixture محلي على 127.0.0.1 بالإضافة إلى موقعي تدريب عامَّين، على Node v22.22.3، macOS arm64، مع Puppeteer 24.16.0 وChrome المُرفَق بها. سُجِّلت الحقيقة المرجعية لكل fixture قبل التشغيل، لذا يُقاس الاسترجاع مقابل مجموعة متوقعة ثابتة لا مقابل أي شيء طبعته Puppeteer بالصدفة.

تتضمن حزمة البحث العامة خادم fixture، ومُشغِّل الاختبارات، والحقيقة المرجعية. حُجب lockfile وملخص التشغيل الخام عمدًا عن حزمة النشر لأن المراجعة الأمنية الصارمة رفضت بيانات lockfile ومواد endpoint الخاصة بالبيئة. لإعادة إنتاج الـ fixture المحلي الآمن، شغّل npm install ثم node run_puppeteer_material_tests.mjs داخل tools/puppeteer/tests، ثم قارن النتيجة بالحقيقة المرجعية المنشورة. يمكن أن تتغيّر صفحات العرض العامة، لذا فإن الـ fixture المحلي هو الأساس المستقر لفحوصات العدد المتوقع.

لإعادة بناء تاريخي دقيق للاعتماديات، أنشئ وراجع lockfile جديدًا محليًا بدلاً من معاملة lockfile غير منشور كدليل عام.

بعض هذه النتائج يستحق جملة إضافية خارج الجدول.

استرجع كود الترقيم الذي كتبته كل عناصر الكتالوج المتوقعة الاثني عشر. استرجع مُحدِّد المقال العنوان وثلاث فقرات متن متوقعة؛ وبقي المحتوى المحيط الزائد متاحًا في DOM. وفّرت Puppeteer DOM المُعروض، بينما حدد منطق المُحدِّد — لا Puppeteer نفسها — ما يُحسَب محتوى مقال.

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

رسم الزحف البياني هو ما يروي القصة كاملة. المشي عبر روابط fixture الداخلية إلى 12 صفحة، مع تتبع العمق حتى لا أعيد زيارة روابط، احتاج بحثًا بالعرض أولاً مكتوبًا يدويًا — لأن Puppeteer لا تملك طابور زحف مُدمَجًا. وجد كل الصفحات الاثني عشر عبر الأعماق {0:1, 1:4, 2:7}، أي أن BFS الخاص بي نجح. لكن BFS كان لي أنا. عرضت Puppeteer كل صفحة؛ أما منطق المشي عبر الموقع فكان كودًا كتبته بنفسي. لاثني عشر صفحة هذا عشرات الأسطر ولا يشكّل عبئًا. أما لآلاف الروابط مع إزالة تكرار، وإعادة محاولات، وتأخيرات أدب، فتلك العشرات من الأسطر تتحول إلى مشروع كامل.

تحفّظ سأكرره لأنه سهل إساءة الاستخدام: تتضمن المخرجات توقيتات لكل اختبار، لكنها ملاحظات من تشغيلة واحدة وجهاز واحد، لا معايير أداء. لا أُصنِّف سرعة Puppeteer مقابل أي شيء بناءً على حاسوب محمول واحد وتشغيلة واحدة. ما تدعمه الأرقام هو الاسترجاع والسلوك عبر ثمانية أنواع صفحات مختلفة — لا ادعاء توقيت.

ما لم أختبره

حتى لا تُقرَأ النتائج على أنها أوسع مما هي عليه، إليك ما بقي خارج نطاق التشغيل، وبالتالي خارج هذه الأرقام:

ولا شيء من هذا انتقاد. إنها حدود ما يمكن لتشغيلة fixture واحدة أن تدّعيه بصدق.

الإيجابيات والسلبيات

الإيجابيات:

• عرض جافاسكربت أصلي مع انتظار صريح للمحتوى: 8/8 على fixture الديناميكي وكل الاقتباسات العشرة على العرض العام، مع لقطات شاشة.
• استرجعت مُحدِّدات الترقيم والمقال التي كتبتها عناصر fixture المتوقعة.
• أعاد fetch داخل الصفحة السجلات الثمانية كاملة من endpoint معروف بنفس الأصل دون تحليل DOM.
• عاد HTTP 500 المُختبَر كاستجابة قابلة للفحص دون استثناء.
• يُنزِّل التثبيت الافتراضي إصدار Chrome for Testing متوافقًا؛ ويبقى ممكنًا تحديد ملف تنفيذي بديل أو تخطي التنزيل.
• واجهة ناضجة مُركَّزة على Chrome فوق CDP، مع نظام بيئي عميق وتوثيق شامل. مرخّصة بـ Apache-2.0.
• أوسع من سمعتها: دعم Firefox موثَّق عبر WebDriver BiDi منذ v23.

السلبيات:

• لا طابور زحف مُدمَج، ولا كاتب مجموعة بيانات، ولا ضبط سرعة — الزحف على نطاق واسع يحتاج كودك الخاص أو غلافًا خارجيًا.
• لا محرك WebKit، وقصة تعدد المحركات فيها أحدث من قصة Playwright.
• وزن متصفح حقيقي: Chrome مُرفَق يجب تنزيله وتكلفة ذاكرة لكل صفحة مقارنة بأدوات HTTP فقط.
• قائمة على Node؛ استخدامها من لغة أخرى يعني بناء جسر وصيانته.
• الإصدار الذي شغّلته (24.16.0) متأخر بإصدار رئيسي عن أحدث إصدار على npm (25.3.0) — أعد التحقق على الإصدار الحالي قبل الوثوق بأرقام دقيقة.

لمن تناسب، ومن يجب أن يتجاوزها

الجأ إلى Puppeteer إن كنت تعيش في Node، وأهدافك تُعرَض بشكل جيد على Chrome (كما تفعل معظمها)، وتريد مكتبة ناضجة ومُركَّزة تحوّل "الصفحة بعد تنفيذ جافاسكربتها" إلى شيء يمكنك قراءته والتقاط لقطة له. لاستخراج مجموعة صفحات ديناميكية، أو جلب JSON API بجلسة الصفحة نفسها، أو التقاط لقطات شاشة كإثبات، فهي خيار افتراضي قوي وقليل الدراما. خيار Firefox عبر BiDi موجود إن كبرت حاجتك إليه، والنظام البيئي يعني أن معظم المشاكل التي ستواجهها قد واجهها غيرك من قبل.

فكّر مرتين إن كانت مشكلتك تنسيق الزحف لا العرض. إن احتجت المشي عبر مئات أو آلاف الروابط مع إزالة تكرار وإعادة محاولات وحدود معدل، فستجد نفسك مع Puppeteer وحدها تعيد بناء زاحف يدويًا — وهذا ليس المستوى الصحيح لها. تجاوز المتصفح بلا واجهة كليًا إن لم تكن صفحاتك بحاجة فعلية إلى جافاسكربت لكشف بياناتها؛ فحين يُعيد طلب HTTP ومُحلِّل المحتوى، يصبح المتصفح الحقيقي مبالغة مكلفة تستهلك الذاكرة وزمن الإعداد فقط. وإن احتجت دقة WebKit أو عميلًا بلغة غير جافاسكربت، فهذه ليست الأداة المناسبة لذلك المحور.

البدائل، وأين تناسب Thunderbit

الإطار الصادق أولاً: Puppeteer مجانية، مرخّصة بـ Apache-2.0، مُستضافة ذاتيًا، وأنت تملك كل جزء من تشغيلها — أسطول المتصفحات، وكود الزحف الذي تضيفه، وسباق التسلح المستمر ضد أدوات مكافحة البوتات. لكثير من المشاريع هذه الملكية هي الخيار الصحيح تمامًا، ولن تعرض أي خدمة مُدارة صفحة مُصرَّح بها بتكلفة أقل من متصفح تملكه أصلاً.

ضمن المصادر المفتوحة، المقارنات المفيدة تكون حسب المهمة، لا حسب الاسم. للزحف على نطاق واسع تحديدًا، Crawlee هي الرفيق الطبيعي: يُغلِّف PuppeteerCrawler الخاص بها Puppeteer بطابور الطلبات ومجموعة البيانات وضبط السرعة التي تتجاهلها المكتبة عمدًا، فتحتفظ بالعرض وتحصل على التنسيق. إن كان هدف مُخرجك Markdown نظيفًا لـ pipeline نموذج لغة بدلاً من DOM مُعروض، فإن Crawl4AI تُشغّل متصفحًا حقيقيًا وتنتج ذلك بالضبط. إن كانت صفحاتك لا تحتاج متصفحًا إطلاقًا، فإن إطار عمل يعتمد على HTTP أولاً مثل Scrapy فئة مختلفة وأخف. وحين تُقارن عدة خيارات من هذه دفعة واحدة، يعرض استعراضنا لأدوات الزحف مفتوحة المصدر الفئات جنبًا إلى جنب.

خدمة مُدارة مثل Thunderbit تنقل تشغيل المتصفح والاستخراج خلف واجهة API. لم تُشغَّل عبر fixtures Puppeteer هذه، لذا لا تقدّم هذه المراجعة أي ادعاء مقارَن بخصوص العرض، أو تجاوز الحظر، أو جودة الاستخراج، أو التكلفة. حد القرار هو الملكية التشغيلية: صيانة كود المتصفح والزحف بنفسك، أو دفع مقابل لمزوّد ليدير جزءًا من تلك الطبقة.

مع Puppeteer لا توجد رسوم استخدام لمزوّد، لكن الحوسبة وعرض النطاق وصيانة المتصفح والتنسيق والعمليات تبقى كلها مسؤوليتك. المسار المُدار يتقاضى رسومًا مقابل الاستخدام وينقل جزءًا من تلك المسؤولية إلى المزوّد. لم تُقارن هذه التجربة النتائج بين المسارين.

جرّب Thunderbit لاستخراج بيانات الويب

الخلاصة

تستحق Puppeteer 24.16.0 التقييم إن كنت في Node وتحتاج أتمتة متصفح تُقدِّم Chrome أولاً. استرجع كود fixture الذي كتبته 12 عنصرًا ثابتًا، وثمانية عناصر ديناميكية، وعشرة اقتباسات من عرض عام؛ وأعادت API المعروفة من نفس الأصل ثمانية سجلات عبر page.evaluate؛ وعملت لقطات الشاشة؛ وبقي HTTP 500 المُختبَر قابلاً للفحص. هذه النتائج تخص هذه الـ fixtures المحدَّدة وإصدارًا رئيسيًا أقدم، لا استرجاع الاستخراج عمومًا.

لكن قيّم الادعاءات بحجمها الصحيح. Puppeteer محرك عرض، لا زاحف: تطلّب مشيي عبر 12 صفحة BFS مكتوبًا يدويًا لأنه لا يوجد طابور مُدمَج، وعلى نطاق واسع تصبح هذه الفجوة عملاً حقيقيًا — سلّمه لـ Crawlee أو ابنِ الآلية بنفسك. إنها تُقدِّم Chrome أولاً مع دعم Firefox موثَّق عبر BiDi لكن دون WebKit، فليست الأداة المناسبة لاتساع تعدد المحركات. وتحمل وزن متصفح حقيقي. واختبرت 24.16.0 مقابل أحدث إصدار 25.3.0، فأعد التشغيل على الإصدار الحالي قبل الوثوق بأرقام دقيقة. اعرف هذه الأمور الأربعة مسبقًا وستكون Puppeteer مكتبة أتمتة Chrome ممتازة. أما إن توقعت أن تزحف موقعًا كاملاً نيابة عنك، فستجد نفسك تكتب الزاحف الذي ظننت أنك نزّلته جاهزًا.

جرّب Thunderbit لاستخراج بيانات الويب Get Started Free

الأسئلة الشائعة

هل تعرض Puppeteer صفحات جافاسكربت، أم أحتاج إضافة؟ تعرضها أصليًا، دون أي إضافة. في fixture الديناميكي الخاص بي، أعادت 8 من أصل 8 منتجات مبنية على جانب العميل بـ recall يساوي 1.0 مع لقطة شاشة كاملة للصفحة، وأعادت صفحة Quotes to Scrape JS العامة كل الاقتباسات العشرة بنفس الطريقة — goto بسيط، ثم قراءة DOM المُعروض. لأن Puppeteer تُشغّل Chrome حقيقيًا عبر DevTools Protocol، تُنفَّذ سكربتات الصفحة فعليًا قبل أن تقرأ أي شيء.

هل يمكن لـ Puppeteer استخراج JSON API دون تحليل HTML؟ نعم، حين يسمح endpoint وعقد الطلب بذلك. يمكن لـ page.evaluate إصدار طلب من أصل الصفحة وقد يعيد استخدام الكوكيز المؤهَّلة، لكنه لا يُعيد إنتاج ترويسات التطبيق أو tokens أو الخيارات أو سلوك service worker تلقائيًا. في fixture من نفس الأصل أعاد السجلات الثمانية كاملة دون تحليل DOM.

هل Puppeteer زاحف ويب؟ لا — إنها مكتبة أتمتة متصفح، لا إطار عمل زحف. لا يوجد طابور طلبات مُدمَج، ولا كاتب مجموعة بيانات، ولا ضبط سرعة، لذا احتاج زحفي عبر 12 صفحة (بالأعماق {0:1, 1:4, 2:7}) بحثًا بالعرض أولاً مكتوبًا يدويًا. هذا حد نطاق، لا خلل. للزحف على نطاق واسع، اقرنها بغلاف مثل PuppeteerCrawler من Crawlee، الذي يضيف آلية الطابور ومجموعة البيانات التي تتركها Puppeteer خارج نطاقها.

هل Puppeteer حصرية لـ Chrome؟ لم تعد كذلك. تُقدِّم Chrome أولاً عبر CDP، لكن منذ v23 صار لديها دعم Firefox موثَّق عبر WebDriver BiDi، والإصدار الذي اختبرته (24.16.0) متقدم بوضوح على ذلك. ما لا تُشغّله هو WebKit، وقصة تعدد المحركات فيها أحدث من قصة Playwright — هذا، لا "حصرية لـ Chrome"، هو القيد الدقيق. اختبرت Chrome فقط هنا، لذا أُبلغ عن Firefox عبر BiDi كموثَّق، لا كشيء قسته.

ماذا يُنزِّل تثبيت Puppeteer فعليًا؟ افتراضيًا، يُنزِّل npm install puppeteer إصدار Chrome for Testing متوافقًا. يمكن تخطي التنزيل أو إعادة توجيهه، ويمكن إعداد ملف تنفيذي آخر، لذا تعتمد مطابقة الإصدار على خيارات النشر. خصّص مساحة قرص وعرض نطاق للمتصفح، خصوصًا على مُشغِّلات CI بلا ذاكرة تخزين مؤقت. اختبرت هذه المراجعة 24.16.0؛ أعد تشغيل الـ fixtures الأساسية على الإصدار الحالي وقت النشر.