ควรรวมโฟลเดอร์“ node_modules” ในที่เก็บ git

ฉันสงสัยว่าเราควรติดตาม node_modules ใน repo ของเราหรือทำการติดตั้ง npm เมื่อตรวจสอบรหัสหรือไม่

คำตอบนั้นไม่ง่ายอย่างที่ Alberto Zaccagni แนะนำ หากคุณพัฒนาแอปพลิเคชัน (โดยเฉพาะแอปพลิเคชันระดับองค์กร) รวมถึง node_modules ใน repo git ของคุณเป็นตัวเลือกที่ทำงานได้และตัวเลือกใดที่คุณเลือกขึ้นอยู่กับโครงการของคุณ

เพราะเขาถกเถียงกันได้ดีกับ node_modules ฉันจะจดจ่อกับมัน

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

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

คุณสามารถค้นหาข้อดีข้อเสียในบทความ Addy Osmani นี้ (แม้ว่าจะเป็นเรื่องเกี่ยวกับ Bower มันก็เกือบจะเป็นสถานการณ์เดียวกัน) และฉันจะจบด้วยคำพูดจากหน้าแรกของ Bower และบทความของ Addy:

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

รายละเอียดโมดูลจะถูกเก็บไว้ในpackages.jsonนั้นก็เพียงพอแล้ว ไม่จำเป็นต้องเช็คอินnode_modulesไม่จำเป็นต้องเช็คอินไม่ได้

คนที่ใช้ในการจัดเก็บnode_modulesในการควบคุมเวอร์ชันเพื่อล็อคการพึ่งพาของโมดูล แต่มีการลดขนาด npmที่ไม่จำเป็นอีกต่อไป

เหตุผลอีกประการสำหรับจุดนี้ตามที่ @ChrisCM เขียนไว้ในความคิดเห็น:

นอกจากนี้ยังเป็นที่น่าสังเกตว่าโมดูลใด ๆ ที่เกี่ยวข้องกับส่วนขยายเนทีฟจะไม่ทำงานสถาปัตยกรรมกับสถาปัตยกรรมและจำเป็นต้องสร้างใหม่ ให้เหตุผลที่เป็นรูปธรรมไม่รวมถึงพวกเขาใน repo

ฉันอยากจะแนะนำให้ตรวจสอบใน node_modulesเนื่องจากแพคเกจเช่น PhantomJS และ node-sass ซึ่งติดตั้งไบนารีที่เหมาะสมสำหรับระบบปัจจุบัน

ซึ่งหมายความว่าหาก Dev Dev หนึ่งรันnpm installบน Linux และตรวจสอบใน node_modules - จะไม่ทำงานสำหรับ Dev อื่นที่ทำซ้ำ repo บน Windows

มันจะดีกว่าที่จะตรวจสอบ tarballs ที่ติดตั้งการดาวน์โหลดและชี้ไปnpm-shrinkwrap.jsonที่พวกเขา คุณสามารถทำให้กระบวนการนี้โดยใช้shrinkpack

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

ฉันมักจะแนะนำไม่ให้ node_modules ภายใต้การควบคุมเวอร์ชัน ผลประโยชน์เกือบทั้งหมดจากการทำเช่นนี้ตามที่ระบุไว้ในบริบทของคำตอบที่ยอมรับนั้นล้าสมัยไปแล้วในขณะนี้

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

2. การวางไฟล์ package-json.lock ใน VCS กำลังช่วยในการอ้างอิงที่อัพเดทบ่อยครั้งอาจส่งผลให้เกิดการตั้งค่าที่แตกต่างกันแม้ว่าจะใช้ไฟล์ package.json เดียวกัน

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

Centralized VCS 'like svn ต้องการการถ่ายโอนและส่งไฟล์ผ่านเครือข่ายซึ่งจะช้าเหมือนนรกเมื่อพูดถึงการเช็คเอาต์หรืออัปเดตโฟลเดอร์ node_modules

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

ดังนั้นหากคุณสนใจกระบวนการที่มีประสิทธิภาพและต้องการให้สิ่งต่าง ๆ "เล็ก" ฉันควรใช้ที่เก็บส่วนแยกต่างหากเช่น Nexos Repository (หรือเซิร์ฟเวอร์ HTTP บางตัวที่มีไฟล์เก็บถาวร ZIP) ซึ่งให้ชุดของการอ้างอิงที่ดาวน์โหลดมาก่อนหน้านี้

การไม่ติดตามnode_modulesด้วยตัวควบคุมแหล่งที่มาเป็นตัวเลือกที่ถูกต้องเนื่องจากบางโมดูล NodeJS เช่นไดรเวอร์ MongoDB NodeJS ใช้โปรแกรมเสริม NodeJS C ++ ส่วนเสริมเหล่านี้ถูกคอมไพล์เมื่อรันnpm installคำสั่ง ดังนั้นเมื่อคุณติดตามnode_modulesไดเรกทอรีคุณอาจยอมรับไฟล์ไบนารีเฉพาะของระบบปฏิบัติการโดยไม่ตั้งใจ

ฉันเห็นด้วยกับivoszzว่าบางครั้งมันมีประโยชน์ในการตรวจสอบโฟลเดอร์ node_modules แต่ ...

สถานการณ์ที่ 1:

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

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

อ่านเพิ่มเติม

ดังนั้นโอกาสสำหรับเรื่องนี้จึงต่ำ แต่มีสถานการณ์ที่ 2 ...

สถานการณ์ที่ 2:

สถานการณ์อื่น ๆ ที่เป็นกรณีนี้: คุณพัฒนาซอฟต์แวร์รุ่นองค์กรหรือซอฟต์แวร์ที่สำคัญมากและเขียนใน package.json ของคุณ:

"dependencies": {
    "studpid-package": "~1.0.1"
}

คุณใช้วิธีการfunction1(x)ของแพคเกจนั้น

ขณะนี้นักพัฒนาของ studpid แพคเกจเปลี่ยนชื่อวิธีfunction1(x)การfunction2(x)และพวกเขาทำให้ความผิด ... พวกเขาเปลี่ยนรุ่นของแพคเกจของพวกเขาจากไป1.0.1 1.1.0นั่นเป็นปัญหาเพราะเมื่อคุณโทรnpm installครั้งต่อไปคุณจะยอมรับรุ่น1.1.0เพราะคุณใช้เครื่องหมายตัวหนอน ("studpid-package": "~1.0.1" )

การโทรfunction1(x)สามารถทำให้เกิดข้อผิดพลาดและปัญหาได้ในขณะนี้

แต่:

การผลักดันโฟลเดอร์ node_modules ทั้งหมด (บ่อยกว่า 100 MB) ไปยังที่เก็บของคุณจะทำให้คุณใช้พื้นที่หน่วยความจำ กี่ kb (package.json เท่านั้น) เปรียบเทียบกับหลายร้อย MB (package.json & node_modules) ... ลองคิดดู

คุณสามารถทำได้ / ควรคิดถึงมันหาก:

• ซอฟต์แวร์มีความสำคัญมาก

• คุณต้องเสียเงินเมื่อมีบางสิ่งผิดพลาด

• คุณไม่เชื่อถือรีจิสทรี npm npm ถูกรวมศูนย์และในทางทฤษฎีอาจถูกปิด

คุณไม่จำเป็นต้องเผยแพร่โฟลเดอร์ node_modules ใน 99.9% ของกรณีต่างๆหาก:

• คุณพัฒนาซอฟต์แวร์สำหรับตัวคุณเอง

• คุณได้ตั้งโปรแกรมบางอย่างและต้องการเผยแพร่ผลลัพธ์บน GitHub เพราะอาจมีคนอื่นสนใจ

หากคุณไม่ต้องการ node_modules ที่จะอยู่ในพื้นที่เก็บข้อมูลของคุณเพียงแค่สร้างไฟล์และเพิ่มบรรทัด.gitignorenode_modules

ฉันต้องการเสนอทางเลือกกลางถนน

1. อย่าเพิ่ม node_modulesเข้าไปในคอมไพล์
2. ใช้ package-lock.jsonไฟล์เพื่อกำหนดเวอร์ชันการพึ่งพาของคุณ
3. ใน CI หรือกระบวนการรีลีสของคุณเมื่อคุณปล่อยเวอร์ชันให้ทำสำเนาของโฟลเดอร์ node_modules และสำรองข้อมูล (เช่นในที่เก็บข้อมูลบนคลาวด์)

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

อีกสิ่งหนึ่งที่ควรพิจารณา: การเช็คอินnode_modulesทำให้ยาก / เป็นไปไม่ได้ที่จะใช้ความแตกต่างระหว่างdependenciesและdevDependenciesและ

บนมืออื่น ๆ แม้ว่าใครจะบอกว่ามันมั่นใจที่จะผลักดันไปสู่การผลิตรหัสเดียวกันแน่นอนที่เดินผ่านการทดสอบ - devDependenciesเพื่อให้รวมถึง

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