โพสต์บล็อกล่าสุดที่อ้างว่า lockfiles นั้นไม่จำเป็นอย่างแน่นอน ได้จุดประกายการถกเถียงอย่างรุนแรงในชุมชนนักพัฒนา ผู้เขียนอ้างว่าระบบจัดการ dependency จะทำงานได้ดีกว่าหากไม่มี lockfiles โดยชี้ไปที่ความสำเร็จของ Maven ที่ไม่ใช้ lockfiles มา 20 ปี อย่างไรก็ตาม การตอบสนองจากชุมชนเผยให้เห็นความแตกแยกอย่างลึกซึ้งเกี่ยวกับแง่มุมพื้นฐานของการพัฒนาซอฟต์แวร์สมัยใหม่
การเปรียบเทียบการจัดการ Dependency ระหว่าง Maven กับ NPM
- Maven: มากกว่า 20 ปีโดยไม่มี lockfiles ใช้กลยุทธ์การแก้ไข dependency แบบ "nearest dependency"
- NPM: ใช้ package-lock.json เพื่อการ build ที่ทำซ้ำได้
- Cargo (Rust): ต้องการการจัดตำแหน่ง version เพื่อความเข้ากันได้ของ type ในภาษาที่คอมไพล์
- .NET: ไม่มี lockfiles ใช้ fixed versions เป็น best practice
การอัปเดตด้านความปลอดภัยขับเคลื่อนความจำเป็นของ Version Ranges
ข้อโต้แย้งที่น่าสนใจที่สุดสำหรับ lockfiles มุ่งเน้นไปที่ช่องโหว่ด้านความปลอดภัย เมื่อมีการค้นพบข้อบกพร่องด้านความปลอดภัยใน transitive dependency นักพัฒนาต้องการความสามารถในการอัปเดตอย่างรวดเร็วโดยไม่ต้องรอให้ผู้เขียน library ทุกคนปล่อยเวอร์ชันใหม่ สถานการณ์นี้เกิดขึ้นเป็นประจำในแอปพลิเคชันในโลกจริง ซึ่งแพตช์ความปลอดภัยต้องถูกปรับใช้อย่างรวดเร็วกับระบบ production
ชุมชนชี้ให้เห็นว่าด้วยเวอร์ชันที่คงที่ เจ้าของแอปพลิเคชันจะติดอยู่กับ dependencies ที่มีช่องโหว่จนกว่า library ทุกตัวในห่วงโซ่จะได้รับการอัปเดต สิ่งนี้สร้างความล่าช้าที่อันตรายในเวลาตอบสนองด้านความปลอดภัย โดยเฉพาะเมื่อผู้ดูแล library ไม่อยู่หรือตอบสนองช้า
ข้อโต้แย้งสำคัญที่สนับสนุน Lockfiles
- ความปลอดภัย: ช่วยให้สามารถอัปเดตการพึ่งพาแบบทรานซิทีฟที่มีช่องโหว่ได้อย่างรวดเร็ว
- การทำซ้ำได้: รับประกันการ build ที่เหมือนกันทุกประการในสภาพแวดล้อมการพัฒนา staging และ production
- การแก้ไขข้อขัดแย้ง: ช่วยให้อัลกอริทึมการแก้ไขการพึ่งพาสามารถหาเวอร์ชันที่เข้ากันได้
- ความปลอดภัยของประเภทข้อมูล: รับประกันความเข้ากันได้ของ memory layout ในภาษาที่ต้องคอมไพล์
ความขัดแย้งของ Dependencies เผยให้เห็นความท้าทายในการแก้ไขที่ซับซ้อน
ผู้วิจารณ์จุดยืนต่อต้าน lockfile เน้นปัญหาพื้นฐาน: จะเกิดอะไรขึ้นเมื่อ libraries หลายตัวต้องพึ่งพาเวอร์ชันที่แตกต่างกันของ dependency เดียวกัน การอภิปรายของชุมชนเผยให้เห็นว่าแนวทางของ Maven ต่อปัญหานี้ไม่ได้สวยงามเลย โดยใช้สิ่งที่ผู้แสดงความเห็นคนหนึ่งอธิบายว่าเป็นสิ่งที่บ้าคลั่งสำหรับการแก้ไขความขัดแย้ง
ในภาษาที่คอมไพล์แล้ว สิ่งนี้กลายเป็นสิ่งที่สำคัญยิ่งขึ้น เมื่อ libraries ต้องการส่งผ่านโครงสร้างข้อมูลระหว่างกัน พวกมันต้องใช้เวอร์ชันเดียวกันเป็นอย่างแน่นอนเพื่อให้แน่ใจว่าเลย์เอาต์หน่วยความจำเข้ากันได้ Version ranges ช่วยให้อัลกอริธึมการแก้ไข dependency สามารถหาเวอร์ชันที่เข้ากันได้ที่ตอบสนองความต้องการทั้งหมด
Dependencies ของแอปพลิเคชันและ Library สร้างความต้องการที่แตกต่างกัน
การถกเถียงเผยให้เห็นความแตกต่างที่สำคัญที่บทความต้นฉบับอาจมองข้าม นักพัฒนาหลายคนโต้แย้งว่า lockfiles มีจุดประสงค์ที่แตกต่างกันสำหรับแอปพลิเคชันเทียบกับ libraries สำหรับแอปพลิเคชันที่กำลังจะ deploy ไปยัง production การทำซ้ำได้อย่างแน่นอนเป็นสิ่งสำคัญเพื่อให้แน่ใจว่าสภาพแวดล้อมการพัฒนา staging และ production ตรงกันอย่างสมบูรณ์
ฉันมอง lockfiles เป็นสิ่งที่คุณใช้สำหรับแอปพลิเคชันที่คุณกำลัง deploy - หากคุณรันสิ่งต่างๆ เช่น web app มันจะมีประโยชน์มากในการทราบว่าอะไรถูก deploy ไปยัง production อย่างแน่นอน
ในทางกลับกัน Libraries ควรหลีกเลี่ยงการล็อกเวอร์ชันที่แน่นอนเพื่อป้องกันความขัดแย้งเมื่อรวมเข้ากับแอปพลิเคชันที่ใหญ่กว่า มุมมองที่ละเอียดอ่อนนี้แสดงให้เห็นว่าการถกเถียงเรื่อง lockfile ไม่ใช่เรื่องขาวดำ
ข้อโต้แย้งหลักต่อ Lockfiles
- ความซับซ้อน: เพิ่มความซับซ้อนที่ไม่จำเป็นให้กับการจัดการ dependency
- ไม่เป็นแบบแผน: ช่วงเวอร์ชันทำให้การ build ขึ้นอยู่กับเวลาที่ build มากกว่าเวลาที่ publish
- ฟีเจอร์ที่ไม่ได้ใช้: dependency ที่ถูกล็อกทำให้ประโยชน์ของช่วงเวอร์ชันหมดไป
- ทางเลือกที่พิสูจน์แล้ว: Maven แสดงให้เห็นความสำเร็จในระดับใหญ่โดยไม่ต้องใช้ lockfiles
ข้อกังวลเกี่ยวกับประสิทธิภาพการ Build และประสบการณ์นักพัฒนา
การอภิปรายของชุมชนยังสัมผัสถึงข้อกังวลเชิงปฏิบัติเกี่ยวกับเวลา build และขั้นตอนการทำงานของนักพัฒนา หากไม่มี lockfiles และ version ranges นักพัฒนาจะต้องประสานงานการอัปเดตเวอร์ชันด้วยตนเองทั่วทั้ง dependency trees สิ่งนี้อาจทำให้การพัฒนาช้าลงอย่างมากและทำให้การอัปเดตความปลอดภัยยุ่งยากในการดำเนินการ
นักพัฒนาบางคนสังเกตว่าแม้จะมี lockfiles ความซับซ้อนพื้นฐานของการจัดการ dependency ยังคงอยู่ เครื่องมือเพียงแค่ให้การแลกเปลี่ยนที่แตกต่างกันระหว่างการควบคุม ความสะดวกสบาย และความสามารถในการทำซ้ำ
การตอบสนองของชุมชนที่รุนแรงต่อโพสต์บล็อกนี้แสดงให้เห็นว่าการจัดการ dependency ยังคงเป็นหนึ่งในแง่มุมที่ท้าทายที่สุดของการพัฒนาซอฟต์แวร์สมัยใหม่ ในขณะที่วิสัยทัศน์ของผู้เขียนเกี่ยวกับการ build ที่เรียบง่ายและแน่นอนนั้นน่าสนใจ ข้อจำกัดในโลกจริงของความปลอดภัย ความเข้ากันได้ และประสิทธิผลของนักพัฒนาสร้างความต้องการที่ซับซ้อนที่ lockfiles พยายามจะจัดการ
อ้างอิง: We shouldn't have needed lockfiles