A Guide to npm: The Node.js Package Manager

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

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

เข้าสู่ Node Package Manager (npm) – ตัวจัดการแพ็คเกจ JavaScript ที่ใช้ร่วมกับ Node.js ได้อย่างโดดเด่นที่สุด แม้ว่าจะใช้งานแยกกันได้ก็ตาม ช่วยให้คุณควบคุมการพึ่งพาโปรเจ็กต์ของคุณได้อย่างดีเยี่ยม และเป็นวิธีที่ยอดเยี่ยมในการมีส่วนร่วมกับโลกโอเพนซอร์ส

คุณสามารถเริ่มต้นได้ด้วยการรัน npm install <package name> และฉีดเข้าไปในไฟล์ JavaScript ของคุณ

ต้องการติดตั้งเวอร์ชันเฉพาะหรือไม่? ไม่มีปัญหา. รัน npm install <package name>@1.2.3

ต้องการติดตั้งแพ็คเกจทั่วโลก (เช่น Mocha หรือ Angular-CLI) หรือไม่ เพียงเพิ่ม -g เช่น: npm install -g angular-cli mocha

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

คำสั่ง CLI

CLI เป็นที่ที่ผู้ใช้ใช้เวลาส่วนใหญ่ในการโต้ตอบกับ npm และส่วนต่อประสานความช่วยเหลือของมันมีประโยชน์จริง ๆ

ความช่วยเหลือในการค้นหา ( ความ npm help ) จะแสดงตัวเลือกทั้งหมดออกมา และการรัน npm help-search <searchText> จะแสดงรายการผลการค้นหาให้คุณโดยตรงจากการลดราคา npm

นี่คือคำสั่งหลักที่โดดเด่น

• install : มีการกล่าวถึงที่นี่เนื่องจากความจำเป็นอย่างยิ่งเมื่อทำงานกับ npm ใช้เพื่อติดตั้งแพ็คเกจใหม่ในเครื่องหรือทั่วโลก (เมื่อเพิ่ม -g ) หรือเพื่อติดตั้งการพึ่งพาที่แสดงในไฟล์ package.json (เพิ่มเติมในภายหลัง)

• uninstall : นี่เป็นสิ่งจำเป็นเช่นกัน ใช้เพื่อล้างแพ็คเกจเฉพาะจากไดเร็กทอรี node_modules ทั้งภายในเครื่องหรือทั่วโลก (เมื่อเพิ่ม -g )

• access : นี่คือสนามเด็กเล่นของผู้ดูแลระบบการอนุญาตผู้ใช้ npm ภายในบริบท npm-organizations และแพ็คเกจที่มีขอบเขต (ส่วนตัว) สิ่งที่ทรงพลังอย่างจริงจัง ใช้ร่วมกับ adduser , owner , team ฯลฯ ช่วยให้สามารถควบคุมได้อย่างละเอียดว่าใครสามารถเข้าถึงอะไรได้บ้าง

• bin : แพ็คเกจติดตั้งอยู่ที่ไหนในโลก รันคำสั่งนี้เพื่อดูพาธไฟล์สัมบูรณ์

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

• config : เราจะเข้าสู่ตัวเลือกการกำหนดค่าต่างๆ ในภายหลัง แต่คำสั่งนี้เกี่ยวข้องกับคุณสมบัติการกำหนดค่าที่คงอยู่เป็นหลักในไฟล์การกำหนดค่าภายในหรือส่วนกลางโดยใช้คำสั่งย่อย set get หรือ delete

• dedupe หรือ ddp : เมื่อทำงานบนโปรเจ็กต์ในช่วงระยะเวลาหนึ่ง และติดตั้งแพ็กเกจโดยตรงจาก npm คำสั่งนี้จะสำรวจโครงสร้างแพ็กเกจในเครื่องและพยายามทำให้การพึ่งพาอาศัยกันง่ายขึ้น

• link : เมื่อคุณกำลังพัฒนาแพ็คเกจ npm ของคุณเอง สิ่งนี้จะให้คุณสร้างลิงก์เชื่อมโยงไปยังบริบทส่วนกลาง เพื่อให้สามารถทดสอบได้ราวกับว่ามันถูกติดตั้งทั่วโลกจากรีจิสตรี npm ตัวอย่างเช่น หากคุณกำลังเขียนเครื่องมือแอสเซมบลีในโหนดที่มี CLI ติดตั้งอยู่ทั่วโลก คุณสามารถรันคำสั่งนี้และทดสอบพฤติกรรมของ CLI ของคุณโดยไม่จำเป็นต้องปรับใช้ก่อน

• ls : ใช้เพื่อแสดงภาพการขึ้นต่อกันของแพ็คเกจและการขึ้นต่อกันในโครงสร้างแบบต้นไม้ น่าดูและยังมีประโยชน์สำหรับการเปรียบเทียบกับโครงการอื่นๆ

• outdated : ใช้เพื่อประเมินสถานะปัจจุบันของการอ้างอิงที่ติดตั้งและดูว่าล้าสมัยหรือไม่ ในโครงการที่รายการการขึ้นต่อกันของรูทมีความยาวหลายร้อยบรรทัด การตรวจสอบแพ็คเกจด้วยตนเองนั้นแทบจะเป็นไปไม่ได้เลย การเพิ่ม -g --depth=0 ให้กับคำสั่งนี้ทำให้คุณสามารถตรวจสอบแพ็คเกจที่ติดตั้งทั่วโลกได้

• publish : คำสั่งนี้จำเป็นเมื่อพัฒนาแพ็คเกจของคุณเองสำหรับ npm มันทำตามชื่อที่แนะนำ มันเผยแพร่แพ็คเกจของคุณไปยังรีจิสตรี npm

• search : ใช้สิ่งนี้เพื่อค้นหาแพ็คเกจทั้งหมดที่มีข้อความที่ให้ไว้ในอาร์กิวเมนต์ที่สามในรีจิสทรี

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

• star : คุณชอบแพ็คเกจที่คุณใช้จริงหรือ? ใช้คำสั่งนี้เพื่อแสดงความขอบคุณโดยตรงจากเทอร์มินัล ซึ่งจะสะท้อนให้เห็นในหน้าของแพ็คเกจในการลงทะเบียน npm

• update : โดยปกติแล้วจะเป็นไปตามคำสั่งที่ outdated เพื่ออัปเดตแพ็คเกจที่ล้าสมัย

• version : สิ่งนี้ช่วยให้คุณจดชวเลขเพื่อชนคุณสมบัติรุ่น package.json และทำแท็ก git ทั้งหมดในที่เดียว

โปรดทราบว่าคำสั่งเหล่านี้ส่วนใหญ่สามารถรับคำสั่งย่อยและ/หรือการกำหนดค่าได้ และรายการนี้ไม่ได้หมายถึงการสิ้นสุดการสนทนาทั้งหมดบน CLI

npm-config

การกำหนดค่าเป็นส่วนสำคัญของ npm และมีหลายวิธีที่ตัวแปรการกำหนดค่าสามารถตั้งค่าได้

การกำหนดค่าผ่าน CLI และตัวแปรสิ่งแวดล้อม

ขั้นแรก คุณสามารถตั้งค่าคอนฟิกผ่าน CLI จากเทอร์มินัลได้

โดยทั่วไปแล้วจะมีลักษณะดังนี้: npm <command> --<configuration option> [<optional value>]

หากไม่ได้ระบุค่า ตัวเลือกจะถูกตั้งค่าเป็น true โดยค่าเริ่มต้น

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

ทำได้โดยง่ายโดยผนวก --access=public ต่อท้ายคำสั่ง publish ของคุณ หากเราไม่ได้ระบุคุณสมบัติให้เป็นสาธารณะ ค่าเริ่มต้นจะถูกจำกัด (ส่วนตัว)

การกำหนดค่าต่อท้ายคำสั่งอื่นๆ เช่นนี้จะไม่คงอยู่ทุกที่ ดังนั้นจึงอาจเป็นเรื่องที่น่าเบื่อหน่ายในการตั้งค่าอาร์เรย์ของการกำหนดค่าผ่าน CLI

ในกรณีเหล่านี้ อาจเป็นการดีกว่าที่จะตั้งค่าคอนฟิกโดยใช้ตัวแปรสภาพแวดล้อม

ตัวแปรสภาวะแวดล้อมใดๆ ที่ตั้งค่าด้วยคำนำหน้า npm_config_ จะถูกใช้เพื่อกำหนดค่า npm

ตัวอย่างเช่น: export npm_config_registry=localhost:4321 จะตั้งค่าตัวเลือกการกำหนดค่ารีจิสทรีทั่วโลก และเมื่อดำเนินการ npm จะใช้รีจิสทรี npm ที่ localhost บนพอร์ต 4321

การกำหนดค่าผ่านไฟล์ npmrc

คุณยังสามารถตั้งค่าตัวเลือกการกำหนดค่าโดยใช้ไฟล์ .npmrc พิเศษ ซึ่งสามารถตั้งค่าในระดับต่างๆ ได้ขึ้นอยู่กับความต้องการของคุณ:

• ระดับโปรเจ็กต์: ในรูทของโค้ดของโปรเจ็กต์พร้อมกับไฟล์ package.json โดยทั่วไปแล้วจะอยู่ path/to/project/.npmrc
• ระดับผู้ใช้: ไดเร็กทอรีที่กำหนดค่าบัญชีผู้ใช้เฉพาะ โดยทั่วไป ~/.npmrc
• ระดับโกลบอล: ไดเร็กทอรีที่ npm ค้นหาคอนฟิกูเรชันโกลบอล โดยทั่วไปคือ $PREFIX/etc/npmrc
• ระดับในตัว: ระวัง. การกำหนดค่านี้ไม่เพียงแต่เป็นสากลเท่านั้น แต่ยังเป็นส่วนหนึ่งของซอร์สโค้ด npm และแนวทางปฏิบัติที่ดีที่สุดแนะนำ (ตามความเป็นจริง) ว่าเราไม่เปลี่ยนโค้ด เราไม่รับผิดชอบต่อการบำรุงรักษา โดยทั่วไปสามารถพบได้ที่ /path/to/npm/npmrc

การตั้งค่าคอนฟิกูเรชันในไฟล์ .npmrc สามารถแก้ไขและคงไว้ได้โดยใช้ CLI โดยการรันคำสั่งในรูปแบบนี้: npm config set <key> <value>

ตัวอย่างเช่น คุณสามารถเรียกใช้ npm config set access public เพื่อให้การกำหนดค่าการเผยแพร่ของแพ็คเกจที่กำหนดขอบเขต (ส่วนตัว) เป็นแบบสาธารณะอย่างต่อเนื่อง

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

เมื่อคอนฟิกูเรชันแบบถาวรจำเป็นต้องเกิดขึ้นในระดับโปรเจ็กต์ หรือในระดับบิวด์อิน ไฟล์ .npmrc จะต้องถูกแก้ไขโดยใช้เท็กซ์เอดิเตอร์

การกำหนดค่าผ่าน package.json

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

การตั้งค่าคอนฟิกที่โดดเด่น

• access : ตามที่กล่าวไว้ข้างต้น ใช้เพื่อกำหนดสิทธิ์

• always-auth : โปรดทราบว่าการตั้งค่านี้มีค่าเริ่มต้นเป็นเท็จ เมื่อตั้งค่าเป็นจริง npm จะต้องมีการตรวจสอบสิทธิ์เสมอเมื่อติดต่อกับรีจิสทรี

• ca : ค่าเริ่มต้นเป็นผู้ออกใบรับรอง npm (CA) สามารถเปลี่ยนเป็นค่าว่างเพื่ออนุญาตการเข้าถึงเฉพาะผู้รับจดทะเบียนที่รู้จัก หรือใบรับรอง CA เฉพาะเพื่อให้สิทธิ์เข้าถึงเฉพาะผู้ลงทะเบียนรายนั้นเท่านั้น การตั้งค่านี้พร้อมกับ cafile , cert และ strict-ssl นั้นไม่ค่อยมีใครใช้ แต่พูดถึงความปลอดภัยและความน่าเชื่อถือของ npm ซึ่งช่วยให้สบายใจได้เมื่อรู้ว่าแพ็คเกจที่คุณกำลังติดตั้งนั้นมาจากแหล่งที่คุณคาดหวัง

• color : ค่าดีฟอลต์นี้เป็น true ทำให้คุณหลุดพ้นจากความเยือกเย็นมาตรฐานของเทอร์มินัลด้วยการระบายสี stdout ที่อนุญาตโดยตัวอธิบายไฟล์ tty หากตั้งค่าเป็นเท็จ เทอร์มินัลจะยังคงทื่อ เมื่อตั้งค่าเป็น always จะแสดงผลเป็นสีเสมอ

• depth : การตั้งค่านี้ช่วยให้สามารถควบคุมสิ่งที่คุณเห็นได้อย่างละเอียดด้วยคำสั่งแบบเรียกซ้ำ เช่น ls และ outdated โดยกำหนดความลึกของการดำเนินการ ค่า 0 จะประเมินการพึ่งพาระดับแรกเท่านั้น ในขณะที่ค่าอนันต์ (ค่าเริ่มต้น) จะทำให้การประเมินการขึ้นต่อกันทุกระดับ ข้อยกเว้นของกฎนี้คือเมื่อใช้กับ outdated ในกรณีนั้น อินฟินิตี้จะถูกตีความว่าเป็น 0 เพื่อให้แน่ใจว่าได้ผลลัพธ์ที่เกี่ยวข้องกันมากขึ้น

• dev : สิ่งนี้ถูกตั้งค่าเป็น false โดยค่าเริ่มต้น แต่เมื่อตั้งค่าเป็น true (เมื่อทำการ npm install ) การพึ่งพาการพัฒนาทั้งหมดในไฟล์ package.json จะถูกติดตั้งพร้อมกับการพึ่งพาปกติ

• dry-run : เมื่อตั้งค่านี้เป็น true npm จะไม่ทำการเปลี่ยนแปลงใดๆ กับแพ็คเกจของคุณ แต่จะบอกคุณว่าจะทำอะไรได้บ้าง สิ่งนี้มีประโยชน์มากเมื่อรันคำสั่งบางอย่าง เช่น dedupe หรือ update

  

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

• loglevel : โดยค่าเริ่มต้น สิ่งนี้ถูกตั้งค่าเป็น warn ซึ่งให้ข้อผิดพลาดและเอาต์พุตคำเตือนเมื่อรันคำสั่ง npm การตั้งค่าอื่นๆ ได้แก่ silent ซึ่งไม่มีเอาต์พุต error ซึ่งบันทึกข้อผิดพลาดไปยังเอาต์พุตเท่านั้น http ซึ่งประกาศเฉพาะข้อผิดพลาดในคำขอ http; info เพื่อต้องการเอาท์พุตข้อมูล); verbose ซึ่งบันทึกเกือบทุกอย่าง และ silly ซึ่งก็เหมือนกับชื่อที่แนะนำ ให้ผลลัพธ์จำนวนที่ไร้สาระ แล้วก็บางส่วน

• production : เมื่อตั้งค่าเป็นจริง npm จะดำเนินการตามนั้นและรันคำสั่งทั้งหมดในโหมดใช้งานจริง ซึ่งหมายความว่าจะไม่มีการติดตั้งการพัฒนาหรือการพึ่งพาที่เป็นทางเลือก และจะไม่ดำเนินการใดๆ ที่เกี่ยวข้องกับการพัฒนา

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

• บันทึก : When installing a package directly from the registry, you can append –save ต่อท้าย to the command which will add the installed package to the dependencies option in the file. For example, package.json file. For example, npm install lodash` จะเพิ่ม lodash ให้กับการอ้างอิงของคุณ

• save-dev : คล้ายกับตัวเลือกบันทึกการกำหนดค่า ให้เพิ่ม --save-dev เมื่อติดตั้งแพ็คเกจ จากนั้นจะถูกเพิ่มไปยังตัวเลือก devDependencies ในไฟล์ package.json

• save-optional : คล้ายกับตัวเลือกบันทึกการกำหนดค่า ให้เพิ่ม --save-optional เมื่อติดตั้งแพ็คเกจ จากนั้นจะถูกเพิ่มไปยังตัวเลือก optionalDependencies ในไฟล์ package.json

• save-exact : เมื่อทำการติดตั้งแพ็คเกจ ตัวเลือก save , save-dev และ save-optional แก้ไขไฟล์ package.json โดยการแทรกแพ็คเกจที่ติดตั้งลงในคุณสมบัติที่เกี่ยวข้องด้วยตัวดำเนินการช่วง semver เมื่อเรียกใช้การตั้งค่าการกำหนดค่า 'บันทึกที่แน่นอน' ด้วยค่าจริง ร่วมกับการตั้งค่าใดการตั้งค่าหนึ่งที่กล่าวถึงข้างต้น จะใช้หมายเลขเวอร์ชันเฉพาะ โดยไม่สนใจช่วงเซเวอร์

• save-prefix : ตั้งค่าตัวดำเนินการช่วง semver เมื่อใช้ save , save-dev หรือ save-optional ค่าดีฟอลต์คือ ^ ซึ่งช่วยให้สามารถอัปเกรดแพ็คเกจเล็กน้อยเมื่อติดตั้ง ค่านี้สามารถตั้งค่าเป็นโอเปอเรเตอร์ช่วงเซมเวอร์นำหน้าที่ถูกต้องได้

• tag-version-prefix : ค่าดีฟอลต์ทั่วไปคือ v ซึ่งระบุสิ่งที่อยู่ข้างหน้าเวอร์ชันแท็ก git เมื่อเรียกใช้ npm version

กำลังอัปเดต npm โดยใช้ npm

คุณยังสามารถใช้ npm เพื่ออัปเดตตัวเองได้

เพียงเรียกใช้ npm install -g npm@latest แล้ว npm จะได้รับการอัปเดตเป็นเวอร์ชันเสถียรล่าสุด สิ่งสำคัญคือต้องสังเกตว่า Node.js แต่ละเวอร์ชันมาพร้อมกับ npm เวอร์ชันเฉพาะ และจากประสบการณ์ของฉัน คุณไม่ควรยุ่งกับการจับคู่นั้นมากเกินไป

ท้ายที่สุดแล้ว คำแนะนำของฉันคือให้ยึดติดกับการจับคู่ตามที่ตั้งใจไว้

เมื่อใช้ npm เป็นเครื่องมือแบบสแตนด์อโลน ตรวจสอบให้แน่ใจว่าคุณเข้าใจความหมายของการใช้เวอร์ชันที่คุณเลือก มีเครื่องมือที่ยอดเยี่ยมสำหรับการจัดการ Node.js เวอร์ชันต่างๆ (และในทางกลับกัน เวอร์ชัน npm) ในระบบเดียวกันที่เรียกว่า nvm

ไฟล์ package.json

ไฟล์ package.json เป็นองค์ประกอบสำคัญที่เชื่อมโยงทุกอย่างเข้าด้วยกัน

เป็นข้อกำหนดสำหรับการเผยแพร่แพ็คเกจไปยังรีจิสตรี npm และเป็นส่วนที่การจัดการของการพึ่งพาอาศัยกัน

มีช่องที่ต้องกรอกสองช่อง ได้แก่ "ชื่อ" และ "เวอร์ชัน" และเมื่อรวมกันแล้วคุณสมบัติเหล่านี้ควรเป็นตัวระบุที่ไม่ซ้ำกัน

ฟิลด์ชื่อควรเป็นไปตามกฎบางอย่าง ตามที่กำหนดโดยเอกสาร npm เกี่ยวกับการตั้งชื่อ และฟิลด์เวอร์ชันอยู่ภายใต้ข้อกำหนดของเซิร์ฟเวอร์

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

"หลัก"

“main” กำหนดจุดเริ่มต้นของแอปพลิเคชันของคุณ ซึ่งมีค่าเริ่มต้นเป็น index.js ขึ้นอยู่กับแบบแผนหรือกรอบงานของคุณ อาจเป็น app.js หรือ main.js แน่นอน คุณสามารถทำอะไรก็ได้ที่คุณต้องการ

“สคริปต์”

นี่เป็นทรัพย์สินที่ประเมินราคาต่ำเกินไป

อย่างแรก สามารถใช้เพื่อทำสิ่งต่าง ๆ ในการเผยแพร่ล่วงหน้า

อย่างที่สอง มันเป็นสถานที่ที่คุณสามารถใช้นามแฝงของอาร์เรย์ของคำสั่งที่ใช้บ่อยได้ ตั้งแต่งานสร้าง (กำหนดในอึกหรือเสียงฮึดฮัด) ทริกเกอร์การติดตั้งการพึ่งพาอื่น ๆ (บางอย่างเช่น bower) การเริ่มต้นเซิร์ฟเวอร์การพัฒนาด้วย webpack หรือ เรียกใช้ชุดคำสั่งทุบตี

“การพึ่งพาอาศัยกัน”

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

ทำได้โดยการเพิ่ม --save (หรือชวเลข -S ) ที่ส่วนท้ายของคำสั่ง npm install

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

ในทำนองเดียวกัน การพึ่งพาสามารถลบออกได้โดยการเพิ่ม --save เมื่อรันคำสั่ง npm uninstall

สิ่งสำคัญคือต้องตระหนักถึงรูปแบบการกำหนดเวอร์ชันเซิร์ฟเวอร์ของแต่ละการขึ้นต่อกันและความหมายของมัน

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

การติดตั้งแพ็กเกจที่เสียหายสามารถพิสูจน์ได้ว่าแก้ไขได้ยาก โดยเฉพาะอย่างยิ่งเมื่อใช้เวอร์ชันย่อของแพ็กเกจ

“การพึ่งพาการพัฒนา”

แยกจากคุณสมบัติการพึ่งพา คุณสมบัติ "devDependencies" ช่วยให้คุณสามารถกำหนดการอ้างอิงที่ใช้เฉพาะในระหว่างขั้นตอนการพัฒนาและไม่จำเป็นสำหรับบิลด์ที่ใช้งานจริง (เช่น ESLint แพ็คเกจ grunt-contrib และ Protractor) เช่นเดียวกับการพึ่งพา คุณสมบัตินี้สามารถแก้ไขได้จากเทอร์มินัลโดยการเพิ่ม --save-dev (หรือชวเลข -D ) ต่อท้ายคำสั่ง npm install หรือคำสั่ง npm uninstall ข้อควรระวังเดียวกันนี้ใช้กับการกำหนดเวอร์ชันตามที่กล่าวถึงภายใต้การพึ่งพา

“ถังขยะ”

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

“กำหนดค่า”

ตามที่กล่าวไว้ก่อนหน้านี้ นี่คือที่ที่คุณกำหนดการตั้งค่าคอนฟิกูเรชันผ่านไฟล์ package.json ของคุณ

"ส่วนตัว"

เมื่อตั้งค่าเป็นจริง npm จะปฏิเสธที่จะเผยแพร่แพ็คเกจ

ไม่ควรสับสนกับการตั้งค่าการกำหนดค่าการเข้าถึง

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

หากความตั้งใจของคุณเปลี่ยนไป เพียงแค่เปลี่ยนการตั้งค่าเป็น "เท็จ" และคุณจะสามารถเผยแพร่แพ็คเกจของคุณได้

คุณสมบัติที่กำหนดเอง

ไฟล์ package.json ยังยอมรับคุณสมบัติที่กำหนดเอง ตราบใดที่ยังไม่ได้กำหนดหรือจองชื่อไว้

การพัฒนาแพ็คเกจ npm ของคุณเอง

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

เป็นไปได้ว่าเมื่อถึงจุดหนึ่ง คุณยังต้องการพัฒนาแพ็คเกจของคุณเองเพื่อแชร์

ขั้นแรก คุณต้องสร้างไฟล์ package.json ด้วยคุณสมบัติขั้นต่ำที่จำเป็นของ “ชื่อ” และ “รุ่น” จากนั้นจึงสร้างคุณสมบัติ “หลัก” เพื่อระบุจุดเริ่มต้น เช่น index.js

เขียนรหัสของคุณในไฟล์ index.js นั้น เข้าสู่ระบบด้วยบัญชีผู้ใช้ npm ของคุณ หรือสร้างผู้ใช้ใหม่จากเทอร์มินัล และคุณพร้อมที่จะเผยแพร่ไปยังรีจิสทรี npm

แพ็คเกจสามารถเป็นสาธารณะหรือส่วนตัวได้

แพ็คเกจสาธารณะมีอิสระในการเผยแพร่และพร้อมให้ทุกคนนำไปใช้

แพ็คเกจส่วนตัว เรียกว่าแพ็คเกจที่มีขอบเขต สามารถเผยแพร่ได้ก็ต่อเมื่อคุณจ่ายผู้ใช้โมดูลส่วนตัว และสามารถระบุได้ด้วย @username/ ที่แตกต่างกันซึ่งต่อท้ายชื่อแพ็คเกจ

แพ็คเกจที่มีขอบเขตสามารถเผยแพร่สู่สาธารณะได้ด้วยการเรียกคำสั่ง publish ด้วย --access=public

นอกจากนี้ หากคุณใช้เวลามากขึ้นในการขยายและปรับปรุงฐานรหัสของแพ็คเกจ และถึงเวลาสำหรับการเผยแพร่เวอร์ชันใหม่ คุณเพียงแค่เปลี่ยนเวอร์ชัน (ตามกฎและแบบแผนของเซิร์ฟเวอร์) ของแพ็คเกจใน package.json ไฟล์และพิมพ์ npm publish

คุณยังสามารถใช้อินเทอร์เฟซบรรทัดคำสั่งและเรียก npm version <update_type> โดยที่ update_type เป็น patch , minor หรือ major ตามที่อธิบายโดย semver จากนั้นจะเพิ่มหมายเลขเวอร์ชันในไฟล์ package.json โดยอัตโนมัติ

npm องค์กร

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

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

แม้ว่าจะเป็นเรื่องยากที่จะเชี่ยวชาญ แต่ก็คุ้มค่ามาก

พลังของnpm

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

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

สำหรับบทความที่น่าสนใจเพิ่มเติมเกี่ยวกับ npm ให้ลองอ่าน การใช้ Scala.js กับ npm และ Browserify