تبدأ معظم الفرق بنهج بسيط لإدارة التبعية. هذا غالبًا ما يشمل نص Bash الذي يعمل بشكل دوري. هذا ما يبدو عليه السيناريو اليدوي:

#!/bin/bash
echo "Starting manual dependency audit..."

# List all dependencies
echo "Installed dependencies:"
npm list --depth=0 > deps.txt
cat deps.txt

# Check for outdated ones
echo -e "\nChecking outdated dependencies..."
npm outdated > outdated.txt
cat outdated.txt

# Guess at unused ones (very crude)
echo -e "\nLooking for potentially unused dependencies..."
for dep in $(npm list --depth=0 | grep '├──' | cut -d' ' -f2 | cut -d@ -f1); do
    if ! find . -type f -name "*.js" -o -name "*.tsx" -o -name "*.ts" | xargs grep -l "$dep" > /dev/null 2>&1; then
        echo "$dep might be unused"
    fi
done

echo "Done! Check deps.txt and outdated.txt manually. Phew that was a lot of work!"

هذا النهج له عدة قيود ، بما في ذلك:

• إنه يدوي ، لذلك يجب على شخص ما أن يتذكره لتشغيله (ودعونا نكون صادقين ، وغالبًا ما أنسى تشغيلها في قواعد الكود الخاصة بي).
• فحص التبعية غير المستخدمة خام ، وغالبًا ما يكون غير دقيق.
• تنتشر النتائج عبر ملفات الإخراج المتعددة.
• لم يتم دمجها مع سير العمل أو خطوط أنابيب CI/CD.

يجب أن تكون هناك طريقة أفضل من هذا – كل؟

لحسن الحظ ، هناك ، في الواقع ، حل أفضل من البرنامج النصي اليدوي إذا كنت تعمل على GitHub – ويبدأ باستخدام مجموعة من أداة مطور الذكاء الاصطناعى لدينا ، Github Copilot ، أتمتة لدينا وأداة CI/CD. الإجراءات github ، و reparabot ، أداة التبعية الآلية لدينا.

إليك دليل خطوة بخطوة يمكنك استخدامه للقيام بذلك.

لتنفيذ إجراء GitHub ، يقوم Github Copilot بإنشاء ملف سير العمل الجديد في .github/workflows/dependency-audit.yml. إليك ملف سير العمل الذي ساعد في إنشاء:

name: Dependency Audit
on:
  schedule:
    - cron: '0 0 * * 1'  # Run weekly on Mondays
  workflow_dispatch:  # Allow manual triggering

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm ci

      - name: Install depcheck
        run: npm install -g depcheck

      - name: Run depcheck for unused dependencies
        run: depcheck --json > unused-deps.json

      - name: Run npm audit
        run: npm audit --json > security-audit.json

      - name: Generate report
        run: |
          echo "# Dependency Audit Report $(date)" > report.md
          echo "## Unused Dependencies" >> report.md
          cat unused-deps.json | jq -r '.dependencies()' >> report.md
          echo "## Security Issues" >> report.md
          cat security-audit.json | jq '.metadata.vulnerabilities' >> report.md

      - name: Create issue if problems found
        uses: peter-evans/create-issue-from-file@v4
        if: ${{ success() }}
        with:
          title: Weekly Dependency Audit
          content-filepath: ./report.md
          labels: maintenance, dependencies

مع ذلك ، أصبحت إدارة التبعية لدينا مؤتمتة بالكامل. دعونا نلخص كيف يعمل:

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

هذا النهج لا يوفر الوقت فحسب ، بل يقلل أيضًا بشكل كبير من المخاطر الأمنية وقضايا الأداء التي تنبع من التبعيات التي تتم إدارتها بشكل سيئ.

من خلال الجمع بين إمكانات الذكاء الاصطناعي لـ Github Copilot مع إجراءات GitHub واعتمدها ، حولنا مهمة يدوية مملة إلى حل تلقائي ومتكامل يحافظ على قاعلة الكود الخاصة بنا وآمنة. وسأأخذ هذه التوفير الزمني لفعل شيء أكثر إثارة للاهتمام ، مثل كشف لغز تلك الماعز الغريبة في البرنامج التلفزيوني قطع. أو من يدري ، ربما سأكتشف أخيرًا ما الذي يعنيه صقل Macrodata في هذا العرض (هل لدى أي شخص أي فكرة حتى الآن؟ الموسم الثاني يقتلني).