React Native 0.87: دليل ترقية Strict TypeScript و AGP 9 و SwiftPM

ياسر نجيب
•
•
آخر مراجعة:
•
5 دقائق قراءة

صدر React Native 0.87 في 11 أغسطس 2026. يحمل الإصدار تحسينات حقيقية في Metro و TypeScript وتجهيز iOS، لكنه يرفع متطلبات الأدوات ويحذف واجهات قديمة. لذلك الترقية ليست تغيير رقم في package.json، خصوصاً إذا كان التطبيق عربياً، أو يعتمد على مكتبات native، أو يبنى في CI قديم.

أصبح Strict TypeScript API هو الافتراضي، وانتقل Metro إلى 0.87، وأضيف دعم تجريبي لـ Swift Package Manager. وفي Android ارتفعت المتطلبات إلى Node.js 22.13 أو أحدث، و Kotlin 2.0 أو أحدث، و AGP 9، و compile SDK 37 للتطبيق المرجعي.

إعلان React Native 0.87 الرسمي

لماذا Strict TypeScript API مهم؟

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

import SomeInternalThing from "react-native/Libraries/...";

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

يوجد opt-out مؤقت عبر react-native-legacy-deep-imports. تقول الوثائق إنه يبقى حتى 0.88، مع نية إزالة الأنواع القديمة في الإصدار التالي. استخدمه كجسر مسجل بموعد إزالة، لا كحل دائم.

متطلبات Android قد توقف CI قبل التطبيق

قد يفشل البناء قبل الوصول إلى JavaScript بسبب اختلاف بيئة التطوير:

  • Node.js 22.13 أو أحدث.
  • Kotlin 2.0 أو أحدث، مع نسخة مجمعة 2.2.
  • Android Gradle Plugin 9.
  • minCompileSdk للمكتبات 34، و compile SDK للمشروع 37.
  • تغيرات في Gradle و Java و plugins التابعة.

ثبّت نسخة Node و JDK و Android SDK في CI بدلاً من الاعتماد على latest. افحص كل مكتبة native، لأن توافق التطبيق وحده لا يكفي إذا كانت مكتبة قديمة تستخدم API أزيل أو إعداد Gradle غير متوافق.

Metro أسرع، لكن راقب الإعدادات القديمة

تعلن Meta أن توليد source maps أصبح أسرع وأن الذاكرة المستخدمة لها انخفضت، مع دعم مستقر لإعدادات TypeScript و ESM. في المقابل، أزيل دعم ملفات إعداد Metro بصيغة YAML وامتداد .es6.

قارن زمن cold build و incremental build وفتح DevTools قبل وبعد على نفس الجهاز. لا تنسب كل تحسن إلى Metro إذا تغير Node و Gradle و cache في الوقت نفسه. احتفظ بالأرقام والسجلات، خصوصاً إذا كان وقت CI يؤثر في تكلفة الفريق.

SwiftPM ميزة تجريبية وليست قرار إنتاج تلقائياً

يقدم 0.87 مساراً تجريبياً لاستخدام Swift Package Manager بدلاً من CocoaPods. الفكرة جذابة لأنها تقلل اعتماد Ruby وpod install، لكن الوثائق تقول بوضوح إن CocoaPods يبقى المسار الافتراضي والمدعوم.

لا تنقل تطبيقاً منشوراً إلى SwiftPM لمجرد تجربة الخبر. بعض المكتبات لا توفر Package.swift، وقد تتغير الأوامر والبنية، ويحتاج CI إلى خطوة إعداد. اختبره في branch منفصل أو تطبيق داخلي، واحصر كل مكتبة native وامتداد و build phase و capability قبل المقارنة.

واجهات أزيلت أو تغيرت

يتضمن الإصدار حذف InteractionManager لصالح requestIdleCallback، وإزالة خصائص قديمة في Modal وStatusBar، وتغييرات في ScrollView وuseColorScheme، ونقل polyfills و Jest preset. كما توجد deprecations جديدة مثل ImageBackground وبعض APIs في Android.

ابحث عن الرموز المذكورة في release notes داخل التطبيق والاعتماديات. ثم عالج كل استخدام مع اختبار، بدلاً من تشغيل codemod وقبول diff كبير بلا مراجعة.

مسار ترقية آمن

  1. سجّل baseline: بناء iOS و Android، الاختبارات، حجم الحزمة، زمن التشغيل، والأعطال.
  2. حدّث toolchain في CI وبيئة محلية قابلة للإعادة.
  3. استخدم Upgrade Helper وقارن ملفات القالب يدوياً.
  4. فعّل Strict API وعالج deep imports قبل استخدام opt-out.
  5. حدّث المكتبات native واحدة أو مجموعة صغيرة في كل خطوة.
  6. شغّل unit و integration و E2E، ثم signed release builds.
  7. اختبر على iPhone و Android فعليين متصلين إن توفرا.
  8. انشر إلى قناة اختبار قبل store production.

مصفوفة RTL لا يجوز اختصارها

النجاح بالإنجليزية لا يثبت جاهزية التطبيق العربي. اختبر:

  • تشغيل بارد بالعربية ثم الإنجليزية والعكس.
  • نصاً مختلطاً مثل QAR 1,250 ورقم طلب وبريد.
  • سهم الرجوع و gestures و drawers و bottom sheets.
  • useColorScheme() لأنه قد يعيد null بعد التغيير.
  • حجم نص كبير و VoiceOver و TalkBack.
  • إشعاراً ورابطاً عميقاً وشاشة صلاحيات.
  • release build موقعاً، لا Metro development فقط.

قارن screenshots قبل وبعد في الاتجاهين. قد يمر TypeScript بينما تنقلب أيقونة أو تتغير safe area أو تفشل مكتبة تنقل على Android فقط.

أثر الترقية على العمل

الفائدة هي API أوضح، وأدوات أحدث، و Metro أفضل، ومسار محتمل أبسط لـ iOS. التكلفة هي وقت توافق للمكتبات و CI واختبار الأجهزة. المشروع الذي يعتمد كثيراً على internals سيدفع تكلفة أكبر الآن، لكنه كان يحمل مخاطرة مخفية أصلاً.

لا تجعل موعد release في المتجر هو أول مرة يلتقي فيها الفريق مع AGP 9 أو Strict API. خصص ترقية مستقلة عن إضافة feature كبيرة حتى تستطيع تحديد سبب الفشل والرجوع بسرعة.

تعامل مع توافق المكتبات كسلسلة اعتماديات

أنشئ قائمة بكل مكتبة native ونسختها ومالكها ومسار iOS و Android الذي تستخدمه. ابحث عن deep imports و patches محلية و Pod hooks وتعديلات Gradle قبل تحديث React Native، لأنها غالباً تخفي ارتباطاً بنسخة قديمة. لا تعتبر وجود إصدار جديد في npm دليلاً على توافقه؛ راجع release notes وشغّل بناء release نظيفاً من clone جديد.

قسّم الاعتماديات إلى حرجة، مثل التنقل والدفع والإشعارات، وثانوية يمكن تعطيلها مؤقتاً. اختبر الحرجة أولاً على الأجهزة الفعلية، مع offline وإلغاء الصلاحية واستئناف التطبيق بعد إغلاقه. سجّل النسخة التي نجحت وسبب أي opt-out. هذا السجل يجعل الرجوع ممكناً ويمنع CI المحلي الناجح من إخفاء فشل لا يظهر إلا في أرشيف iOS أو bundle Android موقع.

رأيي العملي

أبدأ الترقية الآن في branch مخصص إذا كان التطبيق على نسخة مدعومة قريبة، لكن لا أعد بالانتقال في يوم واحد. أصلح deep imports بدلاً من إخفائها، وأثبت toolchain، وأبقي CocoaPods للإنتاج إلى أن تثبت SwiftPM ملاءمته لكل اعتماد. بالنسبة لتطبيق عربي، لا تكتمل الترقية من دون signed builds واختبار RTL فعلي.

المصادر وتاريخ المراجعة

اقرأ أيضاً