เรากำลังใช้เส้นด้ายสำหรับการติดตั้ง pkg ที่กำหนดไว้ทั้งหมดของเรา แต่ไม่ได้ป้องกันไม่ให้ผู้ใช้ใช้ npm - ฉันเดาว่าการมีไฟล์ทั้งสองนี้จะทำให้เกิดปัญหาอย่างไรก็ตาม ควรเพิ่มใน. gitignore dir ของคุณหรือไม่
คำตอบ:
ตามที่กล่าวไว้ในที่อื่น ๆ ไฟล์ล็อกการพึ่งพาซึ่งได้รับการสนับสนุนโดยระบบการจัดการแพ็กเกจจำนวนมาก (เช่น: ผู้เรียบเรียงและชุดรวมกลุ่ม ) ควรยึดมั่นกับโค้ดเบสในโปรเจ็กต์ปลายทาง - เพื่อให้แต่ละคนที่พยายามรันโปรเจ็กต์นั้นทำ เพื่อให้มีตรงชุดทดสอบการอ้างอิง
มีความชัดเจนน้อยกว่าว่าควรผูกไฟล์ล็อกไว้ในแพ็กเกจที่ตั้งใจจะรวมไว้ในโปรเจ็กต์อื่น ๆ หรือไม่ (ซึ่งเป็นที่ต้องการของการอ้างอิงแบบหลวม ๆ ) อย่างไรก็ตามทั้งYarnและ NPM (ตามที่ @Cyrille ครอบคลุม) จะเพิกเฉยอย่างชาญฉลาดyarn.lockและpackage-lock.jsonตามลำดับเมื่อจำเป็นทำให้ปลอดภัยในการส่งไฟล์ล็อกเหล่านี้เสมอ
ดังนั้นคุณควรยอมรับอย่างน้อยหนึ่งรายการyarn.lockหรือpackage-lock.jsonขึ้นอยู่กับตัวจัดการแพ็คเกจที่คุณใช้
ในปัจจุบันเรามีระบบการจัดการแพ็คเกจที่แตกต่างกันสองระบบซึ่งทั้งสองติดตั้งชุดการอ้างอิงเดียวกันจากpackage.jsonแต่สร้างและอ่านจากไฟล์ล็อกสองไฟล์ที่แตกต่างกัน NPM 5 สร้างในขณะที่สร้างเส้นด้ายpackage-lock.jsonyarn.lock
หากคุณตกลงแสดงpackage-lock.jsonว่าคุณกำลังสร้างเพื่อรองรับผู้ที่ติดตั้งการอ้างอิงของคุณด้วย NPM 5 หากคุณตกลงแสดงyarn.lockว่าคุณกำลังสร้างเพื่อรองรับผู้ที่ติดตั้งการอ้างอิงด้วย Yarn
ไม่ว่าคุณจะเลือกที่จะกระทำyarn.lockหรือpackage-lock.jsonหรือทั้งสองอย่างขึ้นอยู่กับว่าผู้ที่พัฒนาในโครงการของคุณใช้เฉพาะ Yarn หรือ NPM 5 หรือทั้งสองอย่าง หากโครงการของคุณเป็นโอเพ่นซอร์สสิ่งที่เป็นมิตรกับชุมชนที่สุดที่ควรทำก็คือการยอมรับทั้งสองอย่างและมีกระบวนการอัตโนมัติเพื่อให้แน่ใจyarn.lockและpackage-lock.jsonซิงค์กันอยู่เสมอ
ปรับปรุง:เส้นด้ายได้แนะนำตอนนี้คำสั่งซึ่งจะสร้างไฟล์จากไฟล์ ซึ่งอาจมีประโยชน์ในการทำให้ไฟล์ทั้งสองซิงค์กัน (ขอบคุณ @weakish)importyarn.lockpackage-lock.json
ปัญหานี้ได้รับการกล่าวถึงอย่างยาวนานในโครงการ Yarn ใน:
ตอนนี้ทั้งสองปิดแล้ว
yarn importเป็นที่รู้จักในปี 2018 yarnpkg.com/blog/2018/06/04/yarn-import-package-lock
คุณควรคอมมิตไฟล์ล็อกแผนผังการพึ่งพา 1 ไฟล์ แต่คุณไม่ควรกระทำทั้งสองอย่าง สิ่งนี้ยังต้องการการกำหนดมาตรฐานบนเส้นด้ายหรือ npm (ไม่ใช่ทั้งสองอย่าง) เพื่อสร้าง + พัฒนาโครงการด้วย
นี่คือบทความเกี่ยวกับเส้นด้ายเกี่ยวกับสาเหตุที่ต้องใช้ yarn.lock หากคุณสร้างมาตรฐานบนเส้นด้าย
หากคุณยอมรับทั้งyarn.lockไฟล์และpackage-lock.jsonไฟล์มีหลายวิธีที่ไฟล์ 2 ไฟล์สามารถจัดเตรียมแผนผังการอ้างอิงที่แตกต่างกัน (แม้ว่าอัลกอริธึมการแก้ปัญหาต้นไม้ของเส้นด้ายและ npm จะเหมือนกันก็ตาม) และไม่ใช่เรื่องเล็กน้อยเพื่อให้แน่ใจว่าไฟล์เหล่านี้ให้ข้อมูลที่ตรงกัน คำตอบเดียวกัน เนื่องจากไม่ใช่เรื่องเล็กน้อยจึงไม่น่าเป็นไปได้ที่แผนผังการพึ่งพาเดียวกันจะได้รับการดูแลในทั้งสองไฟล์และคุณไม่ต้องการพฤติกรรมที่แตกต่างกันขึ้นอยู่กับว่าการสร้างนั้นเสร็จสิ้นโดยใช้เส้นด้ายหรือ npm
ถ้าและเมื่อเส้นด้ายเปลี่ยนจากใช้yarn.lockเป็นpackage-lock.json( ปัญหาที่นี่ ) การเลือกล็อกไฟล์เพื่อคอมมิตจะกลายเป็นเรื่องง่ายและเราไม่ต้องกังวลเกี่ยวกับเส้นด้ายและ npm ที่ทำให้เกิดการสร้างที่แตกต่างกันอีกต่อไป ขึ้นอยู่กับการโพสต์บล็อกนี้คือการเปลี่ยนแปลงที่เราไม่ควรคาดหวังว่าเร็ว ๆ นี้ (โพสต์บล็อกนี้ยังอธิบายถึงความแตกต่างระหว่างและyarn.lockpackage-lock.json
ฉันกำลังคิดถึงคำถามเดียวกัน นี่คือความคิดของฉันหวังว่ามันจะช่วยได้:
เอกสารnpm package-lock.json ระบุว่า:
package-lock.json ถูกสร้างขึ้นโดยอัตโนมัติสำหรับการดำเนินการใด ๆ โดยที่ npm ปรับเปลี่ยนโครงสร้าง node_modules หรือ package.json โดยจะอธิบายถึงโครงสร้างที่ถูกสร้างขึ้นเพื่อให้การติดตั้งในภายหลังสามารถสร้างโครงสร้างที่เหมือนกันได้โดยไม่คำนึงถึงการอัปเดตการอ้างอิงระดับกลาง
วิธีนี้ดีมากเพราะป้องกันเอฟเฟกต์ "ทำงานบนเครื่องของฉัน"
โดยไม่ต้องไฟล์นี้ถ้าคุณnpm install --save A, NPM จะเพิ่มที่คุณ"A": "^1.2.3" package.jsonเมื่อคนอื่นทำงานnpm installในโครงการของคุณก็เป็นไปได้ว่ารุ่น1.2.4ของAได้รับการเผยแพร่ เนื่องจากเป็นเวอร์ชันล่าสุดที่พร้อมใช้งานซึ่งตรงตามช่วง semver ที่ระบุในของคุณpackage.jsonจึงจะติดตั้งเวอร์ชันนี้ แต่จะเกิดอะไรขึ้นถ้ามีข้อผิดพลาดใหม่ในเวอร์ชันนี้? บุคคลนี้จะมีปัญหาที่คุณไม่สามารถทำซ้ำได้เนื่องจากคุณมีเวอร์ชันก่อนหน้าโดยไม่มีจุดบกพร่องใด ๆ
ด้วยการแก้ไขสถานะของnode_modulesไดเร็กทอรีของคุณpackage-lock.jsonไฟล์จะป้องกันปัญหานี้เนื่องจากทุกคนจะมีเวอร์ชันเดียวกันของทุกแพ็คเกจ
แต่ถ้าคุณเขียนและเผยแพร่โมดูล npm ล่ะ? เอกสารระบุว่าต่อไปนี้:
รายละเอียดที่สำคัญอย่างหนึ่งเกี่ยวกับ package-lock.json คือไม่สามารถเผยแพร่ได้และจะถูกละเว้นหากพบในที่อื่นที่ไม่ใช่แพ็กเกจ toplevel
ดังนั้นแม้ว่าคุณจะยอมรับมันเมื่อผู้ใช้ติดตั้งโมดูลของคุณเขา / เธอจะไม่ได้รับpackage-lock.jsonไฟล์ แต่จะมีเพียงpackage.jsonไฟล์เท่านั้น ดังนั้น npm จะติดตั้งเวอร์ชันล่าสุดที่ตรงตามช่วง semver ของการอ้างอิงทั้งหมดของคุณ หมายความว่าคุณต้องการทดสอบโมดูลของคุณด้วยเวอร์ชันอ้างอิงเหล่านี้เสมอไม่ใช่เวอร์ชันที่คุณติดตั้งเมื่อคุณเริ่มเขียนโมดูลของคุณ ดังนั้นในกรณีpackage-lock.jsonนี้ไม่มีประโยชน์อย่างชัดเจน มากกว่านั้นอาจเป็นเรื่องน่ารำคาญ
นี่คือกฎทั่วไปของฉัน: หากคุณกำลังทำงานกับแอปพลิเคชันให้ทำการล็อกไฟล์ หากคุณกำลังดูแลไลบรารีให้เพิ่มลงในรายการที่ไม่สนใจ ไม่ว่าจะด้วยวิธีใดคุณควรใช้ช่วง semver ที่ถูกต้องในรูปแบบpackage.json. Yehuda Katz ( แคช ) เขียนคำอธิบายที่ดีสำหรับเวลาที่ควรกระทำGemfile.lock(ไฟล์ล็อกของ Ruby) และเมื่อใดที่ไม่ควรทำ อย่างน้อยอ่านส่วน tl; dr
.gitignoreและโดยทั่วไปจะอยู่ที่รูทของโปรเจ็กต์
ถูกต้อง! การอนุญาตทั้งสองอย่างnpmและyarnใช้จะทำให้เกิดปัญหา ลองดูที่บทความนี้
ขณะนี้เรากำลังวางแผนที่จะเพิ่มคำเตือนให้กับผู้ใช้ที่ใช้ทั้งสอง
yarnและnpmในที่เก็บเดียวกันเพื่อติดตั้งแพ็กเกจเราขอแนะนำให้คุณลบ
package-lock.jsonไฟล์หากคุณตัดสินใจที่จะใช้เส้นด้ายเพื่อหลีกเลี่ยงความสับสนในอนาคตและปัญหาความสอดคล้องที่อาจเกิดขึ้น
คุณอาจไม่ต้องการทั้งสองอย่างnpmและyarnในฐานะผู้จัดการแพ็คเกจของคุณ
ไฟล์เหล่านี้ได้รับการจัดการโดยเครื่องมือของคุณดังนั้นสมมติว่าการใช้เส้นด้ายจะช่วยอัปเดตได้อย่างมีประสิทธิภาพpackage-lock.json- ฉันคิดว่าการคอมมิตทั้งสองไฟล์ทำงานได้ดี
ผมคิดว่าสิ่งที่สำคัญที่สุดสำหรับผู้ใช้ของคุณpackage-lock.json(ฉันเช่นไม่ได้ใช้เส้นด้าย) เพื่อให้คนนี้มีที่จะมุ่งมั่น
สำหรับyarn.lockมันขึ้นอยู่กับว่าคุณทำงานคนเดียวหรือเป็นทีม ถ้าโซโลฉันคิดว่าไม่จำเป็นต้องกระทำ หากคุณ (วางแผนที่จะ) ทำงานเป็นทีมคุณก็ควรจะยอมรับอย่างน้อยก็จนกว่าเส้นด้ายจะรองรับมัน 🙂
ฉันคิดว่าในที่สุดทีมเส้นด้ายจะเลิกใช้yarn.lockและใช้package-json.lockแทนในเวลานี้มันจะง่ายขึ้น😛
ไม่การใช้ไฟล์ล็อกทั้งสองพร้อมกันส่วนใหญ่มักจะทำให้โครงสร้างการพึ่งพาของคุณไม่สอดคล้องกันโดยเฉพาะอย่างยิ่งเมื่อทำงานร่วมกันในทีม การละเว้นหนึ่งล็อคหรืออีกล็อคเป็นวิธีง่ายๆ ตรวจสอบให้แน่ใจว่าทีมของคุณเข้าใจและเห็นด้วยกับการเปลี่ยนแปลงนี้