ฉันยอมรับไฟล์ package-lock.json ที่สร้างโดย npm 5 หรือไม่

1394

npm 5 เปิดตัวแล้ววันนี้และหนึ่งในคุณสมบัติใหม่รวมถึงการติดตั้งที่กำหนดขึ้นพร้อมกับการสร้างpackage-lock.jsonไฟล์

ไฟล์นี้ควรถูกเก็บไว้ในแหล่งควบคุมหรือไม่?

ฉันสมมติว่ามันคล้ายกับyarn.lockและcomposer.lockทั้งสองอย่างนี้ควรจะเก็บไว้ในการควบคุมแหล่งที่มา

20

คำตอบสั้น ๆ : ใช่ หนึ่งความคิดเห็น: เมื่อ package-lock.json มีการเปลี่ยนแปลงคุณสามารถกระทำเพียงการเปลี่ยนแปลงนั้นแยกต่างหากจากการเปลี่ยนแปลงแหล่งอื่น ๆ ทำให้git logง่ายต่อการจัดการกับ

— Purplejacket

14

ไฟล์ไม่สามารถช่วยสร้างการติดตั้งที่กำหนดค่าได้หากไม่มีอยู่

— Alan H.

4

ขึ้นอยู่กับโครงการ github.com/npm/npm/issues/20603

— Gajus

3

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

— jimmont

1615

ใช่package-lock.jsonมีวัตถุประสงค์เพื่อตรวจสอบในการควบคุมแหล่งที่มา หากคุณใช้ npm 5 คุณอาจเห็นสิ่งนี้ในบรรทัดคำสั่ง: created a lockfile as package-lock.json. You should commit this file.ตามnpm help package-lock.json:

package-lock.jsonถูกสร้างขึ้นโดยอัตโนมัติสำหรับการดำเนินการใด ๆ ที่ NPM ปรับเปลี่ยนทั้งต้นไม้หรือnode_modules package.jsonมันอธิบายต้นไม้ที่แน่นอนที่สร้างขึ้นเช่นที่ติดตั้งในภายหลังจะสามารถสร้างต้นไม้ที่เหมือนกันโดยไม่คำนึงถึงการปรับปรุงการพึ่งพากลาง

ไฟล์นี้มีวัตถุประสงค์เพื่อส่งไปยังที่เก็บข้อมูลต้นทางและให้บริการตามวัตถุประสงค์ต่างๆ:

อธิบายการเป็นตัวแทนของแผนภูมิการพึ่งพาเดียวว่าเพื่อนร่วมทีมการปรับใช้และการรวมอย่างต่อเนื่องรับประกันว่าจะติดตั้งการพึ่งพาเดียวกัน

จัดเตรียมสิ่งอำนวยความสะดวกสำหรับผู้ใช้เพื่อ "การเดินทางข้ามเวลา" ไปยังสถานะก่อนหน้าของnode_modulesโดยไม่ต้องคอมมิตไดเร็กทอรีเอง

เพื่ออำนวยความสะดวกในการมองเห็นการเปลี่ยนแปลงทรีผ่านการควบคุมแหล่งที่มาที่แตกต่าง

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

รายละเอียดสำคัญอย่างหนึ่งเกี่ยวกับpackage-lock.jsonว่าไม่สามารถเผยแพร่ได้และจะถูกละเว้นหากพบในที่อื่นนอกเหนือจากแพ็คเกจระดับบนสุด มันใช้รูปแบบร่วมกับ npm-shrinkwrap.json (5) ซึ่งโดยพื้นฐานแล้วเป็นไฟล์เดียวกัน แต่อนุญาตให้เผยแพร่ได้ ไม่แนะนำให้ใช้เว้นแต่จะใช้เครื่องมือ CLI หรือใช้กระบวนการเผยแพร่สำหรับการผลิตแพ็คเกจ

หากทั้งสองpackage-lock.jsonและnpm-shrinkwrap.jsonมีอยู่ในรากของแพคเกจpackage-lock.jsonจะถูกละเว้นอย่างสมบูรณ์

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

77

โครงการประเภทใดที่มีประโยชน์ในการยอมรับไฟล์ จุดรวมของ semver และ package.json คือการอ้างอิงที่เข้ากันได้ที่ปรับปรุงแล้วไม่จำเป็นต้องจดบันทึกไว้

— อยากรู้อยากเห็น dannii

45

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

— Panu Horsmalahti

34

@trusktr: Sindre Sorhus แนะนำให้ใช้ "Lockfiles สำหรับแอพ แต่ไม่ใช่สำหรับแพ็คเกจ"

— vine77

23

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

— trusktr

128

โดยส่วนตัวตอนนี้ฉันต้องหันไปใช้การเพิ่มpackage-lock.jsonของฉัน.gitignore... มันทำให้ฉันมีปัญหามากกว่าการแก้ไขพวกเขา มันมักจะขัดแย้งกันเมื่อเรารวมหรือ rebase และเมื่อการผสานส่งผลให้package-lock.jsonเกิดความเสียหายบนเซิร์ฟเวอร์ CI นั้นเป็นเพียงความเจ็บปวดที่ต้องแก้ไข

— Stefan Z Camilleri

111

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

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

19

มันยุติธรรมที่จะถกเถียงกันว่าควรตรวจสอบในแหล่งเก็บข้อมูลซอร์สโค้ดของคุณหรือไม่ แต่การเผยแพร่ไฟล์นี้ไปยัง npm นั้นไม่ได้ขึ้นอยู่กับการถกเถียงกันจริงๆ - คุณต้องรวม package-lock.json ของคุณ ถ้าคุณทำไม่ได้แพคเกจที่เผยแพร่ของคุณจะถูกเปลี่ยนแปลงการอ้างอิงของการขึ้นต่อรุ่นที่ 1 คุณจะไม่สังเกตเห็นว่านี่เป็นปัญหาจนกว่าหนึ่งในรุ่นที่ 2 + ที่ขึ้นต่อกันเหล่านั้นจะเผยแพร่การเปลี่ยนแปลงที่ไม่หยุดยั้ง ไฟล์ package-lock.json นี้สร้างขึ้นเพื่อแก้ไขปัญหาดังกล่าว

— guerillapresident

8

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

— xer0x

7

ฉันมักจะแยกการติดตั้งแพ็คเกจออกจากงานอื่น ฉันไม่จำเป็นต้องยอมรับคำมั่นสัญญาเช่น "Installed chai and mocha" เพราะฉันรู้แล้วว่ามีอะไรเปลี่ยนแปลง

— Keith

3

คำแนะนำเกี่ยวกับpackage-lock.jsonไฟล์เมื่อทำงานกับระบบ SCM ที่มีลำต้นและการแตกแขนงหรือไม่? ฉันกำลังทำการเปลี่ยนแปลงบางอย่างในสาขาที่ต้องรวมเข้ากับ trunk ... ตอนนี้ฉันต้องแก้ไขข้อขัดแย้งระหว่างpackage-lock.jsonไฟล์สองไฟล์หรือไม่? มันรู้สึกเจ็บปวด

— kmiklas

3

@guerillapresident ตามที่ฉันเข้าใจคุณถูกต้องเพียงบางส่วน การเผยแพร่ไฟล์นี้ไปยัง npm ไม่ได้ขึ้นอยู่กับการอภิปราย คุณไม่สามารถเผยแพร่ได้

— Tim Gautier

66

ใช่คุณควรจะ:

package-lock.jsonกระทำ
ใช้npm ciแทนnpm installเมื่อสร้างแอปพลิเคชันของคุณทั้งบน CI และเครื่องพัฒนาท้องถิ่นของคุณ

npm ciเวิร์กโฟลว์ต้องpackage-lock.jsonดำรงอยู่ของที่

ข้อเสียใหญ่ของnpm installคำสั่งคือพฤติกรรมที่ไม่คาดคิดที่มันอาจกลายพันธุ์ในpackage-lock.jsonขณะที่npm ciใช้เฉพาะรุ่นที่ระบุใน lockfile และสร้างข้อผิดพลาด

ถ้าpackage-lock.jsonและpackage.jsonไม่ซิงค์กัน
ถ้าpackage-lock.jsonไม่มี

ดังนั้นการเรียกใช้npm installในพื้นที่โดยเฉพาะอย่างยิ่ง ในทีมขนาดใหญ่ที่มีผู้พัฒนาหลายคนอาจนำไปสู่ความขัดแย้งมากมายภายในpackage-lock.jsonและนักพัฒนาตัดสินใจที่จะลบpackage-lock.jsonแทนทั้งหมด

ยังมีกรณีการใช้งานที่แข็งแกร่งสำหรับความสามารถในการเชื่อถือได้ว่าการพึ่งพาของโครงการแก้ไขซ้ำในวิธีที่เชื่อถือได้ในเครื่องที่แตกต่างกัน

จากสิ่งที่package-lock.jsonคุณจะได้รับนั่นคือสถานะที่รู้จักกันในการทำงาน

ในอดีตฉันมีโครงการที่ไม่มีpackage-lock.json/ npm-shrinkwrap.json/yarn.lockไฟล์ที่มีการสร้างจะล้มเหลววันหนึ่งเพราะการพึ่งพาสุ่มมีการปรับปรุงการทำลาย

ปัญหาเหล่านั้นยากที่จะแก้ไขเนื่องจากบางครั้งคุณต้องเดาว่าเวอร์ชันการทำงานสุดท้ายคืออะไร

npm install {dependency}หากคุณต้องการที่จะเพิ่มการพึ่งพาใหม่คุณยังคงทำงาน หากคุณต้องการอัพเกรดให้ใช้อย่างใดอย่างหนึ่งnpm update {dependency}หรือnpm install ${dependendency}@{version}และยอมรับการเปลี่ยนแปลงpackage-lock.jsonและการกระทำที่มีการเปลี่ยนแปลง

หากการอัปเกรดล้มเหลวคุณสามารถเปลี่ยนกลับไปใช้งานpackage-lock.jsonได้ตามปกติ

หากต้องการอ้างเอกสาร npm :

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

และเกี่ยวกับความแตกต่างระหว่างnpm civsnpm install :

โปรเจ็กต์ต้องมี package-lock.json หรือ npm-shrinkwrap.json ที่มีอยู่

หากการอ้างอิงในการล็อกแพ็กเกจไม่ตรงกับที่อยู่ใน package.json npm ciจะออกด้วยข้อผิดพลาดแทนที่จะอัพเดตการล็อกแพ็กเกจ

npm ci สามารถติดตั้งโครงการทั้งหมดได้พร้อมกัน: ไม่สามารถเพิ่มการอ้างอิงเดี่ยวได้ด้วยคำสั่งนี้

หากมีnode_modulesอยู่แล้วมันจะถูกลบโดยอัตโนมัติก่อนที่จะnpm ciเริ่มการติดตั้ง

มันจะไม่เขียนถึงpackage.jsonหรือล็อคแพกเกจใด ๆ : การติดตั้งจะถูกตรึงเป็นหลัก

หมายเหตุ: ฉันโพสต์คำตอบที่คล้ายกันที่นี่

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

10

คำตอบนี้สมควรได้รับเครดิตมากขึ้นโดยเฉพาะการใช้ npm ci การใช้สิ่งนี้ช่วยลดปัญหาส่วนใหญ่ที่ผู้คนเคยประสบกับการล็อคแพ็คเกจ

— JamesB

ฉันพบว่าใช้รุ่นที่คงที่ใน package.json (ไม่มีคาเร็ทหรือเครื่องหมายตัวหนอน) เป็นตัวเลือกที่สะอาดกว่ามาก สิ่งนี้ช่วยฉันจากwhose build would fail one day because a random dependency got a breaking updateปัญหา แม้ว่ามันจะเป็นไปได้ของการพึ่งพาของเด็กçausingปัญหาเดียวกัน

— Ashwani Agarwal

58

ใช่แนวทางปฏิบัติที่ดีที่สุดคือการเช็คอิน (ใช่, เช็คอิน)

ฉันยอมรับว่ามันจะทำให้เกิดเสียงหรือความขัดแย้งมากมายเมื่อเห็นความแตกต่าง แต่ประโยชน์คือ:

รับประกันรุ่นเดียวกันแน่นอนของทุกแพคเกจ ส่วนนี้เป็นสิ่งสำคัญที่สุดเมื่อสร้างในสภาพแวดล้อมที่แตกต่างกันในเวลาที่ต่างกัน คุณอาจใช้^1.2.3ในของคุณpackage.jsonแต่คุณจะมั่นใจได้อย่างไรในแต่ละครั้งที่npm installจะรับเวอร์ชั่นเดียวกันในเครื่อง dev ของคุณและในบิลด์เซิร์ฟเวอร์โดยเฉพาะแพ็คเกจพึ่งพาทางอ้อมเหล่านั้น ดีpackage-lock.jsonจะให้แน่ใจว่า (ด้วยความช่วยเหลือของnpm ciติดตั้งแพคเกจตามไฟล์ล็อค)
ปรับปรุงกระบวนการติดตั้ง
ช่วยด้วยคุณสมบัติการตรวจสอบใหม่npm audit fix(ฉันคิดว่าคุณสมบัติการตรวจสอบมาจาก npm เวอร์ชัน 6)

— ซิน
แหล่งที่มา

3

เท่าที่ฉันรู้ไม่เคยใช้ semver (ซึ่ง npm devs ไม่เข้าใจอยู่ดี) ควรให้ลักษณะการทำงานเช่นเดียวกับการมี lockfile อย่างน้อย 99% ของกรณี ประสบการณ์ของฉันเองคือ semper fuckups ส่วนใหญ่เกิดขึ้นกับแพคเกจหลัก (การอ้างอิงโดยตรง datepickers jQuery เส็งเคร็ง ฯลฯ ) ประสบการณ์ส่วนตัวของฉันกับ npm คือไฟล์ล็อคนั้นมีเสียงดังตลอดกาล ฉันหวังว่าภูมิปัญญานี้จะไม่เปลี่ยนแปลงกับรุ่นล่าสุด

— Svend

13

+1 npm ciสำหรับการกล่าวขวัญ ผู้คนมักพูดถึงว่าการpackage-lock.jsonอนุญาตให้ติดตั้งแพคเกจที่กำหนดได้ แต่แทบไม่เคยพูดถึงคำสั่งที่อำนวยความสะดวกในการทำงานนี้! หลายคนอาจสันนิษฐานว่าnpm installติดตั้งไม่ถูกต้องว่ามีอะไรอยู่ในไฟล์ล็อค ...

— ahaurat

npm ci ไม่อยู่ใน npm 5.

— dpurrington

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

— adampasz

@adampasz จริงๆแล้วแต่ละ dev สามารถคอมไฟล์ล็อคและเมื่อผ่านการทดสอบและการรวมสาขาที่สองเพิ่งต่ออายุล็อคไฟล์ถ้าแพ็กเกจได้รับการเปลี่ยนแปลงอย่างใด (เราไม่ได้เปลี่ยน package.json บ่อยครั้งที่เราประสบปัญหานี้น้อยลง (

— Xin

38

ฉันไม่ยอมรับไฟล์นี้ในโครงการของฉัน ประเด็นคืออะไร ?

มันถูกสร้างขึ้น
มันเป็นสาเหตุของความผิดพลาดของรหัส SHA1 ใน gitlab ด้วย gitlab-ci.yml builds

แม้ว่ามันจะเป็นความจริงที่ฉันไม่เคยใช้ ^ ใน package.json สำหรับ libs เพราะฉันมีประสบการณ์ที่แย่กับมัน

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

11

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

— PotatoFarmer

2

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

— radtek

6

คุณไม่สามารถใช้ ^ ได้ที่ package.json แต่คุณมั่นใจได้ว่าการพึ่งพาของคุณไม่ได้ใช้งานหรือไม่

— neiker

35

เพื่อคนที่บ่นเกี่ยวกับเสียงเมื่อทำคอมไพล์:

git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

สิ่งที่ฉันทำคือใช้นามแฝง:

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

ในการเพิกเฉย package-lock.json เป็นส่วนต่างสำหรับที่เก็บข้อมูลทั้งหมด (ทุกคนใช้งาน) คุณสามารถเพิ่มสิ่งนี้ใน.gitattributes:

package-lock.json binary
yarn.lock binary

ซึ่งจะส่งผลให้ diffs แสดง "ไฟล์ไบนารี a / package-lock.json และ b / package-lock.json แตกต่างกันเมื่อใดก็ตามที่ไฟล์ล็อคแพ็คเกจถูกเปลี่ยนแปลงนอกจากนี้บริการ Git บางอย่าง (โดยเฉพาะ GitLab แต่ไม่ใช่ GitHub) จะไม่รวมอยู่ด้วย ไฟล์เหล่านี้ (ไม่เกิน 10k บรรทัดที่เปลี่ยนแปลง!) จากความต่างเมื่อดูทางออนไลน์เมื่อทำสิ่งนี้

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

1

ฉันมีgd() { git diff --color-words $1 $2 -- :!/yarn.lock :!/package-lock.json; }ใน. bashrc ของฉันแทนที่จะเป็นนามแฝง

— apostl3pol

16

ใช่คุณสามารถส่งไฟล์นี้ได้ จากเอกสารทางการของ npm :

package-lock.jsonถูกสร้างขึ้นโดยอัตโนมัติสำหรับการดำเนินการใด ๆ ที่npmปรับเปลี่ยนทั้งต้นไม้หรือnode_modules package.jsonมันอธิบายต้นไม้ที่แน่นอนที่สร้างขึ้นเช่นที่ติดตั้งในภายหลังจะสามารถสร้างต้นไม้ที่เหมือนกันโดยไม่คำนึงถึงการปรับปรุงการพึ่งพากลาง

ไฟล์นี้มีวัตถุประสงค์เพื่อส่งไปยังที่เก็บข้อมูลต้นทาง [.]

— Bablu Singh
แหล่งที่มา

13

การติดตั้งจะไม่อัพเดต node_modules เสมอและดังนั้นจึงอัพเดท package-lock.json

— Tim Gautier

2

ไม่คุณสามารถเรียกใช้npm ciเพื่อติดตั้งจาก package-lock.json

— William Hampshire

คุณต้องเครียดในคำตอบของคุณว่าคุณต้องใช้ npm ci ในการสร้างการรวมระบบอย่างต่อเนื่องหากคุณมี package-lock.json ใน repo

— MagicLAMP

6

ปิดใช้งาน package-lock.json ทั่วโลก

พิมพ์สิ่งต่อไปนี้ในเทอร์มินัลของคุณ:

npm config set package-lock false

มันใช้งานได้ดีสำหรับฉันเหมือนเวทมนตร์

— Balogun Ridwan Ridbay
แหล่งที่มา

2

สิ่งนี้สร้าง~/.npmrc(อย่างน้อยใน macos ของฉัน) ที่มีเนื้อหาpackage-lock=falseและสิ่งเดียวกันสามารถทำได้ในโครงการเฉพาะข้างๆnode_modules/(เช่นecho 'package-lock=false' >> .npmrc

— jimmont

6

มันตลกสำหรับฉันที่จะเป็นเชิงลบ ชุมชน npm ไม่สามารถยอมรับได้ว่าการสร้างอัตโนมัติ package-lock.json เป็นการมีส่วนร่วมของชุมชนที่ไม่ดี คุณไม่ควรทำสิ่งที่อาจส่งผลกระทบต่อกระบวนการของทีม ควรเป็นตัวเลือกในการเปิดใช้งานไม่ใช่บังคับ มีกี่คนที่ทำ "git add *" และไม่สังเกตเห็นมันและทำให้เกิดการสกรู หากคุณมีการไหลเวียนตามลักษณะใด ๆ ฉันรู้ว่าการไหลของคอมไพล์เป็นเหมือนพระคัมภีร์ต่อผู้ใช้ที่ใช้สิ่งนี้จะไม่ทำงาน คุณไม่สามารถมีรุ่นต่อไปได้! การกำหนดเวอร์ชัน npm ใช้งานไม่ได้แพ็คเกจ: 1.0.0 ควรถูกกำหนดไว้ล่วงหน้า!

— Eric Twilegar

3

เหตุใดจึงลงคะแนนนี้ นี่เป็นวิธีที่ถูกต้องในการปิดใช้งานคุณลักษณะที่ไม่ทำงาน และถึงแม้ว่ามันจะไม่ตอบคำถามต่อ se แต่มันก็สร้างคำถามขึ้นมา นั่นคือไม่จำเป็นต้องตอบรับอีกต่อไป ยกนิ้วให้ฉัน :)

— Superole

สาเหตุที่ทำให้ downvoted เป็นเพราะคุณเพียงปิดการใช้งานคุณสมบัติ

— Raza

5

ใช่มันเป็นแนวปฏิบัติมาตรฐานในการส่งข้อมูล package-lock.json

เหตุผลหลักในการยืนยัน package-lock.json คือทุกคนในโครงการนั้นอยู่ในแพ็คเกจเดียวกัน

ข้อดี:-

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

จุดด้อย: -

มันสามารถทำให้คำขอดึงของคุณดูน่าเกลียด :) '

แก้ไข: - การติดตั้ง npm จะไม่ทำให้แน่ใจว่าทุกคนในโครงการนั้นอยู่ในแพ็คเกจแพ็คเกจเดียวกัน npm ci จะช่วยในเรื่องนี้

— Nikhil Mohadikar
แหล่งที่มา

4

ข้อเสียจะหายไปถ้าคุณต้องการใช้แทนnpm ci npm install

— k0pernikus

2

ขอบเขตคืบคลานเล็ก ๆ น้อย ๆ แต่นี่เป็นข้อมูลเพิ่มเติมเกี่ยวกับคำแนะนำที่ดีจากที่ @

— ruffin

1

"ทุกคนในโครงการจะอยู่ในแพ็คเกจเวอร์ชันเดียวกันสิ่งที่คุณต้องทำคือติดตั้ง NPM" ไม่จริงคุณต้องใช้ "npm ci" แทน

— reggaeguitar

ขอบคุณ @reggaeguitar อัปเดตคำตอบของฉันสำหรับสิ่งนี้

— Nikhil Mohadikar

2

การใช้งาน npm ของฉันคือการสร้าง css / js ขนาดเล็ก / uglified และสร้างจาวาสคริปต์ที่จำเป็นในหน้าที่ให้บริการโดยแอปพลิเคชัน django ในแอปพลิเคชันของฉัน Javascript ทำงานบนหน้าเว็บเพื่อสร้างภาพเคลื่อนไหวบางครั้งทำการโทร ajax ทำงานภายในกรอบงาน VUE และ / หรือทำงานกับ css หาก package-lock.json มีอำนาจในการควบคุมสิ่งที่อยู่ใน package.json อาจจำเป็นต้องมีไฟล์หนึ่งเวอร์ชัน จากประสบการณ์ของฉันมันไม่ส่งผลกระทบต่อสิ่งที่ติดตั้งโดยการติดตั้ง npm หรือหากมันไม่ได้มีผลกระทบกับแอพพลิเคชั่นที่ฉันปรับใช้กับความรู้ของฉัน ฉันไม่ได้ใช้ mongodb หรือแอปพลิเคชันอื่น ๆ ที่เป็นไคลเอ็นต์แบบบาง

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

เมื่อnpm installรันบนเซิร์ฟเวอร์จะเปลี่ยน package-lock.json และหากมีการเปลี่ยนแปลงไฟล์ที่ repo บันทึกไว้บนเซิร์ฟเวอร์การปรับใช้ WONT ครั้งต่อไปจะช่วยให้คุณสามารถดึงการเปลี่ยนแปลงใหม่จากแหล่งกำเนิด นั่นคือคุณไม่สามารถปรับใช้เนื่องจากการดึงจะเขียนทับการเปลี่ยนแปลงที่ทำกับ package-lock.json

คุณไม่สามารถเขียนทับ package-lock.json ที่สร้างขึ้นภายในเครื่องด้วยสิ่งที่อยู่บน repo (รีเซ็ตต้นแบบแหล่งกำเนิดฮาร์ด) เนื่องจาก npm จะบ่นเมื่อคุณออกคำสั่งเมื่อใดก็ตามที่ package-lock.json ไม่สะท้อนสิ่งที่อยู่ใน node_modules เนื่องจากการติดตั้ง npm ดังนั้นการทำลายการปรับใช้ ตอนนี้ถ้าสิ่งนี้บ่งชี้ว่าเวอร์ชันที่แตกต่างกันเล็กน้อยถูกติดตั้งใน node_modules อีกครั้งที่ไม่เคยทำให้ฉันเกิดปัญหา

หาก node_modules ไม่ได้อยู่บน repo ของคุณ (และไม่ควรเป็น) ดังนั้น package-lock.json ควรถูกละเว้น

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

jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

และบิลด์ล้มเหลวอย่างไรก็ตามเมื่อติดตั้ง node_modules หรือใช้ npm เพื่อบิลด์ js / css จะไม่มีการร้องเรียนหากฉันลบ package-lock.json

jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...

— ตะเกียงวิเศษ
แหล่งที่มา

เพียงเพิ่มตอนนี้ฉันได้กำหนด package-lock.json ของฉันไปยังที่เก็บของฉันและฉันใช้ npm ci ในการปรับใช้ของฉันซึ่งฉันเชื่อว่า node_modules ลบของและติดตั้งทุกอย่างใน package-lock.json โดยไม่ต้องอัปเดต สิ่งนี้ทำให้ผู้ใช้ front end ของฉันอัพเกรดสิ่งจาวาสคริปต์โดยไม่จำเป็นต้องมีการแทรกแซงในการปรับใช้

— MagicLAMP