Next.js 16 Turbopack Production Builds: ما تغير وكيفية هجرتنا

كنا نراقب نضج Turbopack منذ إعلانه في عام 2022، وقمنا بتشغيله في وضع التطوير منذ Next.js 14، وننظر بحذر إلى أعلام "turbo" في CI. عندما وصل Next.js 16 في أوائل عام 2025 مع Turbopack كحزمة الإنتاج الافتراضية، علمنا أن الهجرة لا يمكن أن تنتظر أي وقت أطول. كان لدينا ثلاثة مشاريع عملاء على Next.js 15 تحتاج إلى ترقية، وسأساعدك في المرور عبر كل تغيير مهم، والمشاكل التي واجهتنا، وأرقام الأداء التي رأيناها في النهاية.

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

جدول المحتويات

• لماذا Next.js 16 مهم جداً
• ما الذي تغير فعلاً مع Turbopack في الإنتاج
• معايير أداء البناء
• التغييرات التي تكسر الإجراءات التي تحتاج إلى معرفتها
• عملية الهجرة الخاصة بنا خطوة بخطوة
• ترجمات إعدادات Webpack
• التعامل مع الحزم التابعة لجهات خارجية
• اعتبارات CSS و Tailwind
• تحديثات النشر وخط أنابيب CI
• عندما لا يجب أن تهاجر حتى الآن
• الأسئلة الشائعة

لماذا Next.js 16 مهم جداً

Next.js 16 ليس مجرد رقم إصدار. إنه يمثل أكبر تغيير في بنية البناء منذ انتقال الإطار من pages إلى App Router. ميزة العنوان واضحة: يستبدل Turbopack webpack كحزمة افتراضية لكل من بناء التطوير والإنتاج.

لكن هناك المزيد. يأتي Next.js 16 أيضاً مع:

• React 19 كإصدار مدعوم الحد الأدنى — لا مزيد من توافق React 18
• بث محسّن ومرونة تصيير جزئية نضج
• افتراضيات تخزين مؤقت جديدة معقولة فعلاً (تعلموا من رد فعل تخزين Next.js 15 المؤقت)
• بمراجع API غير متزامنة مفروضة بالكامل — cookies()، headers()، و params جميعها غير متزامنة الآن مع دعم موروث متزامن صفر
• متطلب Node.js 20 الحد الأدنى — دعم Node 18 ولى

بالنسبة لوكالات مثل وكالتنا التي تقوم بـ تطوير Next.js، هذا هو نوع الإصدار الذي يلمس كل شيء. لا يمكنك فقط زيادة رقم الإصدار والاتصال بها في اليوم.

ما الذي تغير فعلاً مع Turbopack في الإنتاج

دعنا نكون محددين. خلال Next.js 14 و 15، كان Turbopack متاحاً لـ next dev مع العلم --turbo. بناء الإنتاج لا يزال يستخدم webpack. قدم Next.js 15.3 علم --turbopack تجريبي لـ next build، وبحلول الوقت الذي وصل 16، أصبح الافتراضي.

إليك ما يختلف بشكل أساسي حول كيفية تعامل Turbopack مع عمليات الإنتاج مقارنة بـ webpack:

معمارية التجميع الإضافية

يعالج Webpack رسم بياني الاعتمادية الكامل على كل بناء. يستخدم Turbopack نظام تخزين مؤقت على مستوى الوظيفة المدمج في محرك Turbo (مكتوب بـ Rust). في الممارسة العملية، هذا يعني أن عمليات البناء اللاحقة تعيد ترجمة فقط ما تغير فعلاً. قد لا تكون عملية البناء الأولى أسرع بشكل كبير، لكن عمليات البناء الثانية والثالثة والعاشرة ستكون كذلك.

تحسينات استخلاص الشجرة

يعمل استخلاص شجرة Turbopack على مستوى أكثر دقة من webpack. لاحظنا أن حزم عملائنا كانت أصغر بنسبة 8-15٪ في المتوسط عبر مشاريعنا الثلاثة بدون تغييرات الأكواد. جاءت أكبر الانتصارات من معالجة ملفات البرميل — Turbopack أفضل حقاً في القضاء على إعادة التصدير غير المستخدمة من ملفات الفهرس.

دقة الوحدة

يحل Turbopack الوحدات بشكل مختلف. إنه أسرع، لكنه أيضاً أكثر صرامة. إذا كان لديك أي مسارات استيراد غير دقيقة كان webpack يحلها بصمت (مثل امتدادات الملفات المفقودة في حالات حافة معينة، أو مسارات غير حساسة لحالة الأحرف على macOS التي تكسر على Linux)، سيمسك بها Turbopack. هذا تسبب في حوالي 30٪ من مشاكل الهجرة لدينا.

استراتيجية تقسيم الرمز

خوارزمية تقسيم الأجزاء جديدة. يُنشئ Turbopack قطع أكثر وأصغر بشكل افتراضي. هذا يحسن عموماً الأداء للمتصفحات الحديثة مع HTTP/2، لكنه قد يزيد من إجمالي عدد الطلبات. رأينا تعداد الأجزاء يزداد بحوالي 40٪ بينما انخفض إجمالي حجم الحزمة.

SWC الآن إلزامي

إذا كنت لا تزال تتمسك بأي إعدادات Babel، فإنها ولت. يستخدم Turbopack حصراً SWC للتحويل. كان هذا بالفعل الاتجاه الذي كانت الأشياء تتجه إليه، لكن Next.js 16 يزيل أي بديل إلى Babel بالكامل.

معايير أداء البناء

إليك أرقام حقيقية من مشاريع الهجرة الثلاثة. هذه ليست معايير اصطناعية — إنها من تطبيقات عميل فعلية تعمل في خط أنابيب CI الخاص بنا على GitHub Actions (Ubuntu، 4 vCPU، 16GB RAM runners).

متري	المشروع أ (التجارة الإلكترونية)	المشروع ب (لوحة معلومات SaaS)	المشروع ج (موقع المحتوى)
الصفحات/المسارات	847	124	2,340
بناء webpack (Next 15)	4m 32s	1m 48s	6m 15s
بناء Turbopack (Next 16، بارد)	3m 10s	1m 22s	4m 44s
بناء Turbopack (Next 16، ذاكرة تخزين دافئة)	1m 05s	28s	1m 52s
تغيير حجم الحزمة	-12%	-8%	-14%
JS التحميل الأول (الصفحة الرئيسية)	-18KB	-7KB	-22KB
بناء ذروة الذاكرة	3.8GB → 2.9GB	1.6GB → 1.2GB	4.2GB → 3.1GB

أرقام ذاكرة التخزين المؤقت الدافئة هي القصة الحقيقية. بمجرد بناء Turbopack لمشروعك مرة واحدة، تصبح عمليات البناء الإضافية أسرع بكثير. بالنسبة لمشروعنا الثقيل المحتوى C (الذي يستخدم نظام CMS بدون رأس بآلاف الصفحات المُنشأة بشكل ثابت)، الذهاب من أكثر من 6 دقائق إلى أقل من دقيقتين في عمليات البناء المخزنة مؤقتاً كان مهماً. هذا المال الحقيقي المُوفر على دقائق CI.

كانت تحسينات استخدام الذاكرة ذات مغزى أيضاً. كان المشروع أ يصل أحياناً إلى أخطاء OOM على عدائي CI الأصغر مع webpack. اختفت هذه المشكلة مع Turbopack.

التغييرات التي تكسر الإجراءات التي تحتاج إلى معرفتها

إليك قائمة جارية لكل شيء انقطع فعلاً أثناء عمليات الهجرة لدينا. يغطي دليل ترقية Next.js 16 بعض هذه الأشياء، لكن القليل منها أخذ غير مقصود.

1. إعدادات Webpack المخصصة

هذا واحد كبير. إذا كان لديك مفتاح webpack في next.config.js، فلن يعمل بعد الآن. يحتوي Turbopack على واجهة برمجية تكوين خاصة به تحت turbopack في إعدادات Next.js. لا يوجد تعيين 1:1 لكل شيء.

// next.config.js — قبل (Next.js 15 مع webpack)
module.exports = {
  webpack: (config) => {
    config.module.rules.push({
      test: /\.svg$/,
      use: ['@svgr/webpack'],
    });
    return config;
  },
};

// next.config.js — بعد (Next.js 16 مع Turbopack)
module.exports = {
  turbopack: {
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
    },
  },
};

2. تم إزالة واجهات برمجية الطلب المتزامنة

أهملت Next.js 15 الوصول المتزامن إلى cookies()، headers()، params، و searchParams. يزيل Next.js 16 لهم تماماً. إذا تجاهلت تلك تحذيرات الاستهلاك، ستكون لديك وقت سيء.

// قبل — هذا يتعطل في Next.js 16
export default function Page({ params }) {
  const { slug } = params;
  return <div>{slug}</div>;
}

// بعد
export default async function Page({ params }) {
  const { slug } = await params;
  return <div>{slug}</div>;
}

يبدو تافهاً لكنه لمس أكثر من 200 مكون عبر مشاريعنا. كتبنا codemod للتعامل معها (المزيد حول ذلك أدناه).

3. لم يعد React 18 مدعوماً

يتطلب Next.js 16 React 19. إذا كانت لديك اعتماديات مثبتة على React 18، فتحتاج إلى تحديث. كانت معظم المكتبات المدعومة جيداً لها دعم React 19 في منتصف عام 2025، لكننا واجهنا بعض المتشددين.

4. Node.js 18 انقطع

الحد الأدنى هو Node.js 20. حدّث صور Docker وإعدادات CI و ملفات .nvmrc.

5. تغييرات next/image

تم إزالة الخاصية onLoadingComplete بالكامل (تم إهمالها منذ Next.js 14). استخدم onLoad بدلاً من ذلك. يستخدم خط أنابيب تحسين الصور أيضاً مكتبة أساسية جديدة، مما يعني أن صورك المحسّنة المخزنة مؤقتاً ستعاد إنشاؤها عند أول طلب.

عملية الهجرة الخاصة بنا خطوة بخطوة

إليك العملية الفعلية التي اتبعناها. قمنا بالمشروع B (الأصغر) أولاً كتشغيل اختبار، ثم تناولنا A و C.

الخطوة 1: تدقيق الاعتماديات

قبل لمس Next.js، دقّقنا كل اعتماد لتوافق React 19 و Node.js 20. استخدمنا سكريبت بسيط:

npx npm-check-updates --target latest --filter '/react|next/'

تحققنا أيضاً يدوياً من أهم الحزم: حزمة Headless CMS SDK ومكتبة المصادقة ومكتبة مكون UI.

الخطوة 2: تحديث Node.js

حدثنا .nvmrc الخاص بنا إلى 20.18.0 (آخر LTS في الوقت)، وحدثنا Dockerfiles، والتحقق من عدائي CI. بسيط لكن سهل النسيان.

الخطوة 3: ترقية React أولاً

npm install react@19 react-dom@19 @types/react@19 @types/react-dom@19

قمنا بتشغيل مجموعة الاختبار الكاملة هنا قبل المتابعة. React 19 له تغييرات فاصلة خاصة به (إزالة forwardRef كضرورة، ref هي الآن دعامة عادية، خطاف use() مستقر). أصلحنا تلك المشاكل في الانقسام بحيث لم نكن نتصحح مشاكل React و Next.js في نفس الوقت.

الخطوة 4: تشغيل Codemod التحديث Next.js

توفر Next.js codemod ترقية يتعامل مع الكثير من التغييرات الميكانيكية:

npx @next/codemod@latest upgrade

تعاملت مع حوالي 70٪ من هجرات API غير المتزامنة تلقائياً. ليست مثالية — تكافحت مع بعض أنماط مكون الخادم الأكثر تعقيداً — لكنها وفرت لنا ساعات.

الخطوة 5: ترقية Next.js

npm install next@16

الخطوة 6: ترجمة next.config.js

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

الخطوة 7: إصلاح أخطاء البناء بشكل متكرر

قمنا بتشغيل next build وعملنا من خلال الأخطاء واحداً تلو الآخر. رسائل الخطأ من Turbopack أفضل فعلاً من webpack's في معظم الحالات — أكثر تحديداً، مع مسارات ملفات أوضح واقتراحات.

الخطوة 8: اختبار الانحدار البصري

نستخدم Playwright لاختبارات E2E وقمنا بتشغيل مجموعة الانحدار البصري لاستخلاص أي اختلافات في الرسم. وجدنا مشكلتين: فرق ترتيب CSS (يعالج Turbopack استيراد CSS بترتيب مختلف قليلاً عن webpack) واستيراد ديناميكي لم يكن ينقسم الكود بشكل صحيح.

الخطوة 9: التحقق من الأداء

قارننا نتائج Lighthouse و Core Web Vitals قبل وبعد. تحسن كل مشروع أو بقي محايداً. لا تراجع.

ترجمات إعدادات Webpack

هذا القسم للفريق الذي يحتوي على إعدادات webpack المخصصة. إليك كيفية ترجمة الأنماط الشائعة إلى Turbopack.

محملات مخصصة

// معادل Turbopack للمحملات المخصصة
module.exports = {
  turbopack: {
    rules: {
      '*.md': {
        loaders: ['raw-loader'],
        as: '*.js',
      },
      '*.graphql': {
        loaders: ['graphql-tag/loader'],
        as: '*.js',
      },
    },
  },
};

أسماء مستعارة وحدة

// لا تزال أسماء مستعارة الدقة تعمل بشكل مشابه
module.exports = {
  turbopack: {
    resolveAlias: {
      'old-package': 'new-package',
      // يمكنك أيضاً الإشارة إلى الملفات المحلية
      '@legacy/utils': './src/utils/legacy.ts',
    },
  },
};

ما لا يترجم

بعض مكونات webpack ببساطة لا تملك معادلات Turbopack حتى الآن:

• webpack.DefinePlugin — استخدم env في next.config.js أو متغيرات البيئة مباشرة
• BundleAnalyzerPlugin — تعمل حزمة @next/bundle-analyzer مع Turbopack اعتباراً من v16، لكن تنسيق الإخراج تغيّر
• تقسيم الأجزاء المخصصة عبر splitChunks — يتعامل Turbopack مع هذا تلقائياً ولا يفضح نفس مستوى التحكم. صراحة، الافتراضيات جيدة بما يكفي لمعظم المشاريع.
• webpack.IgnorePlugin — استخدم resolveAlias للإشارة إلى الاستيراد للوحدات الفارغة

التعامل مع الحزم التابعة لجهات خارجية

تسببت بعض الحزم في مشاكل أثناء الهجرة:

@sentry/nextjs — احتاج إلى v9+ لتوافق Turbopack. الإصدارات السابقة انضمت إلى داخليات webpack. كان الترقية مباشرة لكنه تطلب تغييرات الإعدادات.

next-intl — عمل بشكل جيد بعد التحديث إلى أحدث إصدار. تعديل API متكيف بنظافة.

@vanilla-extract/next-plugin — كانت هذه أكبر صداع لدينا على المشروع B. لم يكن لدى مكون Vanilla Extract webpack نموذج Turbopack حتى إصدار 2.0 الخاص بهم. اضطررنا إلى الانتظار لذلك أو النظر في البدائل. انتظرنا.

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

اعتبارات CSS و Tailwind

إذا كنت تستخدم Tailwind CSS (ومعظم مشاريعنا تفعل)، فإن الهجرة سلسة في الغالب. يعمل Tailwind v4 بشكل رائع مع Turbopack. لكن هناك بعض الأشياء التي يجب الحذر منها:

ترتيب استيراد CSS

يعالج Turbopack استيراد CSS بطريقة حتمية لكن مختلفة عن webpack. إذا كنت تعتمد على ترتيب الاستيراد للخصوصية (وأنت لا يجب أن تكون، لكن دعنا نكون صادقين — نصل جميعاً إلى هناك في بعض الأحيان)، قد ترى اختلافات بصرية. كان لدينا مشروع واحد حيث تم تجاوز إعادة تعيين عام بواسطة CSS وحدة مكون لأن ترتيب الاستيراد انقلب.

الإصلاح كان الاستخدام الصريح @layer في CSS الخاص بنا، والذي كان يجب أن نفعله طوال الوقت.

وحدات CSS

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

PostCSS

لا تزال ملفات تكوين PostCSS محترمة. يستمر postcss.config.js الخاص بك في العمل. لا تغييرات مطلوبة هنا.

تحديثات النشر وخط أنابيب CI

أهدافنا للنشر هي بشكل أساسي Vercel و AWS (عبر SST/OpenNext). إليك ما تغيّر:

Vercel: يكتشف تلقائياً Next.js 16 واستخدم Turbopack. تكامل ذاكرة التخزين المؤقت للبناء يعمل خارج الصندوق. انخفضت أوقات البناء لدينا على Vercel حتى أكثر بشكل كبير من CI المحلي لأن Vercel لديها تكامل عميق مع طبقة تخزين Turbopack المؤقت. انتقل المشروع C من حوالي 8 دقائق إلى حوالي 2.5 دقيقة على Vercel.

AWS/OpenNext: تطلب التحديث إلى OpenNext 4.x، الذي أضاف دعم إخراج Turbopack. تغيّر تنسيق الإخراج قليلاً — تم إعادة تنظيم هيكل دليل .next — لذا احتاجت أي سكريبتات ما بعد البناء التي أشارت إلى مسارات ملف محددة إلى التحديث.

بناء Docker: إذا كنت تبني Next.js في Docker، حدّث صورة الأساس إلى Node 20+ وكن على دراية بأن دليل ذاكرة التخزين المؤقت لـ Turbopack (.next/cache/turbopack) يجب أن يُدرج في استراتيجية تخزين Docker layer المؤقت. أضفنا طبقة COPY محددة لهذا.

# تحسين تخزين طبقة Docker المؤقت لـ Turbopack
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
# حمل مخزن مؤقت لـ Turbopack
RUN --mount=type=cache,target=/app/.next/cache \
    npm run build

عندما لا يجب أن تهاجر حتى الآن

لا أريد أن أصور هذا كل الورود. هناك أسباب شرعية للبقاء على Next.js 15 في الوقت الحالي:

• اعتماد مكون webpack ثقيل: إذا كان البناء الخاص بك يعتمد على 3+ مكونات webpack مخصصة لا تملك معادلات Turbopack، فقد لا تستحق تكلفة الهجرة.
• مستودع Monorepo مع إعداد webpack مشترك: إذا كنت تشارك إعدادات webpack عبر Next.js ومشاريع غير Next.js في monorepo، فإن تقسيم هذا الإعداد هو عمل إضافي.
• متطلبات الاستقرار: Next.js 16.0 مستقر، لكن 16.1 و 16.2 أصلحوا أخطاء حقيقية. أود الانتظار لـ 16.2+ على الأقل قبل هجرة أي شيء لا يمكنك تحمل وقت التوقف عليه.
• الاعتماديات الموروثة عالقة على React 18: إذا كان اعتماد حرج لم يضيف دعم React 19، فأنت محظور بغض النظر.

بالنسبة للفريق التي تقوم بـ تطوير Headless CMS، تكون الهجرة سلسة بشكل عام لأن المواقع المدفوعة بـ CMS تميل إلى أن يكون لديها تكوين بناء أبسط.

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

هل Turbopack مستقر بما يكفي للإنتاج في Next.js 16؟ نعم. كان Turbopack في التطور لأكثر من ثلاث سنوات، واختُبر بشكل شامل في وضع التطوير عبر ملايين مشاريع Next.js، ومرّ بجولة بيتا موسعة في عمليات الإنتاج خلال Next.js 15.3-15.5. كنا نشغله في الإنتاج منذ إصدار 16.0 عبر مواقع عملاء متعددة بدون مشاكل متعلقة بالحزمة. ومع ذلك، إذا كنت على 16.0 على وجه التحديد، قم بالترقية إلى 16.2+ حيث تم حل عدة أخطاء حافة.

هل يمكنني لا تزال استخدام webpack مع Next.js 16؟ ليس كحزمة أساسية، لا. Turbopack هو الحزمة المدعومة الوحيدة في Next.js 16. إذا كنت بحاجة مطلقة إلى webpack، ستحتاج إلى البقاء على Next.js 15، الذي سيتلقى رقع أمان خلال أوائل عام 2026. كانت Vercel واضحة بأن دعم webpack في Next.js انتهى.

كم مرة أسرع Turbopack مقارنة بـ webpack لعمليات البناء الإنتاجية؟ في عمليات البناء البارد (بدون ذاكرة تخزين مؤقت)، رأينا تحسينات 20-30٪. في عمليات البناء الدافئة/المخزنة مؤقتاً، يقفز التحسن إلى 50-70٪. الأرقام الدقيقة تعتمد بشكل كبير على حجم المشروع وعدد الطرق والكمية الثابتة المُنتجة. استخدام الذاكرة انخفض أيضاً بنسبة 20-30٪ باستمرار عبر مشاريعنا.

هل أحتاج إلى إعادة كتابة next.config.js الخاص بي لـ Turbopack؟ إذا كان لديك تكوين webpack مخصص في next.config.js، فنعم — تلك الكتل تحتاج إلى ترجمة إلى تنسيق إعدادات turbopack. إذا كنت تستخدم فقط خيارات إعدادات Next.js القياسية (الصور والإعادات والأرض والمتغيرات البيئية)، فكل تلك تعمل تماماً بنفس الطريقة. جهد الهجرة يتناسب مع مقدار إعدادات webpack المخصصة التي لديك.

هل سيعمل خط أنابيب CI/CD الموجود لدي مع Next.js 16؟ في الغالب نعم. الأشياء الرئيسية للتحديث هي: إصدار Node.js (الحد الأدنى 20)، أي سكريبتات تشير إلى ملفات إخراج محددة webpack، واستراتيجيات تخزين مؤقت تستهدف .next/cache/webpack. ستريد تخزين .next/cache/turbopack مؤقتاً بدلاً من ذلك. إذا كنت تنشر إلى Vercel، يتم التعامل مع كل شيء تلقائياً.

هل يدعم Turbopack جميع الميزات ذاتها مثل webpack في Next.js؟ لميزات خاصة بـ Next.js، نعم — App Router، Pages Router، طرق API، middleware، ISR، SSG، SSR جميعها تعمل. بالنسبة لتكوين webpack المخصص، هناك حوالي 90٪ توافق الميزات. الثغرات المتبقية تتعلق في الغالب بمكونات webpack المتخصصة واستراتيجيات تقسيم الأجزاء المخصصة بشكل كبير. تحقق من وثائق توافق Turbopack لحالة الاستخدام المحددة الخاصة بك.

هل يجب أن أهاجر إلى Next.js 16 أو أفكر في بدائل مثل Astro؟ يعتمد على حالة الاستخدام الخاصة بك. إذا كنت تبني تطبيقات تفاعلية للغاية مع إدارة حالة معقدة، فـ Next.js 16 خيار قوي وتحسينات Turbopack تجعل DX أفضل بشكل كبير. إذا كنت تبني مواقع ثقيلة المحتوى بـ تفاعل بسيط، Astro لا تزال بديلاً ممتازاً مع نموذج الترطيب الجزئي. كنا نبني مع كلاهما واختر بناءً على متطلبات المشروع. إذا كنت غير متأكد، تواصل معنا وبإمكاننا مساعدتك في تقييم.

ما هو الحد الأدنى للوقت المطلوب لهجرة تطبيق Next.js 15 متوسط الحجم إلى 16؟ بالنسبة لتطبيق متوسط الحجم نموذجي (50-200 مسار، اعتماديات قياسية، إعدادات webpack مخصصة بسيطة)، خطط لـ 2-4 أيام من وقت المطور. يتضمن ذلك تحديثات الاعتماديات والهجرات API غير المتزامنة والاختبار والتحقق من النشر. إذا كان لديك إعدادات webpack مخصصة واسعة النطاق أو اعتماديات موروثة، فقد تستغرق أسبوع أو أكثر. يقدم فريقنا في Social Animal خدمات الهجرة إذا كنت تفضل عدم حرق sprint فريقك على عمل البنية التحتية.