مُقيم مخاطر ترقية التبعيات: تحويل قائمة بالحزم القديمة إلى خطة ترقية مصنفة مرتبة
لماذا تهم هذه المطالبة
Dependency debt compounds silently. Each deferred upgrade doesn't just add one more overdue package — it makes the eventual upgrade riskier, because more changes stack up between your current version and the one you'll be forced onto during a security incident or an end-of-life deadline. Teams that never explicitly prioritize upgrades don't avoid the work; they just do it later, under worse conditions, usually as an unplanned emergency instead of a scheduled sprint task.
فيم نستخدمها
Your `npm outdated` output lists 34 packages behind, most flagged for major-version gaps. Your tech lead wants a prioritized upgrade plan before tomorrow's sprint planning, and you don't have time to read every changelog yourself.
المطالبة
Act as a senior engineer responsible for dependency management who has run upgrade cycles across dozens of production codebases and knows how deferred upgrades turn into emergency migrations. Context: Project type and stack: [e.g., "Node.js/TypeScript monorepo, ~200k LOC, deployed to production weekly"] Outdated dependencies: [PASTE THE LIST — package name, current version, latest version, e.g. from `npm outdated`, `pip list --outdated`, or `bundle outdated`] Changelog or release-notes excerpts, if you have them: [PASTE RELEVANT EXCERPTS, OR WRITE "NONE PROVIDED" FOR ANY PACKAGE] Team capacity this sprint: [e.g., "limited — can only take on 2-3 low-risk upgrades" or "dedicated tech-debt sprint, can absorb larger changes"] Task: For each dependency listed, assess: 1. How many major and minor versions behind it currently is 2. Its risk category — security-critical, breaking-change-heavy, or routine 3. A specific recommendation: upgrade now, schedule for next sprint, or defer (with a reason) Constraints: - Flag any dependency with a known CVE or security advisory as highest priority regardless of stated team capacity. - Clearly distinguish between "this WILL break something" (based on documented breaking changes you were given) and "this MIGHT break something" (no changelog provided, so assume moderate risk) — never present a guess with the same confidence as a documented fact. - The "upgrade now" shortlist must respect the stated team capacity — do not recommend more work than the team can realistically absorb this sprint. - If changelog excerpts weren't provided for a package, say so explicitly in your reasoning rather than inventing specific breaking changes. Output Format: 1. A ranked table: Package | Current → Latest | Risk Level | Recommendation | Reasoning 2. A "Do This Sprint" shortlist that respects the stated capacity 3. One clarifying question to ask before greenlighting the single riskiest upgrade on the list
النتيجة
| Package | Current → Latest | Risk Level | Recommendation | Reasoning |
|---|---|---|---|---|
| auth-token-lib | 2.3.1 → 2.3.9 | Security-Critical | Upgrade now | Changelog for 2.3.7 lists a fix for CVE-2026-31442, a token-validation bypass. This overrides capacity limits — security fixes are non-negotiable regardless of sprint load. |
| axios | 0.21.4 → 1.7.2 | Breaking-Change-Heavy | Schedule for next sprint | Major version jump (0.x → 1.x). Changelog confirms the default export pattern changed and several config options were renamed. This WILL require code changes across every file that imports axios directly — not a drop-in bump. |
| lodash | 4.17.15 → 4.17.21 | Routine | Upgrade now | Patch-only jump within the same minor version. No changelog excerpt was provided, but the version delta itself (patch-level only) makes breaking changes very unlikely. Low effort, safe to batch with the security fix above. |
| express | 4.17.1 → 4.19.2 | Routine | Upgrade now | Minor version bumps within Express 4.x have historically been backward-compatible. No changelog was provided for this specific range, so this is a moderate-confidence assessment, not a documented guarantee. |
| react | 17.0.2 → 18.3.1 | Breaking-Change-Heavy | Defer | Major version jump requiring the new root API (createRoot) and auditing all components for concurrent-rendering side effects. Given your stated capacity of 2-3 upgrades this sprint, this is too large to absorb alongside the security fix — defer to the dedicated tech-debt sprint. |
Do This Sprint (respecting stated capacity of 2-3 upgrades):
- auth-token-lib (security-critical, mandatory)
- lodash (near-zero risk, low effort)
- express (routine, moderate confidence)
Clarifying question before greenlighting axios 1.x: Do you have integration test coverage on every code path that calls axios directly, or only on the handful of endpoints your team remembers using it? A breaking-change-heavy upgrade is far riskier in code paths without test coverage, since you won't catch a broken call signature until it fails in production.
تراكم كل هندسة software backlog من التبعيات القديمة، وتعامل معها جميع الفرق تقريباً بنفس الطريقة غير المرضية: يلقي شخص نظرة على الـ output، ويشعر بالذنب لفترة وجيزة، ثم ينتقل للعمل على الميزات. المشكلة ليست في نقص الوعي — بل في أن تحويل قائمة تضم أكثر من ثلاثين package إلى خطة أولويات فعلية يستغرق وقتاً حقيقياً، وهذا الوقت يتنافس مباشرة مع عملية الشحن (shipping). تم بناء هذا الـ prompt لضغط عمل الفرز (triage) هذا في تمريرة واحدة.
لماذا تم هيكلة هذا الـ prompt بهذه الطريقة
الشرط الذي يطلب من الـ model التعامل مع أي CVE معروف على أنه ذو أولوية قصوى تلقائياً، بغض النظر عن سعة الفريق المعلنة، موجود لأن إصلاحات الأمان هي فئة واحدة من عمل التبعيات التي ليست اختيارية في الواقع. الـ prompt الذي يسمح لـ "السعة المحدودة" بإلغاء أولوية تصحيح أمان صمتًا سيكون خطيراً بشكل نشط للاعتماد عليه — والهدف الأساسي من أتمتة عملية الفرز هذه هو التأكد من عدم تفويت أي شيء مهم، وليس تبييض عذر مناسب لتخطيه.
التمييز بين "هذا سيكسر شيئاً ما بالتأكيد (WILL break something)" و"هذا قد يكسر شيئاً ما (MIGHT break something)" هو أهم شرط في الـ prompt بأكمله، وهو موجود لأن النمط الأكثر شيوعاً لفشل التخطيط المدعوم بالـ AI هو الثقة الزائفة. الـ model الذي يتم تزويده بمقتطف من سجل التغيير (changelog) يؤكد تغيير API كاسح يكون على أرض صلبة. الـ model الذي يُطلب منه تخمين ما إذا كان رفع الإصدار (version bump) بدون وثائق آمن يفعل شيئاً أقل موثوقية بشكل أساسي — وإذا تم تقديم كلاهما بنفس النبرة الواثقة، تصبح الخطة مضللة بشكل نشط. إجبار الـ model على تحديد الفئة التي تندرج تحتها كل تقييم يعني أنك تعرف بدقة التوصيات التي يجب الوثوق بها ظاهرياً وتلك التي تستحق فحصاً لمدة خمس دقائق لسجل التغيير قبل الالتزام بها.
قيد السعة هو ما يحول هذا من تقرير تبعيات عام إلى أtool فعلية لتخطيط الـ sprint. تقييم المخاطر الذي يتجاهل مقدار العمل الذي يمكن لفريقك استيعابه بشكل واقعي هذا الأسبوع هو نصيحة لفريق افتراضي، وليس لفريقك. إجبار القائمة المختصرة "افعل في هذا الـ sprint (Do This Sprint)" على احترام رقم سعة معينة يعني أن الـ output هو شيء يمكنك تسليمه مباشرة إلى تخطيط الـ sprint بدلاً من ترجمته بنفسك.
لماذا تنسيق الـ table مهم
الـ table المرتب، بدلاً من المقال السردي، مقصود بعناية. فرز التبعيات هو في جوهره مهمة مقارنة — فأنت تزن عدة packages مقابل بعضها البعض لتحديد ما يناسب السعة المحدودة — والـ table يتيح لك الفحص وإعادة الترتيب ذهنوياً بطريقة لا توفرها صيغة الفقرة لكل package. سؤال التوضيح الختامي حول تغطية الاختبارات موجود لأن أكبر مخاطر خفية في أي ترقية تغير كاسح ليست التغيير نفسه، بل ما إذا كنت ستلاحظ بالفعل إذا كان يكسر شيئاً ما — وهذا سؤال يمكن للـ model أن يحثك على الإجابة عليه ولكن لا يمكنه الإجابة عليه بناءً على الـ codebase الخاص بك وحدك.
كيفية تكييفه
بالنسبة لـ codebase ذو وصول ضعيف حقاً لسجل التغييرات (private packages، مشاريع مفتوحة المصدر مهجورة ذات ملاحظات إصدار قليلة)، توقع وصول المزيد من العناصر إلى فئة "قد يكسر شيئاً ما (MIGHT break something)" افتراضياً — هذا هو الـ prompt يعمل بشكل صحيح، وليس فشلاً. في تلك الحالة، يجدر إقران الـ output بفحص سريع لمشاكل GitHub لكل package للحصول على تقارير الأخطاء الأخيرة قبل وضع اللمسات الأخيرة على خطة الـ sprint.
بالنسبة للفرق التي تنفذ هذا ربع سنوي (quarterly) بدلاً من كل sprint، قم بتغيير إطار السعة من "هذا الـ sprint" إلى "هذا الربع"، وفكر في طلب تمريرة ثانية تجمع الـ packages حسب الـ framework الأساسي المشترك (مثل "جميع packages نظام تفاعل React") نظراً لأن قفزات الإصدارات الكبيرة في الـ framework الأساسي غالباً ما تجبر الـ packages ذات الصلة على التحديث بالتوازي على أي حال.