composer.lock ควรมุ่งมั่นที่จะควบคุมเวอร์ชันหรือไม่?


529

ฉันสับสนเล็กน้อยที่composer.lockใช้ในแอปพลิเคชันที่มีที่เก็บ

ฉันเห็นหลายคนบอกว่าเราไม่ควร.gitignore composer.lockออกจากที่เก็บ

หากฉันอัปเดตห้องสมุดของฉันในสภาพแวดล้อมการพัฒนาของฉันฉันจะมีใหม่composer.lockแต่ฉันจะไม่สามารถอัปเดตไลบรารีเหล่านั้นเป็นการผลิตได้หรือไม่

มันจะไม่สร้างความขัดแย้งในไฟล์นี้หรือไม่?


1
ลิงค์นั้นตอนนี้ตาย @markus
Kyrre

คำตอบ:


673

หากคุณอัพเดต libs ของคุณคุณต้องการคอมไฟล์ lock เช่นกัน โดยพื้นฐานแล้วระบุว่าโครงการของคุณถูกล็อคไปยัง libs ที่คุณใช้อยู่

หากคุณยอมรับการเปลี่ยนแปลงของคุณและมีคนดึงรหัสของคุณและอัปเดตการอ้างอิง lockfile ควรไม่ได้รับการแก้ไข หากมีการแก้ไขก็หมายความว่าคุณมีบางสิ่งบางอย่างรุ่นใหม่

การมีไว้ในที่เก็บทำให้คุณมั่นใจได้ว่านักพัฒนาซอฟต์แวร์แต่ละคนใช้เวอร์ชันเดียวกัน


5
ตกลง แต่ลองคิดดูถ้าฉันอัปเดตไลบรารีจากสภาพแวดล้อมการผลิต composer.lock จะถูกเขียนทับดังนั้นการดึงครั้งต่อไปจากการผลิตจะขอให้ฉันรวมไฟล์นี้ ...
Pierre de LESPINAY

7
หาก composer.lock ได้รับการแก้ไขคุณจะต้องผลักดันการปรับเปลี่ยนกลับไปที่ที่เก็บ หากคุณต้องการผูกซอฟต์แวร์กับไลบรารีเวอร์ชันที่ระบุให้ทำเช่นนั้นอย่างชัดเจนในการกำหนดค่า วิธีนี้ล็อคจะไม่เปลี่ยนแปลง คิดว่าไฟล์ล็อคเป็นตัวบ่งชี้ปัญหาการจัดการการพึ่งพาซึ่งจำเป็นต้องได้รับการแก้ไขในทางใดทางหนึ่ง
meza

361
ในการผลิตคุณไม่ควรอัปเดตการอ้างอิงของคุณคุณควรเรียกใช้composer installซึ่งจะอ่านจากไฟล์ล็อคและไม่เปลี่ยนแปลงอะไร
Seldaek

112
"ในการผลิตคุณไม่ควรอัปเดตการอ้างอิงของคุณ" ควรเขียนในตัวพิมพ์ใหญ่ทั้งหมด
Joaquín L. Robles

75
@ JoaquínL.Roblesในการผลิตคุณไม่ควรปรับปรุงเงินฝากของคุณ! :)
ЙлинЙ

201

สำหรับแอปพลิเคชัน / โครงการ : ใช่แน่นอน

เอกสารแต่งเพลงกล่าวเกี่ยวกับเรื่องนี้ (ที่มีความสำคัญ):

คอมมิชชันของแอพพลิเคชั่นของคุณ (พร้อมกับ composer.json) ในการควบคุมเวอร์ชัน

Like @meza กล่าวว่า: คุณควรคอมมิตไฟล์ล็อคเพื่อให้คุณและผู้ทำงานร่วมกันทำงานในเวอร์ชันเดียวกันและป้องกันไม่ให้คุณพูดเช่น "แต่มันทำงานบนคอมพิวเตอร์ของฉัน" ;-)

สำหรับห้องสมุด : อาจจะไม่

เอกสารประกอบของผู้แต่งเกี่ยวกับเรื่องนี้:

หมายเหตุ: สำหรับไลบรารีไม่แนะนำให้คอมมิตไฟล์ล็อก (... )

และรัฐที่นี่ :

สำหรับไลบรารีของคุณคุณอาจส่งไฟล์ composer.lock ถ้าคุณต้องการ สิ่งนี้จะช่วยให้ทีมของคุณทดสอบกับเวอร์ชันการพึ่งพาที่เหมือนกันเสมอ อย่างไรก็ตามไฟล์ล็อคนี้จะไม่มีผลกับโครงการอื่น ๆ ที่ขึ้นอยู่กับมัน มันมีผลต่อโครงการหลักเท่านั้น

สำหรับห้องสมุดฉันเห็นด้วยกับคำตอบของ @Josh Johnson


ทำไมต้องดูแลโครงการในที่ทำงานแตกต่างจาก "ห้องสมุด"
Josh Johnson

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

2
การยอมรับการล็อกไฟล์ด้วยไลบรารีน่าจะเป็นสิ่งที่ดี - เอกสารไฟล์ล็อคที่เวอร์ชันของการพึ่งพาถูกติดตั้งเมื่อรันชุดการทดสอบ นั่นเป็นสิ่งสำคัญอย่างยิ่งในทีมและโดยเฉพาะอย่างยิ่งในสภาพแวดล้อมการรวมอย่างต่อเนื่อง
mindplay.dk

ความขัดแย้งที่ไม่สำคัญสามารถเกิดขึ้นได้เมื่อรวมอยู่ในลำต้น 2 สาขาซึ่งทั้งคู่มีแพ็คเกจใหม่ที่ติดตั้งผ่านผู้แต่ง เกิดขึ้นตอนนี้ :)
g4b0

2
@tonix ฉันสามารถตอบคำถามนี้ด้วยสิทธิ์บางอย่าง! เหตุผลที่ฉันไม่ผูกมัดผู้แต่งให้ล็อคห้องสมุดของฉันก็คือ CI ของฉันสร้างต้นแบบทุกคืนไม่ว่าจะเกิดอะไรขึ้น มันรับประกันว่าหากการอ้างอิงใด ๆ ของไลบรารีมีปัญหาในการอัพเกรดผู้ใช้ไลบรารีจะมี CI นั้นล้มเหลว ใช้งานได้ดี!
Theodore R. Smith

86

หลังจากทำทั้งสองวิธีสำหรับโปรเจกต์บางอย่างท่าทางของฉันคือว่าcomposer.lockไม่ควรมีส่วนร่วมในโครงการ

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

หากคุณกังวลเกี่ยวกับการพึ่งพาการเปลี่ยนแปลงระหว่างการอัปเดตผู้แต่งคุณจะไม่มีความมั่นใจในการกำหนดเวอร์ชันของคุณ เวอร์ชัน (1.0, 1.1, 1.2 และอื่น ๆ ) ควรไม่เปลี่ยนรูปแบบและคุณควรหลีกเลี่ยงสัญลักษณ์เสริม "dev-" และ "X. *" นอกเหนือจากการพัฒนาคุณสมบัติเริ่มต้น

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

นอกจากนี้โครงการของคุณไม่ควรจะถูกสร้างขึ้นมาใหม่หรือมีการอ้างอิงใหม่ในแต่ละสภาพแวดล้อมโดยเฉพาะอย่างยิ่งผลิตภัณฑ์ การส่งมอบ (tar, zip, phar, ไดเร็กตอรี่และอื่น ๆ ) ของคุณควรจะไม่เปลี่ยนรูปและเลื่อนขั้นผ่านสภาพแวดล้อมโดยไม่เปลี่ยนแปลง


19
ตกลง ฉันรู้สึกว่าเหมาะสมกว่าที่จะระบุรุ่นที่ต้องพึ่งพาcomposer.jsonที่ซึ่งรุ่นที่ต้องการนั้นมีการระบุไว้อย่างชัดเจนยิ่งขึ้น แต่ถ้าคุณไม่ได้composer.lockตั้งเฉพาะรุ่นดีกว่าที่จะกระทำ มันทำให้เกิดความสับสนถ้ารุ่นที่ระบุไว้ในมีความแตกต่างกว่าที่ติดตั้งเป็นต่อcomposer.json composer.lockนอกจากนี้ยังขึ้นอยู่กับแอพ (ภายในองค์กรหรือรุ่นทั่วไป) และวัฏจักรการพัฒนา แน่นอนว่านักแต่งเพลง docs พูดด้วยตัวหนาว่า"คอมมิทแอพพลิเคชั่นของคุณให้คอมมิชชันของคุณ เลือกอย่างชาญฉลาด =)
Quinn Comendant

10
หลังจากค้นหาวิญญาณมากฉันได้ตัดสินใจแล้ว ณ จุดนี้ผู้แต่งเอกสารผิด :) ฉันมีกฎที่ฉันไม่เพิ่มเนื้อหาที่สร้างขึ้นใน VCS; ฉันอนุญาตให้กระบวนการสร้างจัดการได้
Josh Johnson

10
ไม่ใช่รหัสที่สร้างขึ้นโดยใช้เครื่องมือกดปุ่มทางชีวกลศาสตร์ของคุณ "วัสดุที่สร้างขึ้น" หรือไม่? ฉันไม่แน่ใจว่าเป็นเกณฑ์ที่แข็งแกร่งในการกำหนดนโยบาย =)
Quinn Comendant

5
@borfast ฉันรู้ว่าฉันเล็ก ๆ น้อย ๆ ในช่วงปลายการสนทนาเพื่อให้คุณอาจจะได้เห็นนี้โดยจุดนี้ composer.jsonแต่คุณสามารถระบุกัญชาในส่วน ในส่วนที่คุณสามารถใส่:require "repo": "dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e"นี่จะเป็น 1) ไปที่สาขา 2) ชำระเงินที่แฮช 3) หากไม่พบแฮชในสาขาอย่างไรก็ตามมันจะเช็คเอาท์หัวหน้าสาขาที่ระบุ (ต้นแบบในกรณีนี้)
CEPA

5
@CEPA - มันแปลก ฉันคาดว่าจะล้มเหลวหากไม่พบแฮช ดูเหมือนว่าอันตราย
นาธาน JB

31
  1. คุณไม่ควรอัปเดตการอ้างอิงโดยตรงกับฝ่ายผลิต
  2. คุณควรควบคุมไฟล์composer.lockของคุณ
  3. คุณไม่ควรควบคุมเวอร์ชันการพึ่งพาที่แท้จริงของคุณ

1. คุณไม่ควรอัปเดตการอ้างอิงโดยตรงกับฝ่ายผลิตเนื่องจากคุณไม่รู้ว่าสิ่งนี้จะส่งผลต่อเสถียรภาพของรหัสของคุณอย่างไร อาจมีข้อผิดพลาดในการอ้างอิงใหม่มันอาจเปลี่ยนวิธีการทำงานของรหัสที่มีผลต่อตัวคุณเองมันอาจเข้ากันไม่ได้กับการพึ่งพาอื่น ๆ ฯลฯ คุณควรทำสิ่งนี้ในสภาพแวดล้อมของ dev ตามด้วย QA และการทดสอบการถดถอยที่เหมาะสม ฯลฯ .

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

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

ซึ่งหมายความว่าแม้เมื่อคุณระบุว่าคุณต้องการ Laravel 4.1.31 ในcomposer.jsonของคุณLaravel ในไฟล์composer.jsonอาจมีการขึ้นต่อกันของตัวเองที่จำเป็นสำหรับ Symfony event-dispatcher: 2. * ด้วยการกำหนดค่าแบบนี้คุณสามารถจบด้วย Laravel 4.1.31 กับ Symfony event-dispatcher 2.4.1 และคนอื่นในทีมของคุณอาจมี Laravel 4.1.31 กับ event-dispatcher 2.6.5 มันขึ้นอยู่กับว่าเมื่อใด เป็นครั้งสุดท้ายที่คุณเรียกใช้ตัวติดตั้งผู้แต่ง

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

ถ้าคุณต้องการอัพเดท จากนั้นในสภาพแวดล้อม dev ของคุณ: composer updateสิ่งนี้จะสร้างไฟล์composer.lockใหม่(หากมีสิ่งใหม่) และหลังจากที่คุณทดสอบแล้วและการทดสอบ QA และการถดถอยทดสอบและสิ่งต่างๆ คุณสามารถผลักดันให้ทุกคนดาวน์โหลดตัวแต่งใหม่ล็อคได้เนื่องจากมันปลอดภัยที่จะอัพเกรด

3. คุณไม่ควรควบคุมเวอร์ชันการพึ่งพาที่แท้จริงของคุณเนื่องจากไม่เหมาะสม ด้วยcomposer.lockคุณสามารถติดตั้งรุ่นที่แน่นอนของการอ้างอิงและคุณไม่จำเป็นต้องยอมรับพวกเขา ทำไมคุณถึงเพิ่มไฟล์ repo 10000 ของการพึ่งพาเมื่อคุณไม่ควรอัพเดท หากคุณต้องการเปลี่ยนแปลงสิ่งนี้คุณควรแยกและทำการเปลี่ยนแปลงที่นั่น และถ้าคุณกังวลเกี่ยวกับการดึงเอาการอ้างอิงจริงออกมาในแต่ละครั้งที่มีการสร้างหรือรีลีสผู้แต่งมีวิธีที่แตกต่างกันในการบรรเทาปัญหานี้แคชไฟล์ซิป ฯลฯ


1
ขอบคุณฉันคิดว่าคำตอบนี้จะอธิบายว่าทำไมคุณควรจะเป็นนักแต่งเพลงรุ่นและถ้าไม่ได้ผลที่ตามมาคืออะไรและถ้าคุณสามารถอยู่กับพวกเขา
José Lozano Hernandez

8

จากนั้นcomposer.jsonให้คอมมิชชันต่อโครงการของคุณและคนอื่น ๆ ในทีมของคุณสามารถเรียกใช้ตัวติดตั้งผู้แต่งเพื่อติดตั้งการอ้างอิงโครงการของคุณ

จุดประสงค์ของไฟล์ล็อคคือการบันทึกเวอร์ชันที่แน่นอนที่ติดตั้งเพื่อให้สามารถติดตั้งใหม่ได้ ซึ่งหมายความว่าหากคุณมีข้อมูลจำเพาะของรุ่น 1 * และเพื่อนร่วมงานของคุณเรียกใช้การอัปเดตผู้แต่งที่ติดตั้ง 1.2.4 แล้วคอมมิตไฟล์ composer.lock เมื่อคุณติดตั้งผู้แต่งคุณจะได้รับ 1.2.4 แม้ ถ้า 1.3.0 ได้รับการเผยแพร่ สิ่งนี้ทำให้มั่นใจว่าทุกคนที่ทำงานในโครงการมีเวอร์ชันที่แน่นอนเหมือนกันทุกประการ

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

นี่เป็นปัญหาหากคุณกังวลเกี่ยวกับการทำลายรหัสของคุณ และนี่เป็นหนึ่งในเหตุผลที่สำคัญที่ต้องคำนึงถึงนักแต่งเพลงว่ามีศูนย์กลางอยู่ที่ไฟล์ composer.lock

ที่มา: แต่งเพลง: มันคือทั้งหมดที่เกี่ยวกับล็อคไฟล์


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

ที่มา: นักแต่งเพลง - การใช้งานพื้นฐาน


1

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

ข้อยกเว้นคือเมื่อคุณใช้แอพพลิเคชั่นเมตาห้องสมุดที่ควรมีการอัพเดทการติดตั้ง (เช่นแอพZend Framework 2 Skeleton App ) ดังนั้นเป้าหมายคือการคว้าการอ้างอิงล่าสุดในแต่ละครั้งที่คุณต้องการเริ่มพัฒนา

แหล่งที่มา: นักแต่งเพลง: มันคือทั้งหมดที่เกี่ยวกับไฟล์ล็อค

ดูเพิ่มเติมที่: การปรับปรุงผู้แต่งและการติดตั้งนักแต่งเพลงต่างกันอย่างไร?


1

ไม่มีคำตอบที่แน่นอนสำหรับเรื่องนี้

โดยทั่วไปนักแต่งเพลงไม่ควรทำในสิ่งที่ระบบการสร้างตั้งใจจะทำและคุณไม่ควรใส่นักแต่งเพลงไว้ใน VCS นักแต่งเพลงอาจย้อนกลับไปอย่างแปลก ๆ ผู้ใช้ปลายทางมากกว่าผู้สร้างไม่ควรใช้ไฟล์ล็อค โดยปกติแล้วระบบการสร้างของคุณจะเก็บสแน็ปช็อต, dirs ที่นำกลับมาใช้ใหม่ได้, แทนที่จะเป็น dir ที่ว่างเปล่าในแต่ละครั้ง ผู้ที่เช็คเอาต์ lib จากผู้แต่งอาจต้องการให้ lib นั้นใช้การล็อคเพื่อให้การอ้างอิงที่การโหลด lib ได้รับการทดสอบ

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

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

SVN สามารถทำได้ดีกว่า git เพราะมันไม่ได้บังคับให้คุณซื้อ repo ทั้งหมด (แม้ว่าฉันคิดว่ามันไม่จำเป็นต้องใช้กับ git อย่างแท้จริง แต่การสนับสนุนนั้น จำกัด และไม่ได้ใช้กันทั่วไป) Simple repos บิวด์มักจะเป็นเพียงโอเวอร์เลย์สาขาที่คุณผสาน / ส่งออกโครงสร้างบิลด์ บางคนรวมทรัพยากรภายนอกในต้นไม้ต้นกำเนิดของพวกเขาหรือแยกเพิ่มเติมภายนอกสร้างและต้นไม้ต้นกำเนิด มันมักจะทำหน้าที่สองวัตถุประสงค์สร้างแคชและสร้างซ้ำ แต่บางครั้งทำให้แยกกันอย่างน้อยบางระดับยังอนุญาตให้สร้างใหม่ / เปล่าและสร้างหลายสร้างได้อย่างง่ายดาย

มีกลยุทธ์มากมายสำหรับสิ่งนี้และไม่มีกลยุทธ์ใดที่ทำงานได้ดีกับการเก็บรายการแหล่งข้อมูลไว้เว้นแต่คุณจะเก็บรักษาแหล่งข้อมูลภายนอกไว้ในแผนผังแหล่งข้อมูลของคุณ

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

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

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

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

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

การเก็บล็อกไฟล์นั้นเป็นปัญหาสำหรับการใช้งานเพราะผู้แต่งมีความลับมากเกี่ยวกับว่าจะใช้การล็อกหรือ JSON และไม่สามารถใช้ทั้งคู่ร่วมกันได้ดี หากคุณรันการติดตั้งจะใช้ไฟล์ล็อคเท่านั้นมันจะปรากฏขึ้นดังนั้นหากคุณเพิ่มบางอย่างใน composer.json มันจะไม่ถูกติดตั้งเพราะมันไม่ได้อยู่ในล็อคของคุณ มันไม่ง่ายเลยในการดำเนินการใด ๆ และสิ่งที่พวกเขากำลังทำเกี่ยวกับไฟล์ json / lock และบางครั้งก็ดูเหมือนจะไม่สมเหตุสมผล (ช่วยบอกว่าการติดตั้งใช้ชื่อแพ็กเกจ แต่พยายามใช้มันบอกว่าไม่มี )

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

การอัปเดตนั้นใช้เวลานานเท่ากิ๊ก RAM ฉันสงสัยเช่นกันว่าถ้าคุณรับโครงการที่ไม่ได้สัมผัสเป็นระยะเวลาหนึ่งซึ่งดูจากรุ่นที่มีอยู่แล้วซึ่งจะมีเวลามากขึ้นและอาจไม่ทำอย่างมีประสิทธิภาพซึ่งเพียงแค่บีบคอ

พวกมันลับ ๆ ล่อๆมากเมื่อพูดถึงการมีคอมโพสิตลับที่คุณไม่คาดคิดว่าจะเป็นคอมโพสิต โดยค่าเริ่มต้นคำสั่งผู้แต่งลบจะปรากฏขึ้นเพื่อจับคู่กับการปรับปรุงผู้แต่งและการถอดผู้แต่ง

คำถามที่คุณต้องถามจริงๆไม่ใช่ว่าคุณควรเก็บล็อกไว้ในแผนผังต้นกำเนิดของคุณหรือไม่หรือว่าคุณควรจะเก็บมันไว้ที่ไหนสักแห่งในแบบนั้นหรือไม่ แต่คุณควรจะถามว่ามันทำอะไรจริงๆแล้วคุณสามารถตัดสินใจเองได้ เมื่อคุณต้องการยืนกรานมันและที่ไหน

ฉันจะชี้ให้เห็นว่าการมีความสามารถในการล็อคเป็นความสะดวกสบายที่ดีเมื่อคุณมีกลยุทธ์การติดตาภายนอกที่แข็งแกร่งเนื่องจากมันจะติดตามข้อมูลที่มีประโยชน์สำหรับการติดตาม (ต้นกำเนิด) และการอัปเดต แต่ถ้าคุณไม่ ถ้าอย่างนั้นก็ไม่ได้อยู่ตรงนี้ มันไม่มีประโยชน์เมื่อถูกบังคับให้ลำคอของคุณเป็นตัวเลือกที่จำเป็นในการทำให้ต้นไม้ที่มาก่อมลพิษ มันเป็นเรื่องธรรมดามากที่พบในรหัสฐานแบบดั้งเดิมที่ผู้คนได้ทำการเปลี่ยนแปลงมากมายใน composer.json ซึ่งยังไม่ได้นำไปใช้จริง ๆ และจะพังเมื่อผู้คนพยายามใช้นักแต่งเพลง ไม่มีผู้แต่งล็อคไม่มีปัญหา desync


0

ใช่แน่นอน

นั่นเป็นเพราะนักแต่งเพลงที่ติดตั้งในเครื่องจะให้ความสำคัญกับไฟล์ composer.lock มากกว่า composer.json

หากไฟล์ล็อคไม่พร้อมใช้งานใน vcs ผู้แต่งจะชี้ไปที่ไฟล์ composer.json เพื่อติดตั้งการอ้างอิงหรือรุ่นล่าสุด

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.