ตรวจแพ็กเกจที่ AI แนะนำก่อนติดตั้ง

เวลาขอให้ AI ช่วยทำฟีเจอร์ใหม่ สิ่งที่ตามมาบ่อยคือบรรทัด composer require ... หรือ npm install ... ที่เรา copy ไปรันแทบจะทันที แต่ทุกแพ็กเกจที่เพิ่มเข้ามาคือโค้ดของคนอื่นที่จะรันด้วยสิทธิ์เดียวกับแอปของเรา และอาจอยู่ในระบบไปอีกหลายปี บทความนี้ให้ขั้นตอนตรวจแพ็กเกจที่ใช้ได้จริงก่อนติดตั้ง ตั้งแต่ดูผู้ดูแล ความเคลื่อนไหว ไลเซนส์ ไปจนถึงการใช้ composer audit, npm audit และการดูแล lock file ให้ทีมได้ dependency ชุดเดียวกันทุกเครื่อง

ก่อนตรวจ: ถามก่อนว่าต้องใช้แพ็กเกจนี้ไหม

AI มีแนวโน้มเสนอแพ็กเกจสำหรับงานที่ภาษาหรือ framework ทำได้อยู่แล้ว เช่น แพ็กเกจจัดการวันที่ ทั้งที่ DateTimeImmutable และ Yii::$app->formatter ทำได้, แพ็กเกจสร้าง UUID ทั้งที่ฐานข้อมูลสร้างให้ได้ หรือแพ็กเกจ JavaScript ขนาดใหญ่เพื่อใช้ฟังก์ชันเดียว ก่อนเริ่มตรวจ ให้ตอบสามคำถาม

• PHP, Yii2 หรือ browser API ทำเรื่องนี้ได้อยู่แล้วหรือไม่
• ถ้าเขียนเองไม่กี่สิบบรรทัดและมี test รองรับ จะคุ้มกว่าการเพิ่ม dependency ไหม
• ในโปรเจกต์มีแพ็กเกจที่ทำเรื่องนี้อยู่แล้วหรือเปล่า

prompt ที่ช่วยได้คือ "ถ้าทำได้ด้วยความสามารถของ PHP 8 และ Yii2 ที่มีอยู่ ให้ใช้วิธีนั้นก่อน ถ้าจำเป็นต้องใช้แพ็กเกจเพิ่ม ให้บอกเหตุผลและทางเลือกอย่างน้อยสองตัว" แล้วนำชื่อที่ได้มาตรวจต่อ

เช็กลิสต์ตรวจแพ็กเกจก่อนติดตั้ง

ข้อมูลส่วนใหญ่ดูได้จากหน้าแพ็กเกจใน Packagist หรือ npm และจาก repository ต้นทาง ใช้ตารางนี้เป็นเกณฑ์

ไม่มีเกณฑ์ข้อไหนตัดสินได้เด็ดขาดข้อเดียว แพ็กเกจที่ไม่อัปเดตนานอาจเพราะเสถียรแล้วก็ได้ แต่ถ้าหลายข้อเป็นสัญญาณอันตรายพร้อมกัน ให้หาทางเลือกอื่น เรื่องไลเซนส์ถ้าไม่แน่ใจให้ปรึกษาผู้รับผิดชอบด้านกฎหมายขององค์กร ข้อความในบทความนี้ไม่ใช่คำแนะนำทางกฎหมาย

ใช้คำสั่งช่วยดูข้อมูลก่อนติดตั้ง

ทั้ง Composer และ npm ดูข้อมูลแพ็กเกจได้โดยยังไม่ต้องติดตั้ง

# Composer: ดูรายละเอียดแพ็กเกจจาก registry
composer show --available vendor-name/package-name

# npm: ดูผู้ดูแล ไลเซนส์ repository และวันที่แก้ไขล่าสุด
npm view package-name maintainers license repository.url time.modified

# npm: ดู scripts ที่จะรันตอนติดตั้ง
npm view package-name scripts

ถ้าต้องการลองแพ็กเกจ npm โดยไม่ให้ install scripts ทำงาน ใช้ npm install --ignore-scripts ในโปรเจกต์ทดลองแยก แล้วอ่านโค้ดใน node_modules/ ก่อน ฝั่ง Composer ถ้ามีคำถามว่าจะอนุญาต plugin หรือไม่ ให้หยุดอ่านก่อนตอบ และบันทึกการตัดสินใจไว้ใน composer.json

{
    "config": {
        "allow-plugins": {
            "yiisoft/yii2-composer": true
        }
    }
}

การระบุ plugin ที่อนุญาตไว้ชัดเจนแบบนี้ ทำให้ถ้ามีแพ็กเกจใหม่พยายามเพิ่ม plugin ตัวอื่นเข้ามา เราจะเห็นใน diff ของ PR

composer audit และ npm audit

หลังติดตั้งแล้ว ให้ตรวจว่ามีช่องโหว่ที่รู้จักในเวอร์ชันที่ใช้หรือไม่ ทั้งสองเครื่องมือเทียบเวอร์ชันใน lock file กับฐานข้อมูล security advisory

# PHP
composer audit
composer audit --no-dev            # เฉพาะแพ็กเกจที่ขึ้น production

# JavaScript
npm audit
npm audit --omit=dev --audit-level=high

ข้อควรระวัง:

• audit ตรวจได้เฉพาะช่องโหว่ที่มีการรายงานแล้ว แพ็กเกจที่ตั้งใจใส่โค้ดอันตรายและยังไม่มีใครรายงานจะผ่าน audit ได้ จึงต้องตรวจตามเช็กลิสต์ก่อนติดตั้งด้วย
• อย่ารัน npm audit fix --force ตามที่ AI แนะนำโดยไม่ดู เพราะอาจอัปเกรดข้าม major version และทำให้ระบบพัง
• ถ้าช่องโหว่ไม่กระทบการใช้งานของเรา ให้บันทึกเหตุผลไว้ ไม่ใช่ปิดการแจ้งเตือนเงียบ ๆ
• นำ audit ไปใส่ใน CI ให้รันทุก build ดูวิธีได้ในบทความ "CI/CD กับ AI: เขียน Pipeline ให้ทำงานจริง"

Lock file: ให้ทุกเครื่องได้ของชุดเดียวกัน

composer.lock และ package-lock.json บันทึกเวอร์ชันที่แน่นอนของทุกแพ็กเกจ รวมถึง dependency ต่อเนื่อง สำหรับแอปพลิเคชัน (ไม่ใช่ไลบรารีที่แจกให้คนอื่นใช้) ให้ commit lock file เสมอ และใช้คำสั่งที่ยึดตาม lock file ในการ deploy และ CI

# ติดตั้งตาม lock file เท่านั้น
composer install --no-dev --prefer-dist --no-interaction --optimize-autoloader
npm ci

# อัปเดตเฉพาะแพ็กเกจที่ตั้งใจ แล้ว review diff ของ lock file
composer update vendor-name/package-name --with-dependencies
npm update package-name

สิ่งที่ควรดูใน PR ทุกครั้งที่ lock file เปลี่ยน:

• มีแพ็กเกจใหม่ที่ไม่ได้ตั้งใจเพิ่มหรือไม่ โดยเฉพาะ dependency ต่อเนื่อง
• URL ของแหล่งดาวน์โหลดยังชี้ไปที่ registry ที่เราใช้ ไม่ใช่โดเมนแปลก ๆ
• เวอร์ชันถูกอัปเกรดข้าม major โดยไม่มีใครตั้งใจหรือไม่

ระวังกรณีที่ AI แนะนำให้ลบ lock file แล้วติดตั้งใหม่เพื่อแก้ปัญหา conflict วิธีนี้อาจอัปเกรดแพ็กเกจทั้งโปรเจกต์ในครั้งเดียว และทำให้หาสาเหตุของปัญหาที่ตามมาได้ยาก

ขั้นตอนในทีม: จาก AI แนะนำ ถึง merge

1. AI เสนอแพ็กเกจ พร้อมเหตุผลและทางเลือก
2. ผู้พัฒนาตรวจตามเช็กลิสต์ และเขียนเหตุผลสั้น ๆ ในคำอธิบาย PR ว่าทำไมเลือกตัวนี้
3. ติดตั้งใน branch แยก รัน test และ composer audit หรือ npm audit
4. ผู้ review ดู diff ของ composer.json, lock file และ allow-plugins
5. CI รัน audit ซ้ำทุก build เพื่อจับช่องโหว่ที่ถูกรายงานภายหลัง

สรุป

• ถามก่อนเสมอว่าต้องใช้แพ็กเกจนี้จริงไหม เพราะทุก dependency คือภาระและความเสี่ยงระยะยาว
• ตรวจชื่อ ผู้ดูแล ความเคลื่อนไหว install scripts และไลเซนส์ ก่อนติดตั้ง
• ใช้ composer audit และ npm audit เป็นประจำ แต่รู้ว่ามันจับได้เฉพาะช่องโหว่ที่ถูกรายงานแล้ว
• commit lock file ใช้ composer install และ npm ci ใน CI และ review diff ของ lock file ทุกครั้ง

ลองทำ

เปิด composer.json ของโปรเจกต์ที่ดูแลอยู่ เลือกแพ็กเกจใน require มา 3 ตัว แล้วตรวจตามตารางเช็กลิสต์ จดว่าแต่ละตัวผ่านกี่ข้อ จากนั้นรัน composer audit และ npm audit (ถ้ามี) บันทึกผล และตรวจว่า allow-plugins ระบุ plugin ที่อนุญาตไว้ครบและไม่มีตัวที่ไม่รู้จัก