Webpack 5.105

يجلب Webpack 5.105 عدة تحسينات، سواء في توليد الأكواد أو إصلاح الأخطاء.

• إصلاح ثغرتين أمنيتين (CVEs) منخفضتي الخطورة في Webpack
• تحليل الأسماء المستعارة في tsconfig.json دون الحاجة إلى إضافات (plugins)
• تحليل الوحدات (Module Resolution) التلقائي لـ Web Workers
• دعم حارس محدد الاستيراد (Import Specifier Guard)
• دعم import.defer() لوحدة السياق (Context Module)
• الحفاظ على الخصائص المخصصة في import.meta
• تحكم أفضل في خرائط المصدر (Source Maps) في devtool
• مخرجات ESM أنظف لـ Node.js وعمليات البناء الحديثة
• تحسينات وإصلاحات أخرى

إصلاح ثغرتين أمنيتين (CVEs) منخفضتي الخطورة في Webpack

تم إصلاح ونشر ثغرتين أمنيتين (CVEs) جديدتين منخفضتي الخطورة في Webpack. بشكل افتراضي، أنت في أمان؛ هذه المشاكل تؤثر فقط على مستخدمي الخيار التجريبي experiments.buildHttp.

الثغرات (CVEs) المتأثرة:

CVE-2025-68157

• لمزيد من التفاصيل، راجع الاستشارة: GHSA-38r7-794h-5758
• الإصدارات المتأثرة: >=5.49.0 <5.104.0

CVE-2025-68458

• لمزيد من التفاصيل، راجع الاستشارة: GHSA-8fgc-7cc6-rx7x
• الإصدارات المتأثرة: >=5.49.0 <5.104.1

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

لمزيد من المعلومات حول الإبلاغ عن الثغرات الأمنية، راجع سياسة أمان Webpack.

تحليل الأسماء المستعارة في tsconfig.json دون الحاجة إلى إضافات (plugins)

يمكن الآن تكوين تحليل الوحدات (Module resolution) لقراءة compilerOptions.baseUrl و compilerOptions.paths من ملف tsconfig.json وتطبيق تلك الأسماء المستعارة عند تحليل الواردات (imports). نتيجة لذلك، لم يعد من الضروري تثبيت وتكوين الإضافة الخارجية tsconfig-paths-webpack-plugin فقط لجعل الأسماء المستعارة لمسارات TypeScript تعمل أثناء الحزم (bundling).

في تكوين webpack، يُستخدم الخيار resolve.tsconfig لتحديد ملف tsconfig الذي يجب استخدامه كمصدر (وهو مفيد أيضًا في المستودعات الأحادية monorepos أو الإعدادات التي تحتوي على ملفات tsconfig متعددة):

// webpack.config.js
module.exports = {
  resolve: {
    tsconfig: "./tsconfig.json", // يمكن أن يكون `false` (معطل)، `true` (استخدام tsconfig.json الافتراضي)، أو مسارًا إلى ملف `tsconfig.json`، أو كائنًا بخيارات configFile و references.
  },
};

مثال على الأسماء المستعارة في tsconfig.json:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  }
}

وبعد ذلك في الكود:

import Button from "@/components/Button";

بهذه الطريقة، يمكن تحليل @/components/Button وفقًا للقواعد المحددة في tsconfig.json، مما يتجنب الحاجة إلى تكرار الأسماء المستعارة في resolve.alias ويقلل من التناقضات بين ما يفهمه TypeScript وما يقوم المحزم (bundler) بتحليله.

تحليل الوحدات (Module Resolution) التلقائي لـ Web Workers

عند استيراد حزمة مخصصة لاستخدامها في Web Worker في Webpack، يمكن لتحليل الوحدات إعطاء الأولوية لملفات مثل index.worker.js بدلاً من index.js عند استخدام الصادرات المشروطة (conditional exports) المعرفة في حقل exports في package.json.

هذا يعني أنه إذا قمت بتحديد شروط مثل "worker" في صادرات حزمتك، سيقوم Webpack تلقائيًا بتحديد الإصدار المناسب، مثل index.worker.js، كلما تم استيراد الحزمة داخل سياق الـ worker. لا حاجة لتعديل خيار resolve.conditionNames أو إجراء تغييرات إضافية في تكوين Webpack؛ تحتاج فقط إلى تحديد الشروط بشكل صحيح في package.json.

على سبيل المثال، في package.json:

{
  "name": "foo",
  "exports": {
    ".": {
      "worker": "./index.worker.js",
      "default": "./index.js"
    }
  }
}

الآن، عند استيراد حزمة foo داخل Worker، سيختار Webpack تلقائيًا ملف index.worker.js وفقًا لشروط التصدير:

// هذا الاستيراد موجود داخل سياق Worker، لذا يستخدم Webpack ملف index.worker.js
const worker = new Worker(new URL("foo", import.meta.url), {
  type: "module",
});

دعم حارس محدد الاستيراد (Import Specifier Guard)

تمت إضافة دعم لحراس محدد الاستيراد (import specifier guards)، وهو تحسين يساعد المحزم (bundler) على فهم النمط الشائع بشكل أفضل عند التحقق مما إذا كان التصدير موجودًا قبل استخدامه. في السابق، حتى لو كان الكود محميًا بشكل صحيح بواسطة عبارة if، كان من الممكن تفسير الوصول على أنه غير مشروط ويؤدي إلى تحذيرات مثل "export … was not found" (التصدير ... غير موجود).

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

import * as React from "react";

if (React.useId) {
  // إنشاء حارس لـ `React` => userId: ["", "useId"].
  React.useId; // React -> "useId" is in guard.
  React; //  React -> "" is in guard.
}

دعم import.defer() لوحدة السياق (Context Module)

يدعم Webpack الآن import.defer() حتى عندما يكون الاستيراد وحدة سياق (context module) (أي عندما يتم بناء مسار الاستيراد ديناميكيًا ويحتاج webpack إلى تضمين مجموعة من الملفات المحتملة). عمليًا، يجعل هذا من الأسهل بكثير تأجيل تحميل الوحدة المحددة في وقت التشغيل، حتى عندما تأتي تلك الوحدة من تعبير ديناميكي يشير إلى مجلد. ويتيح هذا أنماطًا مثل "اختر بين a.js أو b.js وقم بتحميله فقط عند الحاجة"، مع توليد webpack للسياق المناسب لضمان عمل import.defer() بشكل صحيح.

const file = Math.random() > 0.5 ? "a.js" : "b.js";
import.defer("./dir/" + file);

الحفاظ على الخصائص المخصصة في import.meta

يحافظ Webpack الآن على الخصائص المخصصة لـ import.meta أثناء الحزم عند تفعيل output.module. في السابق، كان Webpack يقوم بإزالة أي خصائص import.meta غير معروفة (مثل import.meta.customProp)، مما يتسبب في فقدان المعلومات السياقية أو الخاصة بالأدوات في البناء.

مع هذا التغيير، ستبقى أي خاصية غير قياسية تضيفها إلى import.meta سليمة في الكود المُولد، مما يسمح باستخدام المعلومات الوصفية (meta-information) المخصصة أو الإشارات الإضافية في التطبيقات الحديثة.

if (!import.meta.UNKNOWN_PROPERTY) {
  // تخصيص وقت التشغيل (runtime assignment)
  import.meta.UNKNOWN_PROPERTY = "HELLO";
}

إذا لم يكن output.module مُفعلاً، سيستمر Webpack في إزالة الخصائص غير المعروفة ما لم تشر صراحةً إلى خلاف ذلك. للحفاظ عليها يدويًا، يمكنك تكوين module.parser.javascript.importMeta كـ 'preserve-unknown' في ملف webpack.config.js:

// webpack.config.js
module.exports = {
  module: {
    parser: {
      javascript: {
        importMeta: "preserve-unknown",
      },
    },
  },
};

بهذه الطريقة، حتى بدون output.module: true، سيتم الحفاظ على أي خاصية مخصصة لـ import.meta، مثل import.meta.customProp، في البناء.

تحكم أفضل في خرائط المصدر (Source Maps) في devtool

يسمح Webpack الآن لخيار devtool بقبول كل من سلسلة نصية (string) ومصفوفة من الكائنات (array of objects) للتكوينات المتقدمة.

يمكن أن يتضمن كل كائن في المصفوفة:

• type: والذي يمكن أن يكون "all", "css", أو "javascript".
• use: حيث تحدد نوع خريطة المصدر التي سيتم توليدها.

يتيح هذا تحديد أنواع مختلفة من خرائط المصدر للموارد المختلفة في مشروعك. على سبيل المثال:

// webpack.config.js
module.exports = {
  target: ["web", "node"],
  experiments: {
    css: true,
  },
  devtool: [
    {
      type: "javascript",
      use: "source-map",
    },
    {
      type: "css",
      use: "inline-source-map",
    },
  ],
};

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

هذا الخيار الجديد مفيد بشكل خاص إذا كنت تستخدم ميزة تحويل CSS التجريبية الخاصة بـ Webpack، حيث تمنحك تحكمًا أكبر في عملية تصحيح الأخطاء (debugging) وتحسّن التكامل مع الأدوات الخارجية.

الجدير بالذكر أن الصياغة النصية الكلاسيكية، مثل devtool: "source-map"، تظل صالحة تمامًا ومدعومة.

مخرجات ESM أنظف لـ Node.js وعمليات البناء الحديثة

يحسّن هذا التحسين في Webpack معالجة وتمثيل وحدات Node.js الأصلية (مثل fs, path, أو crypto) أثناء عملية الحزم، وخاصة عند استخدام الخيار output.module في التكوين. عند تفعيل output.module: true، يقوم Webpack الآن بتوليد استيرادات للوحدات الأصلية باستخدام صياغة ES module أي import ... from "module" بدلاً من require("module") الخاصة بـ CommonJS، بغض النظر عما إذا كان الكود سيعمل في بيئة الويب أو Node.js.

تحسينات وإصلاحات أخرى

• أصدر Webpack-dev-server إصدارًا جديدًا لتحديث التبعيات (dependencies) التي أُبلغ عن وجود ثغرات انتقالية بها، لذا يوصى بالتحديث. بالإضافة إلى ذلك، تمت إضافة خيار لإغلاق تراكب الخطأ (error overlay) بالضغط على مفتاح ESC، وتم إصلاح العديد من الأخطاء. تحقق من الإصدار لمزيد من المعلومات.
• تلقى Webpack-bundle-analyzer تحسينات وإصلاحات مهمة لتجربة المستخدم. تم حل المشكلات البصرية المتعلقة بـ tooltips في الوضع المظلم، وأصبح تحليل الحزم باستخدام IIFE أكثر قوة، مما يمنع الأخطاء. بالإضافة إلى ذلك، تمت إضافة دعم لضغط Zstandard، وهو متاح فقط في Node.js 22.15 أو أعلى. تحقق من سجل التغييرات لمزيد من المعلومات.
• يقدم Mini-css-extract-plugin ميزات جديدة وإصلاحات للأخطاء. من بين التغييرات الرئيسية، أصبحت الإضافة الآن تحترم الخيارين output.cssFilename و output.cssChunkFilename، مما يسمح بتحكم أدق في أسماء ملفات CSS المولدة. بالإضافة إلى ذلك، تم إصلاح خلل كان يمنع توليد contentHash للـ chunk عندما يكون حجم مجموعة وحدات CSS صفراً، مما يتجنب التجزئة (hashes) غير الضرورية في تلك الحالات. تحقق من الإصدار لمزيد من المعلومات.

تم حل العديد من الأخطاء منذ الإصدار 5.104. تحقق من سجل التغييرات (changelog) لمزيد من التفاصيل.

شكر

شكر كبير لجميع المساهمين والرعاة الذين جعلوا Webpack 5.105 ممكنًا. دعمكم، سواء كان عبر المساهمة بالكود، أو التوثيق، أو الرعاية المالية، يساعد في استمرار تطور وتحسن Webpack للجميع.