pnpm (Performant NPM) ดีกว่า npm และ yarn ในหลายด้าน โดยเฉพาะในเรื่อง ประสิทธิภาพ, ขนาดของ node_modules, และ ความเร็วในการติดตั้งแพ็กเกจ ค่ะ มาดูการเปรียบเทียบทีละด้านกัน:
เปรียบเทียบ pnpm vs npm
| ประเด็น | pnpm |
npm |
|---|---|---|
| 🚀 ความเร็วในการติดตั้ง | เร็วมาก เพราะใช้ hard links | ช้ากว่า pnpm
|
| 🧠 ใช้พื้นที่น้อย | แชร์ dependencies เดิมด้วย symlink/hard link ทำให้ไม่ซ้ำซ้อน | สร้างไฟล์ซ้ำในแต่ละโปรเจกต์ ทำให้เปลืองพื้นที่ |
📦 โครงสร้าง node_modules
|
ใช้แบบ isolated + symlink ไม่ทำให้ dependency ซ้อนกันลึก | ซ้อนกันลึกในบางกรณี ทำให้เกิดปัญหา เช่น path ยาวเกิน |
| 🧩 การแก้ dependency tree | ปลอดภัยและแม่นยำขึ้น เพราะไม่แก้ไขตรงๆ | อาจเจอปัญหา dependency ที่ซ้อนกันหรือ resolve ผิด |
| 🔒 ความเข้มงวด (strict) | เข้มงวดเรื่องการ import แพ็กเกจที่ไม่ได้อยู่ใน dependencies | ค่อนข้างหลวม อาจ import ได้แม้ไม่มีใน package.json
|
| 🧰 ใช้งานกับ monorepo ได้ดี | มี built-in support (pnpm workspaces) |
npm มี support เหมือนกัน (v7+) แต่ยังไม่เสถียรเท่า |
Hard link คือการเชื่อมโยง (link) ไฟล์หลายชื่อไปยัง ไฟล์ข้อมูลเดียวกันจริงๆ บนดิสก์ โดยที่ทุกชื่อไฟล์ (link) สามารถเข้าถึงข้อมูลเดียวกันได้ ไม่ใช่การก็อปปี้ไฟล์ใหม่
อธิบายแบบเข้าใจง่าย
| Hard Link | Symbolic Link (Symlink) | |
|---|---|---|
| 🧠 คืออะไร | อีกชื่อหนึ่งของไฟล์เดียวกัน | ไฟล์ที่ชี้ทางไปยังไฟล์อื่น |
| 📁 เก็บข้อมูลจริงไหม | ใช่ (แชร์ inode เดียวกัน) | ไม่ (แค่ชี้ทาง) |
| 🔗 เชื่อมแบบไหน | เชื่อมกับข้อมูลจริงโดยตรง | เชื่อมกับ path ของไฟล์อื่น |
| 🧨 ลบต้นทางแล้วเป็นยังไง | ไฟล์ยังอยู่ เพราะมี hard link อื่นอยู่ | ไฟล์พัง เพราะ symlink ชี้ทางไม่เจอ |
| 🔄 ใช้บ่อยเมื่อ | แชร์ข้อมูลซ้ำโดยไม่เปลืองพื้นที่ | สร้าง shortcut หรือ path ชี้ข้ามที่ |
ตัวอย่างในระบบ Unix/Linux
# สร้างไฟล์ต้นฉบับ
echo "hello" > original.txt
# สร้าง hard link
ln original.txt hardlink.txt
# ตรวจสอบ inode (ต้องเหมือนกัน)
ls -i
ผล:
- original.txt และ hardlink.txt จะใช้ข้อมูลเดียวกันบนดิสก์
- แก้ไขไฟล์ใดไฟล์หนึ่ง อีกไฟล์จะเห็นการเปลี่ยนแปลงทันที
ทำไม pnpm ใช้ hard link
pnpm ใช้ hard link เพื่อแชร์ไฟล์ dependency ใน .pnpm-store ไปยัง node_modules โดย:
- ไม่ก็อปปี้ไฟล์ซ้ำ
- ประหยัดพื้นที่
- ติดตั้งเร็วมาก
ตัวอย่าง:
.project1/node_modules/react -> hard link ไปยัง .pnpm-store/react
.project2/node_modules/react -> hard link ไปยัง .pnpm-store/react
สรุปสั้น ๆ
Hard Link คือ “ชื่ออื่นของไฟล์เดียวกัน” ที่เชื่อมกับข้อมูลจริงโดยตรง ไม่ได้แค่ชี้ทาง
ทำให้ไฟล์นั้น ไม่ถูกลบจนกว่า hard link สุดท้ายจะถูกลบ
pnpm ใช้สิ่งนี้เพื่อให้ติดตั้งไวและประหยัดพื้นที่สุด ๆ
Symlink ย่อมาจาก Symbolic Link หรือภาษาไทยแปลว่า:
"ลิงก์เชิงสัญลักษณ์" หรือ "ไฟล์ทางลัด"
(คล้าย ๆ shortcut บน Windows)
สรุปง่าย ๆ:
Symlink คือ ไฟล์ชนิดพิเศษที่ชี้ไปยัง path ของไฟล์/โฟลเดอร์อื่น
เวลาเปิด symlink เหมือนเรากำลังเข้าถึงไฟล์ปลายทางจริง ๆ
เปรียบเทียบกับ Hard Link
| Symlink | Hard Link | |
|---|---|---|
| 🔗 ชี้ไปยัง | Path ของไฟล์อื่น | ตัวข้อมูล (inode) ของไฟล์ |
| 🧱 เป็นคนละไฟล์ไหม | ใช่ | ไม่ใช่ (แชร์กันจริง) |
| 🗑 ลบต้นทาง | พัง (กลายเป็น broken link) | ใช้งานได้ต่อถ้ายังมี hard link อื่น |
| 📂 ข้ามโฟลเดอร์ / ไดรฟ์ได้ไหม | ✅ ได้ | ❌ ไม่ได้ |
| 📌 ใช้บ่อยเมื่อ | ทำทางลัด / รวม config หลายที่ | แชร์ไฟล์เดียวกันหลายชื่อ |
ตัวอย่างการสร้าง symlink (บน Unix / macOS / Linux)
ln -s /path/to/target my-link
ln -s /usr/local/bin/node ~/node-shortcut
ในโปรแกรมเมอร์ใช้ symlink ทำอะไร
- สร้าง ทางลัดระหว่างไฟล์/โฟลเดอร์
- ใช้ในระบบจัดการ dependency (เช่น npm, pnpm, yarn)
- ใช้ใน monorepo เพื่อเชื่อม lib ข้ามแพ็กเกจ
สรุปสั้น ๆ
Symlink คือ "ไฟล์พิเศษที่ทำตัวเหมือนป้ายบอกทาง"
เปิดมัน = เหมือนเปิดของปลายทางจริง ๆ
แต่ถ้าปลายทางหาย → symlink ใช้งานไม่ได้ (broken)
ตัวอย่างข้อดีของ pnpm
ติดตั้งไวมาก
pnpm install
# ใช้เวลาเร็วกว่า npm หลายเท่า โดยเฉพาะในโปรเจกต์ใหญ่
แชร์ dependency ระหว่างหลายโปรเจกต์
- ถ้ามีโปรเจกต์ A กับ B ใช้ react เวอร์ชันเดียวกัน
- pnpm จะโหลดแค่ครั้งเดียว แล้วใช้ลิงก์ไปยังโฟลเดอร์ .pnpm-store ที่แชร์กัน
ป้องกันปัญหา devDependency และ dependency ปะปนกัน
- pnpm จะเตือนทันทีถ้า import package ที่ไม่ได้ระบุไว้ใน package.json
คำเตือน
- ถ้าใช้ pnpm กับโปรเจกต์ที่ทีมยังใช้ npm อาจต้อง sync ให้ดี เช่น .lock file (pnpm-lock.yaml)
- บางไลบรารีที่เขียนมาเฉพาะกับ npm อาจไม่รองรับ symlink ที่ pnpm ใช้ (กรณีหายาก)
สรุป
pnpm เหมาะมากสำหรับ:
- โปรเจกต์ใหญ่
- โปรเจกต์ที่มีหลาย repo หรือ monorepo
- ทีมที่ต้องการจัดการ dependency อย่างมีระเบียบ
- ต้องการความเร็วและใช้ทรัพยากรอย่างมีประสิทธิภาพ
- ถ้าคุณใช้ npm อยู่และเจอปัญหาช้า, ขนาด node_modules ใหญ่ หรือ dependency ซ้อนกันยุ่งเหยิง — pnpm คือทางเลือกที่คุ้มมากครับ
Top comments (0)