Next.js 9.5

نحن متحمسون اليوم لتقديم Next.js 9.5، الذي يتضمن:

• إعادة توليد ثابت تدريجي مستقر: إعادة بناء الصفحات الثابتة بعد النشر، في أجزاء من الثانية
• مسار أساسي قابل للتخصيص: استضافة مشاريع Next.js بسهولة على مسارات فرعية من نطاقك
• دعم لإعادة الكتابة، إعادة التوجيه، والعناوين: إعادة كتابة عناوين URL الزائفة، إعادة توجيه عناوين URL القديمة، وإضافة عناوين إلى الصفحات الثابتة
• شرطة مائلة اختيارية في عناوين URL: فرض غياب أو وجود شرطة مائلة نهائية بشكل متسق
• تخزين مؤقت دائم لحزم الصفحات: ملفات JavaScript للصفحات غير المتغيرة تنتقل الآن عبر عمليات البناء
• تحسينات التحديث السريع: تحسين موثوقية تجربة التحرير المباشر في Next.js
• تحليل أداء React للإنتاج: علامة جديدة لقياس "تكلفة" التصيير لمشروعك
• مسارات التقاط اختيارية لجميع المسارات: توفر المسارات الديناميكية الآن مرونة أكبر لحالات استخدام تحسين محركات البحث (SEO)
• دعم Webpack 5 (بيتا): اختيارياً الاشتراك في الإصدار التالي من Webpack 5 لتحسين حجم وسرعة البناء

إعادة توليد ثابت تدريجي مستقر

قدم Next.js طرق توليد موقع ثابت في الإصدار 9.3 بهدف واضح: يجب أن نحصل على فوائد الثبات (سريع دائمًا، متاح دائمًا، مكرر عالميًا)، ولكن مع دعم ممتاز للبيانات الديناميكية، الذي يشتهر به Next.js.

للحصول على أفضل ما في العالمين، قدم Next.js التوليد الثابت التدريجي، الذي يقوم بتحديث المحتوى الثابت بعد أن قمت بالفعل ببناء موقعك. باستخدام خيار fallback: true في getStaticPaths، يمكنك تسجيل صفحات ثابتة جديدة أثناء التشغيل.

يمكن لـ Next.js أن يقوم بتصيير مسبق لعدد لا حصر له من الصفحات بهذه الطريقة، عند الطلب، بغض النظر عن حجم مجموعة البيانات الخاصة بك.

اليوم، نعلن عن التوفر العام لإمكانية إعادة التوليد الثابت التدريجي، وهي آلية لتحديث الصفحات الموجودة، عن طريق إعادة تصييرها في الخلفية مع وصول الزيارات.

مستوحاة من stale-while-revalidate، تضمن إعادة التوليد في الخلفية تقديم الزيارات دون انقطاع، دائمًا من التخزين الثابت، ويتم دفع الصفحة التي تم بناؤها حديثًا فقط بعد اكتمال توليدها.

export async function getStaticProps() {
  return {
    props: await getDataFromCMS(),
    // سنحاول إعادة توليد الصفحة:
    // - عند وصول طلب
    // - على الأكثر مرة كل ثانية
    revalidate: 1,
  };
}

علامة revalidate هي عدد الثواني التي خلالها سيحدث توليد واحد على الأكثر، لمنع https://en.wikipedia.org/wiki/Cache_stampede.

على عكس التصيير من جانب الخادم التقليدي (SSR)، تضمن إعادة التوليد الثابت التدريجي أن تحتفظ بفوائد الثبات:

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

كلتا الميزتين التدريجيتين (إضافة الصفحات وتحديثها بكسل)، بالإضافة إلى وضع المعاينة، أصبحتا الآن مستقرتين ومدعومتين بالكامل من قبل كل من next start ومنصة Vercel edge مباشرة.

لعرض هذه الميزة الجديدة، قمنا بإنشاء مثال يوضح إعادة توليد صفحة ثابتة تعرض عدد ردود الفعل المختلفة على GitHub لقضية محددة: https://reactions-demo.vercel.app/

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

في المستقبل، سنعمل على طلب تعليقات (RFC) تكميلي لمعالجة قدرتين إضافيتين للتوليد الثابت التدريجي:

• إعادة توليد وإبطال عدة صفحات في وقت واحد (مثل فهرس مدونتك ومنشور مدونة معين)
• إعادة التوليد عن طريق الاستماع إلى الأحداث (مثل webhooks من نظام إدارة المحتوى)، قبل وصول زيارات المستخدمين

لمزيد من التفاصيل، راجع توثيق getStaticProps.

مسار أساسي قابل للتخصيص

لا يتم تقديم مشاريع Next.js دائمًا من جذر النطاق. في بعض الأحيان قد ترغب في استضافة مشروع Next.js الخاص بك تحت مسار فرعي مثل /docs بحيث يغطي مشروع Next.js هذا القسم الفرعي فقط من النطاق.

على الرغم من أن هذا كان ممكنًا حتى الآن، إلا أنه كان على حساب الكثير من التكوين الإضافي. على سبيل المثال، إضافة البادئة إلى كل <Link> والتأكد من أن Next.js يقدم حزم JavaScript من المسار الصحيح.

لمعالجة هذه المشكلة، نقدم خيار تكوين جديد. يسمح لك basePath باستضافة مشروع Next.js الخاص بك بسهولة على مسار فرعي من نطاقك.

للبدء في استخدام basePath، يمكنك إضافته إلى next.config.js:

module.exports = {
  basePath: '/docs',
};

بعد تكوين basePath، سيتم توجيه مشروعك تلقائيًا من المسار المقدم. في هذه الحالة، /docs.

عند الارتباط بصفحات أخرى في المشروع باستخدام next/link أو next/router، ستتم إضافة basePath تلقائيًا. وهذا يسمح لك بتغيير basePath دون تغيير مشروعك.

مثال على ذلك هو استخدام next/link للتوجيه إلى صفحة أخرى:

import Link from 'next/link';
 
export default function HomePage() {
  return (
    <>
      <Link href="/documentation-page">
        <a>صفحة التوثيق</a>
      </Link>
    </>
  );
}

سيؤدي استخدام next/link بهذه الطريقة إلى عرض HTML التالي في متصفح الويب:

<a href="/docs/documentation-page">صفحة التوثيق</a>

لمزيد من التفاصيل، راجع توثيق basePath.

دعم لإعادة الكتابة، إعادة التوجيه، والعناوين

إعادة الكتابة

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

مع Next.js 9.5، نقدم خيار تكوين جديدًا يسمى rewrites، الذي يسمح لك بتعيين مسار طلب وارد إلى مسار وجهة مختلف، بما في ذلك عناوين URL الخارجية.

على سبيل المثال، قد ترغب في إعادة كتابة مسار معين إلى example.com:

module.exports = {
  async rewrites() {
    return [
      { source: '/backend/:path*', destination: 'https://example.com/:path*' },
    ];
  },
};

في هذه الحالة، سيتم توجيه جميع المسارات تحت /backend إلى example.com.

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

module.exports = {
  async rewrites() {
    return [
      // التحقق مما إذا كانت مسارات مشروع Next.js متطابقة قبل محاولة التوجيه
      {
        source: '/:path*',
        destination: '/:path*',
      },
      {
        source: '/:path*',
        destination: `https://example.com/:path*`,
      },
    ];
  },
};

في هذه الحالة، نقوم أولاً بمطابقة جميع المسارات. إذا لم يتطابق أي منها، نقوم بالتوجيه إلى example.com الذي سيكون المشروع السابق.

لمعرفة المزيد عن ميزة rewrites، راجع توثيق إعادة الكتابة.

إعادة التوجيه

تحتاج معظم المواقع إلى بعض عمليات إعادة التوجيه على الأقل. خاصة عند تغيير هيكل مسارات مشروعك. على سبيل المثال، عند الانتقال من /blog إلى /news أو انتقالات مماثلة.

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

بدءًا من Next.js 9.5، يمكنك الآن إنشاء قائمة بإعادة التوجيه في next.config.js تحت مفتاح redirects:

module.exports = {
  async redirects() {
    return [
      {
        source: '/about',
        destination: '/',
        permanent: true,
      },
    ];
  },
};

لمعرفة المزيد عن ميزة redirects، راجع توثيق إعادة التوجيه.

رؤوس الصفحات (Headers)

يسمح لك Next.js ببناء مشاريب هجينة تستخدم كلاً من التوليد الثابت (Static Generation) وعرض جانب الخادم (Server-Side Rendering). مع عرض جانب الخادم، يمكنك تعيين رؤوس للطلب الوارد. بالنسبة للصفحات الثابتة، لم يكن من الممكن تعيين الرؤوس حتى الآن.

لقد قدمنا الآن خاصية headers في next.config.js تنطبق على جميع مسارات Next.js:

module.exports = {
  async headers() {
    return [
      {
        source: '/:path*',
        headers: [
          {
            key: 'Feature-Policy',
            // تعطيل الميكروفون وتحديد الموقع الجغرافي
            value: "microphone 'none'; geolocation 'none'",
          },
        ],
      },
    ];
  },
};

خيار headers يسمح لك بتعيين رؤوس شائعة مثل Feature-Policy و Content-Security-Policy.

للمزيد عن ميزة headers، راجع توثيق الرؤوس.

الشرطة المائلة الاختيارية في عناوين URL

عند تقديم Next.js قبل 3 سنوات، كان سلوكه الافتراضي هو أن جميع عناوين URL التي تحتوي على شرطة مائلة في النهاية تعرض دائمًا صفحة 404.

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

مع Next.js 9.5 قدمنا خيارًا جديدًا يسمى trailingSlash في next.config.js.

هذا الخيار الجديد يضمن أن Next.js يتعامل تلقائيًا مع سلوك الشرطة المائلة:

• إعادة توجيه عناوين URL ذات الشرطة المائلة تلقائيًا إلى عنوان URL بدون الشرطة المائلة، على سبيل المثال: /about/ إلى /about
• عند تعيين trailingSlash إلى true، سيتم إعادة توجيه عنوان URL بدون شرطة مائلة إلى عنوان URL مع شرطة مائلة، على سبيل المثال: /about إلى /about/
• يضمن أن next/link يطبق/يزيل الشرطة المائلة تلقائيًا لتجنب عمليات إعادة التوجيه غير الضرورية.

module.exports = {
  // إجبار وجود شرطة مائلة، القيمة الافتراضية هي عدم وجود شرطة مائلة (false)
  trailingSlash: true,
};

للمزيد عن ميزة trailingSlash، راجع توثيق trailingSlash

التخزين المؤقت الدائم لحزم الصفحات

عند كتابة صفحات Next.js، يكون إنشاء جميع حزم البرامج النصية وملفات أنماط CSS و HTML تلقائيًا بالكامل ومجردًا عنك. إذا قمت بفحص علامات <script> المُنشأة قبل Next.js 9.5، ستلاحظ أن عناوين URL الخاصة بها تتبع نمطًا مثل هذا:

/_next/static/ovgxWYrvKyjnlM15qtz7h/pages/about.js

جزء المسار ovgxWYrvKyjnlM15qtz7h أعلاه هو ما نسميه معرف البناء (build ID). على الرغم من أن هذه الملفات كانت قابلة للتخزين المؤقت بسهولة عند الحافة وعلى جهاز المستخدم، إلا أنه بعد إعادة بناء تطبيقك، سيتغير معرف البناء وسيتم إبطال جميع ذاكرات التخزين المؤقت.

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

قدمنا استراتيجية تقسيم الشفرة المحسنة في Next.js 9.2 التي تم تطويرها بالتعاون مع فريق Google Chrome بعض الأساسيات لهذه التحسينات في توليد حزم صفحات Next.js.

بدءًا من Next.js 9.5 ستستخدم جميع حزم JavaScript للصفحات تجزئات المحتوى (content hashes) بدلاً من معرف البناء. هذا يسمح للصفحات التي لم تتغير بين النشرات بالبقاء في ذاكرة التخزين المؤقت للمتصفح والحافة دون الحاجة إلى تنزيلها مرة أخرى.

على النقيض من ذلك، يبدو نمط عنوان URL بعد هذه التغييرات كما يلي:

/_next/static/chunks/pages/about.qzfS4o5gIEXRME6sTEahL.js

بدلاً من معرف بناء عام، فإن جزء `qzfS4o5gIEXRME6sTEahL` هو تجزئة حتمية لحزمة `about.js`، والتي ستكون مستقرة طالما أن الكود الخاص بهذا القسم من موقعك لم يتغير. علاوة على ذلك، **يتم الآن تخزينها مؤقتًا على المدى الطويل عبر عمليات إعادة النشر** عبر `Cache-Control: public,max-age=31536000,immutable` والتي يقوم Next.js بتعيينها تلقائيًا لك.

[تحسينات التحديث السريع (Fast Refresh)](#fast-refresh-enhancements)
-------------------------------------------------------

لقد [قدمنا التحديث السريع في Next.js 9.4](https://nextjs.org/blog/next-9-4#fast-refresh)، وهي تجربة إعادة تحميل ساخن جديدة تمنحك ملاحظات فورية على التعديلات التي تجريها على مكونات React الخاصة بك.

يُحسن Next.js 9.5 تنفيذنا للتحديث السريع ويعطيك الأدوات التي تحتاجها للنجاح:

*   **أخطاء سهلة الفهم**: تم تحديث جميع أخطاء الترجمة والوقت التشغيلي [لعرض **المعلومات ذات الصلة فقط، بما في ذلك إطار الكود** لأي كود تسبب في الخطأ](https://twitter.com/timer150/status/1263689549898829829).
*   **نصائح وقت التطوير للحفاظ على حالة المكون**: يقدم لك Next.js الآن نصائح مفيدة لضمان أن التحديث السريع سيحافظ على حالة مكونك في أكبر عدد ممكن من السيناريوهات. كل نصيحة يقدمها Next.js **قابلة للتنفيذ بالكامل** ومصحوبة بمثال قبل وبعد!
*   **تحذيرات عند إعادة تعيين حالة المكون**: سنطبع الآن تحذيرًا مفصلًا عندما لا يتمكن Next.js من الحفاظ على حالة المكون بعد تعديل ملف. سيساعدك هذا التحذير في تشخيص سبب اضطرار المشروع إلى إعادة تعيين حالة المكون، مما يسمح لك بإصلاحه والاستفادة الكاملة من التحديث السريع.
*   **توثيق جديد**: لقد [أضفنا توثيقًا موسعًا](/docs/architecture/fast-refresh) يشرح ما هو التحديث السريع، وكيف يعمل، وما يمكن توقعه! سيعلمك التوثيق أيضًا كيفية الاستفادة بشكل أفضل من التحديث السريع من خلال شرح كيفية عمل استرداد الأخطاء.
*   **دليل استكشاف الأخطاء وإصلاحها للكود الخاص بالمستخدم**: يتضمن التوثيق الجديد أيضًا [خطوات استكشاف الأخطاء وإصلاحها الشائعة ونصائح](/docs/architecture/fast-refresh#tips) حول كيفية تحقيق أقصى استفادة من التحديث السريع في التطوير.

[تحليل أداء React في الإنتاج](#production-react-profiling)
---------------------------------------------------------

قدمت React [واجهة برمجة التطبيقات لتحليل الأداء (Profiler API)](https://github.com/reactjs/rfcs/pull/51) منذ فترة والتي تتيح لك تتبع مشكلات الأداء في مكونات React الخاصة بك. بينما تعمل هذه الميزة تلقائيًا في التطوير، فإنها تتطلب استخدام إصدار منفصل من ReactDOM لتحليل الأداء في الإنتاج.

مع Next.js 9.5، يمكنك الآن **تمكين تحليل أداء React للإنتاج** باستخدام علامة `--profile` في `next build`:

next build --profile

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

للمزيد عن تحليل أداء React، يمكنك قراءة [المنشور حول محلل أداء React من فريق React](https://reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html). شكر خاص لـ [TODOrTotev](https://github.com/TodorTotev) و [@darshkpatel](https://github.com/darshkpatel) للمساهمة في هذه الميزة.

[مسارات الالتقاط الشاملة الاختيارية](#optional-catch-all-routes)
-------------------------------------------------------

أضاف Next.js 9.2 [دعمًا لمسارات ديناميكية شاملة الالتقاط](https://nextjs.org/blog/next-9-2#catch-all-dynamic-routes) والتي تم اعتمادها على نطاق واسع من قبل المجتمع لحالات استخدام متنوعة. تمنحك مسارات الالتقاط الشاملة المرونة لإنشاء هياكل توجيه ديناميكية للغاية مدعومة بـ Headless CMS، وواجهات برمجة تطبيقات GraphQL، ونظام الملفات، وما إلى ذلك.

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

لإنشاء مسار شامل الالتقاط اختياري، يمكنك إنشاء صفحة باستخدام بناء الجملة `[[...slug]]`.

على سبيل المثال، `pages/blog/[[...slug]].js` سيطابق `/blog`، وكذلك أي مسار تحته، مثل: `/blog/a`، `/blog/a/b/c`، وهكذا.

مثل مسارات الالتقاط الشاملة، سيتم توفير `slug` في [كائن استعلام الموجه](/docs/pages/api-reference/functions/use-router#router-object) كمصفوفة من أجزاء المسار. لذا، بالنسبة للمسار `/blog/foo/bar`، سيكون كائن الاستعلام `{ slug: ['foo', 'bar'] }`. بالنسبة للمسار `/blog`، سيحذف كائن الاستعلام مفتاح slug: `{ }`.

يمكنك [معرفة المزيد عن مسارات الالتقاط الشاملة الاختيارية في توثيقنا](/docs/pages/building-your-application/routing/dynamic-routes#optional-catch-all-routes).

[دعم Webpack 5 (بيتا)](#webpack-5-support-beta)
---------------------------------------------------

Webpack 5 حاليًا في مرحلة بيتا. يتضمن بعض التحسينات الرئيسية:

*   [تحسين هز الشجرة (Tree-Shaking)](https://github.com/webpack/changelog-v5#nested-tree-shaking): يتم هز الصادرات المتداخلة، والوحدات الداخلية، و CommonJS
*   [التخزين المؤقت الدائم (Persistent Caching)](https://github.com/webpack/changelog-v5#persistent-caching): يسمح بإعادة استخدام العمل من عمليات البناء السابقة
*   [معرفات قطع ووحدات حتمية](https://github.com/webpack/changelog-v5#deterministic-chunk-and-module-ids): يحل الحالات التي تتغير فيها معرفات وحدة webpack بين عمليات البناء

يسعدنا اليوم الإعلان عن التوفر التجريبي لـ webpack 5 لـ Next.js.

لتجربة webpack 5 يمكنك استخدام [قرارات Yarn](https://classic.yarnpkg.com/en/docs/selective-version-resolutions/) في ملف `package.json` الخاص بك:

```json filename="package.json"
{
  "resolutions": {
    "webpack": "^5.0.0-beta.30"
  }
}

تم بالفعل طرح نسخة بيتا من Webpack 5 في nextjs.org و vercel.com في الإنتاج. نشجعك على تجربتها بطريقة تدريجية والإبلاغ عن النتائج التي توصلت إليها على GitHub.

تحسينات بنية الترجمة

لدعم webpack 5 قمنا بإعادة كتابة الكثير من خط أنابيب الترجمة ليكون أكثر ملاءمة لـ Next.js:

• لم يعد Next.js يعتمد على webpack-hot-middleware و webpack-dev-middleware، بدلاً من ذلك نستخدم الآن webpack مباشرة ونحسن خصيصًا لمشاريع Next.js. وهذا يترجم إلى بنية أبسط وترجمة تطوير أسرع.
• الإدخالات عند الطلب (On-demand-entries)، وهو النظام الذي يمتلكه Next.js للسماح له بترجمة الصفحات التي تزورها في وقت معين أثناء التطوير، تمت إعادة كتابته أيضًا وأصبح الآن أكثر موثوقية من خلال الاستفادة من سلوك webpack الجديد المصمم خصيصًا لحالة استخدامنا.
• التحديث السريع لـ React وطبقة أخطاء Next.js متوافقان الآن بالكامل مع webpack 5
• سيتم تمكين التخزين المؤقت على القرص في إصدار بيتا مستقبلي.

التوافق مع الإصدارات السابقة

نحن ملتزمون دائمًا بضمان أن Next.js متوافق مع الإصدارات السابقة.

سيستمر دعم webpack 4 بالكامل. نحن نعمل عن كثب مع فريق webpack لضمان أن الانتقال من webpack 4 إلى 5 يكون سلسًا قدر الإمكان.

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

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

تحسين مراقبة الملفات على macOS

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

علاوة على ذلك، وجدنا أن هذه المشكلة لم تحدث فقط في مشاريع Next.js ولكن في جميع المشاريع والأطر التي تعتمد على webpack.

بعد عدة أيام من تصحيح المشكلة، تتبعنا جذرها إلى تنفيذ مراقبة الملفات الذي يستخدمه webpack المسمى chokidar، وهو تنفيذ لمراقبة الملفات يستخدم على نطاق واسع في نظام Node.js.

أرسلنا تصحيحًا إلى chokidar لإصلاح المشكلة. بعد إصدار التصحيح، عملنا مع Tobias Koppers لطرح هذا التصحيح في إصدار جديد من webpack.

يتم استخدام إصدار webpack المصحح تلقائيًا عند الترقية إلى Next.js 9.5.

الختام

يسعدنا رؤية النمو المستمر في اعتماد Next.js:

• كان لدينا أكثر من 1,200 مساهم مستقل**،** مع أكثر من 135 مساهمًا جديدًا منذ إصدار 9.4.
• على GitHub، تم تمييز المشروع بنجمة أكثر من 51,100 مرة.

انضم إلى مجتمع Next.js على مناقشات GitHub. المناقشات هي مساحة مجتمعية تتيح لك التواصل مع مستخدمي Next.js الآخرين وطرح الأسئلة بحرية أو مشاركة عملك.

على سبيل المثال، قد ترغب في البدء بـ مشاركة عنوان URL لمشروعك مع الجميع.

إذا كنت ترغب في رد الجميل ولكنك غير متأكد من كيفية القيام بذلك، فإننا نشجعك على تجربة الميزات التجريبية مثل دعم Webpack لدينا والإبلاغ عن النتائج التي توصلت إليها!

الاعتمادات

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

شكر خاص لـ Jan Potoms، عضو مجتمع Next.js منذ فترة طويلة والذي ساهم في ميزات متعددة في هذا الإصدار.

شكر خاص لـ Tobias Koppers، مؤلف webpack، الذي ساعد في دعم webpack 5 في Next.js.

تم تقديم هذا الإصدار بفضل مساهمات: @chandan-reddy-k، @Timer، @aralroca، @artemisart، @sospedra، @prateekbh، @Prioe، @Janpot، @merceyz، @ijjk، @PavelK27، @marbiano، @MichelleLucero، @thorsten-stripe، @TODOrTotev، @Skn0tt، @lfades، @timneutkens، @akhila-ariyachandra، @chibicode، @rafaelalmeidatk، @kirill-konshin، @jamesvidler، @JeffersonBledsoe، @tylev، @jamesmosier، @filipemarins، @Remeic، @vvo، @timothyis، @jazibsawar، @coetry، @adam-zacharski، @danwilliams، @tywmick، @matamatanot، @goldins، @mvllow، @its-tayo، @sshyam-gupta، @wilbert-abreu، @sebastianbenz، @jaydenseric، @developit، @dylanjha، @darshkpatel، @spinks، @stefanprobst، @moh12594، @jasonmerino، @cristiand391، @HyunSangHan، @mcsdevv، @M1ck0، @hydRAnger، @alexej-d، @valmassoi، @motleydev، @eKhattak، @jpedroschmitz، @JerryGoyal، @bowen31337، @phillip055، @balazsorban44، @chuabingquan، @youhosi، @andresz1، @bell-steven، @areai51، @Wssn، @ndom91، @anthonyshort، @zxzl، @jbowes، @IamLizu، @PascalPixel، @ralphilius، @ysun62، @muslax، @elsigh، @AsherFoster، @botv، @tomdohnal، @christianalfoni، @tomasztunik، @gsimone، @illuminist، @jplew، @OskarKaminski، @RickyAbell، @steph-query، @ericgoe، @MalvinJay، @cristianbote، @Ashikpaul، @jensmeindertsma، @amorriscode، @abhik-b، @awareness481، @LukasPolak، @arvigeus، @romMidnight، @jackyef، @drumm2k، @kuldeepkeshwar، @bogy0، @Belco90، @wawjr3d، @tanmaylaud، @SarKurd، @kevinsproles، @dstotijn، @styfle، @blackwright، @BrunoBernardino، @heyAyushh، @Necmttn، @TrySound، @obedparla، @NyashaNziramasanga، @tonyspiro، @kukicado، @ceorourke، @MehediH، @robintom، @karlhorky، و @tcK1!