ฉันควรคอมมิทไฟล์ yarn.lock และมันมีไว้เพื่ออะไร?

305

เส้นด้ายสร้างไฟล์หลังจากที่คุณทำการyarn.lockyarn install

สิ่งนี้ควรถูกกำหนดให้กับที่เก็บหรือถูกละเว้น? มีไว้เพื่ออะไร?

yarnpkg

3

IMHO คำถามนี้ (และคำตอบส่วนใหญ่ด้านล่าง) ไม่สมบูรณ์เนื่องจากไม่มีคำถามว่า "เราควรสร้างไฟล์ yarn.lock ใหม่ได้อย่างไรและเมื่อไหร่"

— MarkHu

1

คุณรู้ตอนนี้อย่างไรและเมื่อไหร่?

— jayarjo

@ MarkHu พบได้ที่นี่: yarnpkg.com/lang/en/docs/yarn-lock/#toc-managed-by-yarnดังนั้นโดยทั่วไป:

Your yarn.lock file is auto-generated and should be handled entirely by Yarn. As you add/upgrade/remove dependencies with the Yarn CLI, it will automatically update your yarn.lock file.

— jayarjo

เกี่ยวข้อง: stackoverflow.com/questions/45614973/…

— k0pernikus

271

ใช่คุณควรตรวจสอบดูการย้ายจาก npm

Yarn จะสร้างไฟล์ yarn.lock ภายในไดเรกทอรีรากของแพ็คเกจของคุณ คุณไม่จำเป็นต้องอ่านหรือเข้าใจไฟล์นี้ - เพียงแค่ตรวจสอบมันลงในการควบคุมแหล่งที่มา

— ckuijjer
แหล่งที่มา

33

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

— rlay3

13

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

— rlay3

แทนที่จะพูดว่า "ไม่พบไฟล์ล็อค" มันควรจะพูดว่า "การสร้างไฟล์ yarn.lock" Duh :) มันไม่ใช่ข้อผิดพลาด แต่ก่อนหน้านี้ฟังดูเหมือนผิดพลาด และอันหลังจะน่าตกใจพอสำหรับทุกคนในสถานการณ์ผกผัน (ที่พวกเขาคาดหวังว่าจะมีไฟล์ yarn.lock แต่เห็นได้ชัดว่าไม่มี)

— Alexander Mills

7

ฉันขอขอบคุณ yarn.lock กำลังล็อคโครงการของเราไปยังแพ็คเกจรุ่นที่ระบุ แต่ฉันรู้สึกว่าการใช้คำว่า "ล็อค" นั้นเป็นเรื่องที่โชคร้าย โดยทั่วไปแล้วการล็อกไฟล์ (เช่น. ldb ) เป็นวิธีการ จำกัด ทรัพยากรให้กับหนึ่งกระบวนการในแต่ละครั้งเพื่อป้องกันไม่ให้เกิดการอัปเดตที่ทำให้เกิดความเสียหาย ไฟล์ล็อคดังกล่าวไม่ควรมุ่งมั่นที่จะควบคุมเวอร์ชันซึ่งเป็นที่ที่ความสับสนส่วนใหญ่เกี่ยวกับ yarn.lock เกิดขึ้น

— Antony

2

ฉันไม่ชอบวลี "คุณไม่จำเป็นต้องอ่านหรือเข้าใจไฟล์นี้" ไฟล์นี้เป็นไฟล์สำคัญในการดูแลโครงการของคุณ

— Nathan Goings

83

ขึ้นอยู่กับว่าโครงการของคุณคืออะไร:

โครงการของคุณเป็นแอปพลิเคชันหรือไม่ จากนั้น: ใช่
โครงการของคุณเป็นห้องสมุดหรือไม่? ถ้าเป็นเช่นนั้น: ไม่

รายละเอียดเพิ่มเติมเกี่ยวกับสิ่งนี้สามารถพบได้ในGitHub ฉบับนี้ซึ่งหนึ่งในผู้สร้างเส้นด้ายเช่น พูดว่า:

package.json อธิบายถึงเวอร์ชันที่ผู้แต่งดั้งเดิมต้องการในขณะที่ yarn.lock อธิบายถึงการกำหนดค่าที่รู้จักกันดีล่าสุดสำหรับแอปพลิเคชันที่ระบุ

จะใช้เฉพาะyarn.lockไฟล์ - ของโครงการระดับบนสุด ดังนั้นหากโครงการใดจะใช้เป็นแบบสแตนด์อโลนและไม่ได้ติดตั้งในโครงการอื่นดังนั้นจึงไม่มีประโยชน์ในการคอมyarn.lockไพล์ไฟล์ใด ๆ- แต่จะขึ้นอยู่กับpackage.json-file เสมอเพื่อถ่ายทอดเวอร์ชันการอ้างอิงที่โครงการคาดหวังไว้

— VoxPelli
แหล่งที่มา

7

ในทางกลับกันการไม่มีไฟล์ล็อคในโครงการห้องสมุดจะส่งผลต่อความสามารถในการทำซ้ำของการทดสอบตามลำดับหรือไม่

— E_net4 ผู้มีสิทธิเลือกตั้งอย่างใกล้ชิด

1

ถ้าฉันอ่านคำอธิบายของคุณถูกต้องกว่า "โครงการของคุณเป็นห้องสมุดหรือไม่" สามารถตอบด้วย "ถ้าคุณต้องการ" ดูเหมือนจะไม่ได้มีข้อเสีย แต่อาจมีประโยชน์หากคุณมี devDependencies ที่ซับซ้อนและคุณต้องการให้นักพัฒนาซอฟต์แวร์ lib ทุกคนมีสคริปต์การสร้างและทดสอบเดียวกัน ขวา?

— Pipo

4

เนื่องจากไฟล์ล็อคจะไม่ได้รับการเคารพสำหรับผู้ใช้ห้องสมุดของคุณจากนั้นให้ใช้ไฟล์ดังกล่าวเมื่อพัฒนาห้องสมุดอาจให้ความปลอดภัยที่ผิดพลาด

— VoxPelli

1

Dart มีระบบเดียวกันกับ pubspec.yaml และ pubspec.lock และแนะนำเช่นเดียวกับในคำตอบ ดูนี้คำถามนี้รายการเอกสาร

— Jonas Kello

16

โปรดดูรายการนี้ในบล็อกอย่างเป็นทางการของ Yarn: ควรล็อคไฟล์ในทุกโครงการ

— E_net4 ผู้มีสิทธิเลือกตั้งอย่างใกล้ชิด

66

ฉันเห็นคำถามสองข้อนี้แยกกันในข้อเดียว ให้ฉันตอบทั้งคู่

คุณควรคอมมิทไฟล์เป็น repo หรือไม่?

ใช่. ดังที่ได้กล่าวไว้ในคำตอบของ ckuijjerขอแนะนำในMigration Guideเพื่อรวมไฟล์นี้ไว้ใน repo อ่านเพื่อทำความเข้าใจว่าทำไมคุณต้องทำ

คือyarn.lockอะไร

เป็นไฟล์ที่เก็บเวอร์ชันอ้างอิงที่แน่นอนสำหรับโครงการของคุณพร้อมกับ checksums สำหรับแต่ละแพ็คเกจ นี่เป็นวิธีเส้นด้ายที่จะให้ความสอดคล้องสำหรับการอ้างอิงของคุณ

จะเข้าใจว่าทำไมไฟล์นี้เป็นสิ่งจำเป็นที่คุณต้องเข้าใจสิ่งที่เป็นปัญหาที่อยู่เบื้องหลังเดิม package.jsonNPM เมื่อคุณติดตั้งแพคเกจ NPM จะเก็บช่วงของการแก้ไขที่อนุญาตของการอ้างอิงแทนการแก้ไขเฉพาะ (semver) NPM จะพยายามดึงข้อมูลการอ้างอิงรุ่นล่าสุดของการพึ่งพาภายในช่วงที่ระบุ (เช่นการอัปเดตแพตช์ไม่ทำลาย) มีสองปัญหาเกี่ยวกับวิธีการนี้

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

เส้นด้ายในอีกทางหนึ่งใช้เส้นทางของการคาดการณ์ได้สูงสุด มันสร้างyarn.lockไฟล์เพื่อบันทึกเวอร์ชันการพึ่งพาที่แน่นอน มีแฟ้มที่ในเส้นด้ายที่จะใช้รุ่นที่เก็บไว้ในแทนการแก้ไขปัญหาจากรุ่นyarn.lock package.jsonกลยุทธ์นี้รับประกันว่าไม่มีปัญหาที่อธิบายไว้ข้างต้นเกิดขึ้น

yarn.lockคล้ายกับnpm-shrinkwrap.jsonที่สามารถสร้างโดยnpm shrinkwrapคำสั่ง ตรวจสอบคำตอบนี้เพื่ออธิบายความแตกต่างระหว่างสองไฟล์นี้

— Juriy
แหล่งที่มา

1

แต่ฉันเห็นyarn.lockการอัปเดตตอนนี้แล้วคุณรู้หรือไม่ว่าทำไมและเมื่อyarnใด

— jayarjo

1

ปัญหาเกี่ยวกับ Yarn # 4379และ# 4147แนะนำให้yarnอัปเดตyarn.lockในหลาย ๆ กรณีรวมถึงการรันyarn installโดยไม่มีการเปลี่ยนแปลง package.json การใช้yarn install --frozen-lockfileตามที่แนะนำในเหตุใดการเรียกใช้งานเส้นด้ายบน windows จึงเปลี่ยน yarn.lock (หรือกำหนดค่าผ่านทาง.yarnrc) ดูเหมือนว่าจะเป็นวิธีที่ดีที่สุด

— Lauri Harpf

NPM ปัจจุบันมีและpackage-lock.json npm ciขั้นตอนการทำงานที่เป็นเส้นด้ายคล้ายของและyarn.lock yarn install --frozen-lockfile

— k0pernikus

10

ฉันเดาใช่เพราะ Yarn เวอร์ชั่นของไฟล์ yarn.lock ของตัวเอง: https://github.com/yarnpkg/yarn

มันใช้สำหรับการแก้ปัญหาการพึ่งพาแพคเกจกำหนด

— jarekwg
แหล่งที่มา

8

คุณควร:

เพิ่มลงในพื้นที่เก็บข้อมูลและยอมรับมัน
ใช้yarn install --frozen-lockfileและไม่yarn installเป็นค่าเริ่มต้นทั้งในประเทศและบนเซิร์ฟเวอร์สร้าง CI

(ฉันเปิดตั๋วบนตัวติดตามปัญหาของ yarn เพื่อสร้างเคสเพื่อให้มีการทำงานที่เป็นค่าเริ่มต้น Frozen-lockfile ดู# 4147 )

ระวังอย่าตั้งค่าfrozen-lockfileสถานะใน.yarnrcไฟล์ตามที่จะป้องกันไม่ให้คุณสามารถซิงค์ไฟล์ package.json และ yarn.lock ดูที่เกี่ยวข้องปัญหาเส้นด้ายกับ GitHub

yarn install อาจกลายพันธุ์เส้นด้ายของคุณล็อคโดยไม่คาดคิดทำให้การเรียกร้องเส้นด้ายของการทำซ้ำสร้างโมฆะและเป็นโมฆะ คุณควรใช้yarn installเพื่อเริ่มต้นเส้นด้ายล็อคและเพื่อปรับปรุง

นอกจากนี้ esp. ในทีมขนาดใหญ่คุณอาจมีเสียงรบกวนมากมายเกี่ยวกับการเปลี่ยนแปลงในการล็อคเส้นด้ายเท่านั้นเนื่องจากนักพัฒนาตั้งค่าโครงการในพื้นที่ของตน

สำหรับข้อมูลเพิ่มเติมอ่านคำตอบของฉันเกี่ยวกับ package-lock.json ของ npmตามที่ใช้ที่นี่เช่นกัน

สิ่งนี้ได้ทำให้ชัดเจนในเอกสารสำหรับการติดตั้งเส้นด้าย :

yarn install

ติดตั้งการพึ่งพาทั้งหมดที่แสดงรายการอยู่ใน package.json ในโฟลเดอร์ node_modules โลคัล

yarn.lockไฟล์ถูกนำมาใช้เป็นดังนี้:

ถ้า yarn.lock มีอยู่และเพียงพอที่จะตอบสนองต่อการอ้างอิงทั้งหมดที่ระบุไว้ใน package.json เวอร์ชันที่แน่นอนที่บันทึกไว้ใน yarn.lock จะถูกติดตั้งและ yarn.lock จะไม่เปลี่ยนแปลง Yarn จะไม่ตรวจสอบเวอร์ชั่นที่ใหม่กว่า

ถ้า yarn.lock ขาดหายไปหรือไม่เพียงพอที่จะตอบสนองการอ้างอิงทั้งหมดที่ระบุไว้ใน package.json (ตัวอย่างเช่นถ้าคุณเพิ่มการพึ่งพา package.json ด้วยตนเอง) Yarn จะค้นหาเวอร์ชั่นใหม่ล่าสุดที่มีอยู่ซึ่งตรงตามข้อ จำกัด ในแพ็คเกจ .json ผลลัพธ์จะถูกเขียนไปยัง yarn.lock

หากคุณต้องการให้แน่ใจว่าไม่มีการอัพเดต yarn.lock ให้ใช้ --frozen-lockfile.

— k0pernikus
แหล่งที่มา

ในขณะที่เป็นจริงเพียงครั้งเดียวที่ฉันสามารถคิดว่าคุณจะต้องใช้--frozen-lockfileคือถ้ามีคนปรับปรุง package.json ด้วยตนเองโดยไม่ต้องเรียกใช้ในภายหลังyarn installและกระทำการปรับปรุง ดังนั้น CI อาจต้องการใช้การตั้งค่าสถานะนั้น แต่นักพัฒนาไม่ควรเพราะมันซ่อนปัญหา

— jkrehm

@jkrehm ขึ้นอยู่กับสิ่งที่คุณหมายถึงโดยการซ่อนปัญหา ฉันมีปัญหาเพิ่มเติมเกี่ยวกับyarn.lockไฟล์ที่เปลี่ยนแปลงโดยไม่คาดหมายyarn installทั้งจากการ bloating คำขอ pull หรือทำให้เกิดความขัดแย้งในการรวมที่ไม่จำเป็นหรือโดยการดึงไลบรารี่ (เนื่องจากห้องสมุดใช้เซมาร์ไม่ได้หมายความว่าการอัปเดตแพตช์ / เล็กน้อยจะไม่ทำให้แอปของคุณพัง - ฉันไปที่นั่นแล้ว) ฉันพิจารณาการอัปเดตyarn.lockควรเป็นขั้นตอนแบบแมนนวลเท่านั้นซึ่งเป็นเหตุผลที่ฉันวางใจyarn install --frozen-lockfile(และnpm ciในโปรเจ็กต์ npm) แม้กระทั่งบนเครื่อง dev ของฉันเพราะมันเชื่อถือได้และไม่แน่นอน

— k0pernikus

1

ฉันไม่เคยมีปัญหากับyarn.lockการอัปเดตโดยไม่คาดคิด (ใช้มาตั้งแต่ตุลาคม 2016 เมื่อมันออกมา) ผู้ใช้มักจะทำบางสิ่งด้วยตนเองหรือสคริปต์หลังการติดตั้งที่มีหมัด เป็นเหตุผลที่ฉันชอบ Yarn over NPM (NPM อัปเดตทุกอย่างทุกเวลาตามที่ต้องการ) ฉันเดาว่าฉันจะถือว่าตัวเองโชคดีที่ไม่ได้พบปัญหาเหล่านั้น

— jkrehm

5

จากประสบการณ์ของฉันฉันจะบอกว่าใช่เราควรยอมรับyarn.lockไฟล์ จะช่วยให้มั่นใจได้ว่าเมื่อคนอื่นใช้โครงการของคุณพวกเขาจะได้รับการอ้างอิงเช่นเดียวกับโครงการของคุณ

จากหมอ

เมื่อคุณเรียกใช้เส้นด้ายหรือเส้นด้ายเพิ่มเส้นด้ายจะสร้างไฟล์ yarn.lock ภายในไดเรกทอรีรากของแพ็คเกจของคุณ คุณไม่จำเป็นต้องอ่านหรือเข้าใจไฟล์นี้ - เพียงแค่ตรวจสอบมันลงในการควบคุมแหล่งที่มา เมื่อคนอื่นเริ่มใช้ Yarn แทนที่จะเป็น npm ไฟล์ yarn.lock จะช่วยให้มั่นใจได้ว่าพวกเขาได้รับการอ้างอิงเช่นเดียวกับที่คุณมี

หนึ่งอาจจะเถียงว่าเราจะประสบความสำเร็จโดยการแทนที่ด้วย^ --ใช่เราทำได้ แต่โดยทั่วไปแล้วเราได้เห็นว่าnpmแพ็คเกจส่วนใหญ่มาพร้อมกับ^สัญกรณ์และเราต้องเปลี่ยนสัญกรณ์ด้วยตนเองเพื่อให้มั่นใจถึงการพึ่งพาแบบคงที่ แต่ถ้าคุณใช้yarn.lockมันจะมั่นใจได้ว่าเวอร์ชั่นที่ถูกต้องของคุณโดยทางโปรแกรม

อีริคเอลเลียตก็พูดเช่นกันที่นี่

อย่า. เส้นด้ายลายเซ็น. ล็อค มันมีเพื่อให้แน่ใจว่าการแก้ปัญหาการพึ่งพาที่กำหนดเพื่อหลีกเลี่ยงข้อผิดพลาด "ทำงานกับเครื่องของฉัน"

— Anshul
แหล่งที่มา

3

ใช่คุณควรจะยอมรับมัน สำหรับข้อมูลเพิ่มเติมเกี่ยวกับไฟล์ yarn.lock อ้างอิงเอกสารทางการที่นี่

— นาวินพระประแดง
แหล่งที่มา

3

ใช่ yarn.lockจะต้องมีการตรวจสอบเพื่อให้นักพัฒนาที่ติดตั้งการอ้างอิงได้รับผลลัพธ์เดียวกันแน่นอน! ตัวอย่างเช่นด้วย npm [ที่มีให้บริการในเดือนตุลาคม 2016]คุณสามารถpatchติดตั้งเวอร์ชัน (เช่น 1.2.0) ในเครื่องในขณะที่นักพัฒนาใหม่ที่ใช้งานเฟรชinstallอาจได้เวอร์ชั่นที่ต่างออกไป (1.2.1)

— enapupe
แหล่งที่มา

1

พฤติกรรม npm ที่คุณกล่าวถึงขึ้นอยู่กับว่าคุณจะบันทึกการพึ่งพาได้อย่างไร หากคุณประหยัดด้วย--save-exactเมื่อใช้ npm คุณสามารถบรรลุพฤติกรรมเดียวกัน

— AlicanC

4

@ AricanC ฉันไม่คิดว่ามันง่ายขนาดนั้น ผมเชื่อว่าเส้นด้าย (ผ่านแฟ้มล็อคความมุ่งมั่น) จะรับประกันรุ่นเดียวกันของแพคเกจและการอ้างอิงทั้งหมดของพวกเขาได้เป็นอย่างดี นี่เป็นสิ่งที่ NPM มักจะมีปัญหาอยู่เสมอเนื่องจากการพึ่งพาของการพึ่งพาอาจไม่ถูกตรึงอยู่กับเวอร์ชันที่เฉพาะเจาะจงดังนั้นการติดตั้งใหม่อาจดึงการพึ่งพาระดับล่างที่แตกต่างกัน NPM shrinkwrap ควรจะแก้ปัญหานี้ในระดับหนึ่ง แต่มันก็ยุ่งยากและมักจะทำงานไม่ถูกต้อง

— nextgentech

@nextgentech หากในกรณีนั้นฉันจะแน่ใจได้อย่างไรว่าการอ้างอิงของการพึ่งพานั้นได้รับการปรับปรุงอย่างถูกต้อง สมมติว่าฉันมีแพ็คเกจหลักซึ่งมีแพ็คเกจที่ขึ้นอยู่กับ (พูด 3) ฉันจะคอยดูการเปลี่ยนแปลงในแพ็คเกจหลักของฉันและอัพเดตมันใน package.json แต่หากแพ็คเกจย่อยใดใน 3 แพ็คเกจได้รับการอัปเดตโดยพวกเขาฉันจะได้รับการเปลี่ยนแปลงอย่างไร เพราะไฟล์ล็อคการอ้างอิงเหล่านั้นจะไม่ได้รับการปรับปรุงใช่มั้ย

— Pragatheeswaran

ฉันยังไม่ได้ยุ่งกับมันมาก แต่ฉันเชื่อว่าเป็นที่ที่yarn upgradeคำสั่งเข้ามาเล่น คำสั่งนี้จะอัพเกรดแพ็คเกจทั้งหมดและสร้างไฟล์ล็อค ตัวอย่างเช่นหากคุณกำลังปรับใช้แอพกับการผลิตและจำเป็นต้องติดตั้งการพึ่งพามันจะทำตามไฟล์ล็อคที่ดึงลงมาจากพื้นที่เก็บข้อมูล คุณไม่ควรเรียกใช้yarn upgradeเว้นแต่คุณต้องการเปลี่ยนข้อมูลการอ้างอิงอย่างชัดเจน (และส่งไฟล์ล็อกใหม่)

— nextgentech

yarn installจะไม่รับประกันเวอร์ชันเดียวกัน เท่านั้นyarn install --frozen-lockfileไม่

— k0pernikus