เวลาเราทำโปรเจกต์เว็บสัก 10 ตัวบนเครื่องที่ใช้แพ็กเกจชุดเดียวกัน การใช้ npm จะทำให้มีไฟล์สำเนาของแพ็กเกจนั้นนอนกินพื้นที่ดิสก์อยู่ถึง 10 ชุด แต่ถ้าสลับมาใช้ pnpm ตัวแพ็กเกจจะถูกเก็บไว้เพียงชุดเดียว แล้วสร้างลิงก์ให้ทุกโปรเจกต์ดึงไปใช้งานร่วมกันแทน

จริง ๆ แล้วทั้ง pnpm และ npm ต่างเป็นตัวจัดการแพ็กเกจ (package manager) ของ Node.js ที่ทำหน้าที่ดาวน์โหลดและจัดเก็บโค้ดสำเร็จรูปซึ่งโปรเจกต์ต้องพึ่งพา แต่ความต่างในวิธีจัดเก็บไฟล์กลับส่งผลตรงๆ กับสิ่งที่คนทำเว็บต้องเจอเป็นประจำ ทั้งเรื่องพื้นที่ดิสก์ที่ค่อยๆ หายไป และเวลาที่ต้องนั่งรอระหว่างสั่งติดตั้งแพ็กเกจ ยิ่งคนที่ชอบใช้ AI ช่วยสร้างโปรเจกต์ใหม่บ่อยๆ จนมีไฟล์ค้างอยู่ในเครื่องหลายสิบตัว จะยิ่งสัมผัสความต่างนี้ได้ชัดเจน

npm ก็อปแพ็กเกจซ้ำทุกโปรเจกต์

เวลาโปรเจกต์เว็บต้องการใช้โค้ดสำเร็จรูปจากคนอื่น เช่น ไลบรารีจัดการวันที่หรือชุดคำสั่งดึงข้อมูล ตัวจัดการแพ็กเกจจะดาวน์โหลดไฟล์เหล่านั้นมาเก็บไว้ในโฟลเดอร์ node_modules ของโปรเจกต์ โดยเรียกแต่ละชิ้นว่า dependency ซึ่งหมายถึงแพ็กเกจที่โปรเจกต์จำเป็นต้องพึ่งพาเพื่อการทำงาน

จุดที่เป็นปัญหาของ npm คือการเก็บไฟล์สำเนาแยกไว้ในทุกโปรเจกต์ ในหน้า Motivation ของเอกสารทางการ pnpm ได้ยกตัวอย่างให้เห็นภาพชัดๆ ว่า หากเรามีโปรเจกต์ถึง 100 ตัวที่ใช้ dependency เดียวกัน พื้นที่ดิสก์จะต้องแบกรับสำเนาของไฟล์ที่เหมือนกันเป๊ะถึง 100 ชุด นี่เลยเป็นสาเหตุที่โฟลเดอร์ node_modules บวมจนกลายเป็นหลาย GB และทำให้พื้นที่ดิสก์หายไปอีกก้อนทุกครั้งที่เปิดสร้างโปรเจกต์ใหม่

เก็บครั้งเดียวในคลังกลาง แล้วลิงก์ไปหา

pnpm เข้ามาแก้ปัญหานี้ด้วยการเปลี่ยนกลไกการจัดเก็บ แทนที่จะคัดลอกแพ็กเกจลงไปในทุกโปรเจกต์ pnpm จะเก็บทุกแพ็กเกจเอาไว้จุดเดียวบนเครื่องในคลังที่เรียกว่า content-addressable store ซึ่งเป็นคลังกลางที่จัดเก็บไฟล์โดยอิงตามเนื้อหา หากไฟล์ไหนมีเนื้อหาเหมือนกันก็จะเก็บไว้แค่ชุดเดียว ไม่มีการเก็บซ้ำซ้อน

พอโปรเจกต์ไหนต้องการใช้งานแพ็กเกจนั้น pnpm จะไม่คัดลอกไฟล์ออกมาใหม่ แต่จะใช้วิธี hard link เพื่อให้ไฟล์ใน node_modules ของโปรเจกต์ชี้กลับไปยังไฟล์ตัวจริงในคลังกลาง เปรียบเหมือนการสร้างทางลัดเข้าถึงไฟล์เดียวกันจากหลายแห่งโดยไม่กินพื้นที่ดิสก์เพิ่ม ส่งผลให้หลายโปรเจกต์ที่ใช้แพ็กเกจเวอร์ชันเดียวกันสามารถแชร์ไฟล์ชุดเดียวกันได้ทันที

นอกจากนี้ยังช่วยประหยัดพื้นที่ได้อีกเยอะตอนอัปเดตเวอร์ชัน สมมติว่าแพ็กเกจหนึ่งมีทั้งหมด 100 ไฟล์ และเวอร์ชันใหม่มีการแก้ไขไปเพียงไฟล์เดียว พอสั่ง pnpm update ระบบจะเพิ่มเฉพาะไฟล์ใหม่ลงในคลังกลางเพียงไฟล์เดียวเท่านั้น ไม่ใช่คัดลอกแพ็กเกจใหม่ยกชุด ด้วยกลไกนี้ พื้นที่ดิสก์ที่ประหยัดได้จะยิ่งเพิ่มขึ้นตามจำนวนโปรเจกต์และแพ็กเกจที่มีการใช้งานซ้ำกัน

ทำไม pnpm install ถึงเร็วกว่า

เบื้องหลังความเร็วในการติดตั้งก็มาจากแนวคิดเดียวกัน โดย pnpm แบ่งขั้นตอนการติดตั้งออกเป็น 3 ขั้นด้วยกัน เริ่มจากขั้นแรกคือการค้นหา dependency ทั้งหมดที่โปรเจกต์ต้องใช้แล้วดึงเข้าคลังกลาง ขั้นที่สองคือคำนวณโครงสร้างการจัดวางภายใน node_modules และขั้นที่สามคือการทำลิงก์ไฟล์จากคลังกลางเข้ามาใน node_modules

จุดต่างสำคัญจะอยู่ที่ขั้นตอนสุดท้าย เพราะวิธีติดตั้งแบบเดิมจำเป็นต้องเขียนไฟล์ของทุก dependency ลงใน node_modules จริงๆ ทีละตัว แต่ pnpm เพียงแค่ทำลิงก์ชี้กลับไปหาไฟล์ในคลังกลางที่ดาวน์โหลดมาเก็บไว้แล้ว ทำให้ไม่ต้องเสียเวลาเขียนไฟล์ซ้ำ การข้ามขั้นตอนการเขียนไฟล์ขนาดใหญ่ตรงนี้เองที่ทำให้การติดตั้งรวดเร็วขึ้นอย่างเห็นได้ชัด

node_modules ของ pnpm หน้าตาไม่เหมือน npm

อีกหนึ่งความต่างที่อาจไม่ได้สังเกตเห็นในตอนแรกคือโครงสร้างภายในโฟลเดอร์ node_modules เวลาติดตั้งแพ็กเกจด้วย npm หรือ Yarn Classic ตัวจัดการแพ็กเกจจะนำแพ็กเกจทั้งหมดขึ้นไปกองรวมกันไว้ที่ชั้นบนสุดของ node_modules ทั้งตัวที่สั่งติดตั้งเองโดยตรงและตัวที่แพ็กเกจอื่นลากติดมาด้วย ซึ่งส่งผลเสียคือโค้ดในโปรเจกต์อาจเผลอไปแอบเรียกใช้งานแพ็กเกจที่ไม่ได้ประกาศว่าจะใช้ได้ เพียงเพราะมันบังเอิญไปวางกองอยู่ในโฟลเดอร์เดียวกัน

pnpm เลือกทำต่างออกไป โดยค่าเริ่มต้นจะใช้ symlink วางเฉพาะ dependency ที่โปรเจกต์ประกาศใช้งานโดยตรงไว้ที่ชั้นบนสุดเท่านั้น โครงสร้าง node_modules ของ pnpm จึงไม่ได้แบนราบเหมือน npm ข้อดีคือโค้ดจะเรียกใช้งานได้เฉพาะแพ็กเกจที่ประกาศไว้จริง ช่วยป้องกันปัญหาบั๊กจากการเผลอไปพึ่งพาแพ็กเกจที่ไม่ได้ระบุไว้ตั้งแต่แรก

อย่างไรก็ตาม วิธีนี้ก็มีข้อแลกเปลี่ยนอยู่บ้าง เนื่องจากเครื่องมือบางตัวอาจทำงานร่วมกับ symlink ได้ไม่ดีนัก หากพบปัญหานี้ เราก็ยังสามารถใช้งาน pnpm ต่อได้ โดยตั้งค่า nodeLinker เป็น hoisted เพื่อสั่งให้ pnpm สร้าง node_modules แบบแบนราบคล้ายกับ npm และ Yarn Classic แทน

เริ่มใช้ pnpm ยังไง

การเริ่มต้นเปลี่ยนมาใช้ pnpm แทบไม่ต้องปรับเปลี่ยนวิธีทำงานเดิมเลย เพราะคำสั่งที่ใช้งานในชีวิตประจำวันมีรูปแบบที่คนที่เคยใช้ npm คุ้นเคยอยู่แล้ว

pnpm install          # ลง dependency ทั้งหมดตาม package.json
pnpm add <package>    # เพิ่มแพ็กเกจใหม่
pnpm update           # อัปเดตแพ็กเกจ
pnpm remove <package> # เอาแพ็กเกจออก

สำหรับวิธีติดตั้งตัว pnpm รวมไปถึงการตั้งค่าเชิงลึก คุณสามารถเข้าไปดูได้ที่เว็บไซต์ทางการของ pnpm ซึ่งมีคู่มือไว้อย่างครบถ้วน เมื่อติดตั้งเรียบร้อยแล้ว โปรเจกต์ที่เคยรันด้วย npm ก็สามารถย้ายมาใช้ชุดคำสั่งข้างต้นได้เกือบตรงตัว

v12 มาแล้ว แต่ยังเป็น alpha

เครื่องมืออย่าง pnpm เองก็มีการขยับขยายอย่างต่อเนื่อง โดยเวอร์ชันที่เอกสารทางการยังอิงอยู่นั้นเป็นสาย 11.x ส่วนรุ่นถัดไปอย่าง v12 เพิ่งปล่อยออกมาในสถานะ alpha ซึ่งยังคงเป็นรุ่นทดลองที่ยังไม่นิ่งพอจะเรียกว่าเสถียร

ตัวอย่างล่าสุดคือ v12.0.0-alpha.18 ที่ถูกปล่อยผ่านบอทอัตโนมัติของโปรเจกต์ และติดป้าย Pre-release ไว้ชัดเจนบนหน้า GitHub ของ pnpm การเปลี่ยนแปลงในรุ่นนี้เน้นเรื่องการจัดการ workspace และคำสั่ง CLI เป็นหลัก เช่น ปรับรูปแบบคำสั่ง pnpm version ให้ทำงานแบบเดียวกับ npm มากขึ้น โดยไม่ได้ไปแตะแก่นเรื่องคลังกลางและการลิงก์ไฟล์ที่เป็นหัวใจสำคัญของความเร็วและการประหยัดดิสก์

การขยับของ pnpm ถือเป็นส่วนหนึ่งของภาพใหญ่ที่เครื่องมือสาย JavaScript กำลังปรับตัวกันทั้งแผง ทั้ง Node.js, Astro และ Vite ที่ทยอยออกเวอร์ชันใหม่กันรัวๆ (รวมไว้ในสัปดาห์ที่เครื่องมือสาย JavaScript ขยับยกแผง)

ครั้งแรกที่สลับมาใช้อาจยังไม่รู้สึกว่าต่างมากนัก แต่พอสร้างโปรเจกต์ตัวถัดไป จะเห็นเลยว่า node_modules ก้อนใหม่แทบไม่กินดิสก์เพิ่ม เพราะแพ็กเกจที่ต้องใช้ส่วนใหญ่นอนรออยู่ในคลังกลางแล้ว การลองสร้างอะไรเล่นๆ อีกสักตัวจึงไม่ต้องมานั่งลุ้นว่าดิสก์จะพอไหม

ที่มา:

• เอกสารทางการของ Motivation · pnpm
• release Release pnpm 12 Alpha 18 · pnpm/pnpm บน GitHub