Lockfile Converter: แปลง package-lock.json เป็น yarn.lock ได้ในเบราว์เซอร์
Lockfile Converter ช่วยแปลง package-lock.json เป็น yarn.lock (และกลับด้าน) โดย parse dependency graph ในเบราว์เซอร์ของคุณ พร้อมส่งต่อ versions, resolved URLs และ integrity hashes
Table of Contents
ทุกโปรเจกต์ JavaScript สักวันต้องเจอช่วงเวลายอกย้อนแบบเดียวกัน: ทีมตัดสินใจเปลี่ยนจาก npm ไปใช้ Yarn (หรือย้ายกลับ) แล้ว lockfile ที่ทุกคนพึ่งพาอยู่กลับอยู่ในฟอร์แมตที่ไม่ตรงกัน package.json ย้ายได้ในไม่กี่วินาที แต่ lockfile — ไฟล์ที่ lock dependency tree ทั้งหมดของคุณเอาไว้ — ต้องถูกแปลง การแก้ไฟล์ที่ generate อัตโนมัติหลายพันบรรทัดด้วยมือแทบเป็นไปไม่ได้ และการ regenerate ใหม่ทั้งหมดก็เสี่ยงที่จะได้เวอร์ชันต่างออกไปโดยไม่รู้ตัว Lockfile Converter ถูกสร้างมาแก้ปัญหานี้: แค่ paste หรือ load ไฟล์ package-lock.json หรือ yarn.lock เข้ามา เครื่องมือจะ parse dependency graph ในเบราว์เซอร์ของคุณ แล้ว convert เป็นอีกฟอร์แมตพร้อมส่งต่อ versions, resolved URLs และ integrity hashes ทั้งหมด
เพราะกระบวนการ convert ทั้งหมดรันฝั่ง client ไฟล์ของคุณจึงไม่ถูกอัปโหลดไปที่ใดเลย dependency tree ของคุณ — รวมถึงชื่อ private package และ URL ของ internal registry — ไม่เคยออกจากเครื่อง ทำให้เครื่องมือนี้ปลอดภัยกับโค้ดที่เป็นความลับ และเหมาะกับการเช็กอย่างเร็วระหว่าง code review โดยไม่ต้อง install CLI เพิ่มแม้แต่ตัวเดียว
ในบทความนี้เราจะพาไปดูวิธีใช้เครื่องมือทีละขั้นตอน สิ่งที่เก็บอยู่ใน lockfile จริง ๆ มีอะไรบ้าง และสถานการณ์จริง — การ migrate, การเทียบ lockfile ระหว่างทีม ไปจนถึงการกู้ CI — ที่เครื่องมือนี้ช่วยประหยัดเวลาได้มากที่สุด
ทำไมต้องใช้ Lockfile Converter?
- เปลี่ยน package manager โดยไม่เสีย version ที่ pin ไว้ เครื่องมือสร้าง graph ในฟอร์แมตใหม่จากเวอร์ชันที่ resolve ไว้แล้วใน lockfile เดิมทั้งหมด คุณจึงไม่ต้องเสี่ยงกับ registry ที่อาจส่งเวอร์ชันใหม่กว่ามาระหว่าง migration
- ทุกอย่างอยู่บนเครื่องคุณเท่านั้น การ parse และ convert เกิดขึ้นในเบราว์เซอร์ล้วน ๆ เหมาะกับ private package, internal registry และโค้ดลูกค้าที่ห้ามนำไป paste ในเว็บบริการแปลก ๆ
- integrity hash รอดตามไปด้วย ค่า integrity และ resolved URL ของแต่ละ package เดินทางข้ามฟอร์แมตไปพร้อมกัน lockfile ที่ได้มาจึงคงการรับประกันเชิงเข้ารหัสแบบเดียวกับต้นฉบับ
- เห็น graph ก่อนตัดสินใจ เครื่องมือ parse dependency graph ให้ก่อน คุณจึงตรวจสอบว่ามันเข้าใจไฟล์ถูกต้องแค่ไหน — ชื่อ, เวอร์ชัน, รูปร่างของ tree — ก่อนนำผลลัพธ์ไปใช้
- ไม่ต้อง install, ไม่ต้องสมัคร, ไม่ต้อง setup เปิดหน้าเว็บ วางไฟล์ ได้ผลลัพธ์ทันที ไม่มี CLI ให้ติดตั้งและไม่มีบัญชีให้สมัคร
- ใช้ได้สองทิศทาง ทั้ง package-lock.json เป็น yarn.lock และ yarn.lock กลับเป็น package-lock.json ใช้หน้าจอเดียวกัน
ฟีเจอร์หลัก
| ฟีเจอร์ | สิ่งที่ทำ |
|---|---|
| Paste หรือ load ไฟล์ | รับทั้ง package-lock.json และ yarn.lock ผ่านการวางเนื้อหาหรือโหลดไฟล์โดยตรง |
| Parse dependency graph ในเครื่อง | สร้าง package graph ในเบราว์เซอร์ของคุณก่อนเริ่ม convert |
| Convert สองทิศทาง | แปลง lockfile ของ npm เป็น yarn.lock และแปลง yarn.lock กลับเป็น package-lock.json |
| ส่งต่อข้อมูลสำคัญครบถ้วน | versions, resolved URLs และ integrity hashes ถูกถ่ายโอนไปยังผลลัพธ์ |
| รันฝั่ง client ทั้งหมด | ไม่มีขั้นตอนอัปโหลด — convert ทั้งหมดเกิดขึ้นในเบราว์เซอร์ของคุณ |
จุดที่ควรรู้เพิ่มเติม:
- dependency graph ที่ parse แล้วคือตัวกลางของกระบวนการ: เครื่องมืออ่าน lockfile ต้นทางเข้าเป็น graph แบบ normalize ก่อน จากนั้นจึง serialize เป็นฟอร์แมตปลายทาง
- เพราะ resolved URL และ integrity hash ถูกส่งต่อมา ไม่ใช่ไปดึงใหม่ ผลลัพธ์จึงสะท้อน artifact ชุดเดียวกับที่ install ครั้งแรกใช้จริง
- การ convert ยังเป็นเครื่องมือตรวจสอบที่ดีในตัว: ดู graph ที่ parse แล้วเพื่อจับเวอร์ชันซ้ำหรือ resolution ที่น่า surprise ก่อนแตะ repository จริง
วิธีใช้งาน Lockfile Converter
- โหลด lockfile ของคุณ เปิดเครื่องมือแล้ว paste เนื้อหาของ package-lock.json หรือ yarn.lock ลงในช่อง input หรือโหลดไฟล์โดยตรง เครื่องมือจะตรวจจับว่าคุณใช้ฟอร์แมตไหน
- ตรวจ dependency graph ที่ parse แล้ว เมื่อ parse เสร็จ ให้ดู graph ที่เครื่องมือดึงออกมา: ชื่อ package, เวอร์ชันที่ resolve และรูปร่างของ tree นี่คือโอกาสจับสิ่งผิดปกติก่อน convert
- Convert เป็นอีกฟอร์แมต สั่ง convert เครื่องมือจะ serialize graph ที่ parse แล้วเป็นฟอร์แมตตรงข้าม พร้อมส่งต่อ version, resolved URL และ integrity hash ของทุก package
- เทียบผลลัพธ์ อ่าน lockfile ที่ได้ แล้วสุ่มเช็ก package ที่คุ้นเคยสัก few ตัวกับไฟล์ต้นทาง: เวอร์ชันเดิม, integrity เดิม, resolved URL เดิม เมื่อพอใจแล้วค่อย copy ผลลัพธ์
- แทนที่ไฟล์แล้ว install บันทึกไฟล์ที่ convert แล้วลง repository ด้วยชื่อที่ถูกต้อง ลบ lockfile เดิมถ้ากำลังเปลี่ยน package manager จากนั้นรันคำสั่ง install ของ package manager ตัวใหม่เพื่อ validate ทุกอย่าง
ภายใน lockfile มีอะไรซ่อนอยู่
lockfile เกิดมาเพื่อแก้ปัญหาเดียว: package.json บอกเพียงว่าคุณ อนุญาต version range ไหน แต่มีแต่ lockfile ที่บันทึกว่าคุณ ได้อะไรมาจริง ๆ ถ้าไม่มี lockfile นักพัฒนาสองคนที่รัน install บน commit เดียวกันอาจได้ dependency tree คนละแบบ และ build ที่เวิร์กบนเครื่องหนึ่งกลับพังบนอีกเครื่อง lockfile จึง freeze tree ที่ resolve แล้วทั้งหมดเพื่อให้ทุก install เป็น deterministic และ reproducible
ข้อมูลสามประเภททำงานหนักที่สุด:
- versions ทุก dependency ทั้งตรงและ transitive ถูก pin ที่เวอร์ชันเป๊ะ ๆ นั่นคือความต่างระหว่าง "lodash ^4.17.21" กับ "lodash 4.17.21 ที่ install แล้ว"
- integrity hashes แต่ละ entry มี hash เชิงเข้ารหัสของ tarball ที่ install จริง ถ้า registry ส่ง byte ที่ต่างออกมา install จะ fail ทันที แทนที่จะรันโค้ดที่ไม่ได้ตรวจสอบแบบเงียบ ๆ
- resolved URLs ตำแหน่งที่แน่นอนที่ artifact ถูกดึงมา — ปกติคือ URL ของ registry แต่อาจชี้ไปที่ mirror หรือ internal registry ก็ได้
นอกจาก direct dependency แล้ว lockfile ยังบันทึก transitive graph ทั้งหมด: dependency ของ dependency รวมถึงกรณีที่สอง package ต้องการ major version ต่างกันของ library ตัวเดียวกันและทั้งสองเวอร์ชันถูกเก็บไว้คู่กัน
แล้วอะไรรอดจากการ convert บ้าง? versions, resolved URLs และ integrity hashes — แก่นของไฟล์ — เดินทางข้ามฟอร์แมตได้ครบ ส่วนที่ fresh install เป็นคน regenerate คือส่วนเฉพาะของแต่ละ package manager: รูปแบบการจัดเรียง, formatting และ metadata field ที่แต่ละเครื่องมือดูแลเอง นี่คือเหตุผลที่ flow ที่แนะนำคือ convert แล้วรัน install ตาม เพื่อให้ package manager ปลายทางจัดรายละเอียดโครงสร้างที่เหลือให้เรียบร้อย
เมื่อไรที่การ generate ใหม่สะอาดกว่า? ถ้า lockfile ต้นทางเก่ามาก ถูกแก้มือ หรือมี entry ที่ package manager ปัจจุบันปฏิเสธ การลบ lockfile แล้ว resolve ใหม่จะให้ tree ที่ package manager การันตีเต็มที่ — แลกกับความเสี่ยงที่จะได้เวอร์ชันใหม่กว่า เครื่องมือ convert นี้มีไว้สำหรับกรณีที่คุณต้องการเก็บ tree ที่ผ่านการทดสอบแล้วตัวต่อตัว
กรณีการใช้งานจริง
ย้าย repository จาก npm ไป Yarn (หรือย้ายกลับ)
ทีมเปลี่ยนไปใช้ Yarn เพราะ install เร็วกว่าหรือเพื่อ workflow แบบ monorepo และทุกคนต้องเริ่มจากจุดเดียวกัน ให้ convert package-lock.json เดิมเป็น yarn.lock ก่อน จากนั้น commit lockfile ใหม่พร้อม script และเอกสารที่อัปเดตแล้วใน pull request เดียว ทั้งทีมจะเริ่มจาก tree ที่ pin ไว้ชุดเดียวกัน แทนที่จะ resolve กันคนละทางแล้วหวังว่าผลจะเหมือนกัน
เปรียบเทียบ lockfile ระหว่างทีม
สองทีมแชร์ core library ตัวเดียวกันแต่สิ่งที่ install จริงเริ่มเหลื่อมกัน เพราะฝั่งหนึ่งใช้ npm อีกฝั่งใช้ Yarn diff ตรง ๆ จึงไม่มีความหมาย นำ lockfile ทั้งสองมา convert ให้อยู่ฟอร์แมตเดียวกันก่อน แล้วค่อย diff ความต่างของเวอร์ชันจะโดดออกมาทันที และคุณย้อนดูได้ว่า dependency ตัวไหนดึง package ที่แชร์กันไปคนละ release
มาตรฐานเดียวกันทั่วทั้งหลาย repository
องค์กรที่มี repository หลายสิบตัวปนกันทั้ง npm และ Yarn เมื่อรวมมาตรฐานเดียว ให้ convert lockfile ของแต่ละ repository ไปเป็นฟอร์แมตที่กำหนดทีละตัว โดยไม่ต้อง regenerate และทดสอบ dependency tree ใหม่ทั้งหมด ทุกทีมยังใช้เวอร์ชันที่ผ่านการ validate แล้ว ในขณะที่ tool landscape กลายเป็นชุดเดียวกัน
แก้ CI ที่พังหลังเปลี่ยนฟอร์แมต lockfile
pull request เข้ามาพร้อม lockfile คนละฟอร์แมตกับ pipeline ของ repository แล้ว build fail ทันที แทนที่จะให้ contributor resolve ใหม่ทั้งหมด ให้ convert lockfile ของเขาเป็นฟอร์แมตที่ CI คาดหวังในเครื่องของคุณ แล้ว commit และ push pipeline ยอมรับไฟล์ และเวอร์ชัน dependency ก็เป๊ะตรงกับที่ contributor ทดสอบมา
แนวปฏิบัติที่ดี
- commit lockfile ที่ convert แล้วทันที lockfile ที่ convert แล้วจะมีประโยชน์ก็ต่อเมื่ออยู่ใน version control ให้ commit พร้อมกับการเปลี่ยน package manager เพื่อให้ทุก teammate และ CI ได้ tree ชุดเดียวกัน
- รัน install หลัง convert เสมอ ถือว่าไฟล์ที่ convert แล้วเป็นจุดเริ่มต้นที่แข็งแรง แล้วปล่อยให้ package manager validate และเขียน metadata ที่จำเป็น การ install คือการตรวจความถูกต้องรอบสุดท้าย
- ลบ node_modules เมื่อเปลี่ยนฟอร์แมต artifact เก่าจาก package manager ตัวเดิมทำให้เกิด error งง ๆ การ install ลง directory ที่สะอาดจะทำให้ migration โปร่งใส
- ใช้ package manager เดียวต่อหนึ่ง repository การ convert lockfile ไว้สำหรับ migration ไม่ใช่ไว้รัน npm กับ Yarn คู่กัน lockfile สองไฟล์ใน repository เดียวคือสูตรของ drift
- ตรวจ graph ก่อน convert ทุกครั้ง มุมมอง graph คือการ audit dependency tree ฟรี ๆ ใช้มันจับเวอร์ชันซ้ำหรือเวอร์ชันที่ไม่คาดคิดก่อนที่มันจะติดไปกับฟอร์แมตใหม่
- อัปเดต CI และเอกสารในการเปลี่ยนแปลงเดียวกัน การเปลี่ยนฟอร์แมตหมายถึงการเปลี่ยนคำสั่ง install ใน pipeline และ README ด้วย ทำพร้อมกันเพื่อไม่ให้อะไรชี้ไปที่ lockfile ที่ไม่มีอยู่แล้ว
ครั้งต่อไปที่งานเปลี่ยน package manager ตกมาที่โต๊ะคุณ อย่าเดา ให้เปิด Lockfile Converter วาง lockfile เดิมลงไป แล้วส่งมอบไฟล์ที่ convert แล้วให้ทีม พร้อม version, resolved URL และ integrity hash ครบถ้วน — ใช้เวลาประมาณการรัน install หนึ่งรอบเท่านั้น
เครื่องมืออื่น ๆ ที่คุณอาจสนใจ:
ขอให้สนุกกับการ convert lockfile!
คำถามที่พบบ่อย
ถ: การ paste lockfile จากโปรเจกต์ส่วนตัวปลอดภัยหรือไม่? ตอบ: ปลอดภัยครับ Lockfile Converter parse และ convert ทั้งหมดในเบราว์เซอร์ของคุณ ไม่มีการอัปโหลดไปยังเซิร์ฟเวอร์ใด ๆ URL ของ internal registry และชื่อ private package จึงอยู่บนเครื่องคุณเท่านั้น
ถ: การ convert lockfile แล้วไม่ต้องรัน install ใหม่ใช่หรือไม่? ตอบ: ยังต้องรันครับ ให้ถือว่าไฟล์ที่ convert แล้วเป็นจุดตั้งต้น หลังแทนที่ lockfile ใน repository ให้รันคำสั่ง install ของ package manager ตัวใหม่ เพื่อให้มัน validate ไฟล์และเขียน metadata เฉพาะของตัวเอง
ถ: รองรับ lockfile ฟอร์แมตไหนบ้าง? ตอบ: เครื่องมือรับไฟล์ package-lock.json และ yarn.lock มาตรฐานที่ npm และ Yarn สร้างขึ้น หลังโหลดไฟล์ ให้ดู dependency graph ที่ parse แล้ว ซึ่งแสดงให้เห็นว่าเครื่องมือเข้าใจไฟล์ของคุณแค่ไหนก่อนกด convert
ถ: lockfile ที่ convert แล้วจะเหมือนไฟล์ที่ package manager สร้างเองทุกไบต์หรือไม่? ตอบ: formatting และลำดับอาจต่างจากไฟล์ที่สร้างโดยตรง แต่ versions, resolved URLs และ integrity hashes จะถูกส่งต่อมาครบ การ install รอบถัดไปจะจัดรายละเอียดโครงสร้างที่เหลือให้ตรงตามที่ package manager ปลายทางต้องการ