หลักสูตรเริ่มต้นสู่การเรียนรู้ส่วนหน้า (vue): การเข้าสู่การเรียนรู้
ทุกวันนี้ นักเรียนที่พัฒนาส่วนหน้าไม่สามารถทำได้หากไม่มี npm ซึ่งเป็นเครื่องมือการจัดการแพ็คเกจที่ยอดเยี่ยม กลไกการจัดการเวอร์ชันแพ็คเกจที่ยอดเยี่ยมนำพาชุมชน NodeJS ที่เจริญรุ่งเรืองทั้งหมด เพื่อทำความเข้าใจกลไกภายใน ช่วยให้เข้าใจการพัฒนาโมดูลและการกำหนดค่าทางวิศวกรรมส่วนหน้าให้ลึกซึ้งยิ่งขึ้นเพื่อเร่งการแก้ไขปัญหาของเรา (ฉันเชื่อว่านักเรียนหลายคนประสบปัญหาการพึ่งพาต่างๆ)
บทความนี้ดำเนินการวิเคราะห์โดยละเอียดเกี่ยวกับกลไกการจัดการแพ็กเกจของ npm จากสามมุมมอง: package.json การจัดการเวอร์ชัน การติดตั้งการขึ้นต่อกัน และตัวอย่างเฉพาะ
ใน Node.js โมดูลคือไลบรารีหรือเฟรมเวิร์กและยังเป็นโปรเจ็กต์ Node.js โปรเจ็กต์ Node.js เป็นไปตามสถาปัตยกรรมแบบโมดูลาร์ เมื่อเราสร้างโปรเจ็กต์ Node.js นั่นหมายถึงการสร้างโมดูลนี้จะต้องมีไฟล์คำอธิบาย ซึ่งก็คือ package.json มันเป็นไฟล์การกำหนดค่าที่พบบ่อยที่สุดของเรา แต่คุณเข้าใจรายละเอียดการกำหนดค่าโดยละเอียดหรือไม่? การกำหนดค่าไฟล์ package.json ที่สมเหตุสมผลจะกำหนดคุณภาพของโปรเจ็กต์ของเราโดยตรง ดังนั้นก่อนอื่นเราจะวิเคราะห์การกำหนดค่าโดยละเอียดของ package.json
มีคุณลักษณะมากมายใน package.json ซึ่งต้องกรอกเพียงสองรายการ: name และ version คุณลักษณะทั้งสองนี้สร้างตัวระบุเฉพาะของโมดูล npm
name ชื่อโมดูล เมื่อตั้งชื่อคุณต้องปฏิบัติตามข้อกำหนดและคำแนะนำอย่างเป็นทางการ:
ชื่อแพ็คเกจจะกลายเป็นพารามิเตอร์ใน url ของโมดูล บรรทัดคำสั่ง หรือชื่อโฟลเดอร์ใด ๆ ที่ไม่ใช่ url ที่ปลอดภัย อยู่ในชื่อแพ็คเกจ ไม่สามารถใช้ได้ คุณสามารถใช้แพ็คเกจ validate-npm-package-name เพื่อตรวจสอบว่าชื่อแพ็คเกจนั้นถูกกฎหมายหรือไม่
ชื่อแพ็คเกจความหมายสามารถช่วยให้นักพัฒนาค้นหาแพ็คเกจที่ต้องการได้เร็วขึ้น และหลีกเลี่ยงการได้รับแพ็คเกจที่ไม่ถูกต้องโดยไม่ตั้งใจ
หากมีสัญลักษณ์บางตัวในชื่อแพ็คเกจ จะต้องไม่ซ้ำสัญลักษณ์กับชื่อแพ็คเกจที่มีอยู่หลังจากลบออกแล้ว
ตัวอย่างเช่น เนื่องจากมี react-native อยู่แล้ว ดังนั้น react.native และ reactnative จึงไม่สามารถสร้างใหม่ได้
ตัวอย่างเช่น: ชื่อผู้ใช้คือ conard จากนั้นขอบเขตคือ @conard และแพ็คเกจที่เผยแพร่อาจเป็น @conard/react
name เป็นตัวระบุเฉพาะของแพ็กเกจ และต้องไม่ซ้ำกับชื่อแพ็กเกจอื่น เราสามารถดำเนินการ npm view packageName เพื่อดูว่าแพ็กเกจถูกครอบครองหรือไม่ และเราสามารถดูข้อมูลพื้นฐานบางอย่างเกี่ยวกับแพ็คเกจนั้นได้:
หากไม่เคยใช้ชื่อแพ็คเกจ ข้อผิดพลาด 404 จะถูกส่งออกไป:
นอกจากนี้คุณยังสามารถไปที่ https://www.npmjs.com/ เพื่อดูข้อมูลแพ็คเกจโดยละเอียดเพิ่มเติม
{
"description": "ภาษาการออกแบบ UI ระดับองค์กรและการใช้งานส่วนประกอบ React",
"คำสำคัญ": [
"มด",
"ส่วนประกอบ",
"ส่วนประกอบ",
"ออกแบบ",
"กรอบ",
"ส่วนหน้า",
"ตอบสนอง",
"ส่วนประกอบปฏิกิริยา",
"อุ้ย"
-
} description ใช้เพื่อเพิ่มข้อมูลคำอธิบายโมดูลเพื่ออำนวยความสะดวกให้ผู้อื่นเข้าใจโมดูลของคุณ
keywords ใช้เพื่อเพิ่มคำหลักในโมดูลของคุณ
แน่นอนว่าพวกมันยังมีบทบาทสำคัญมากเช่นกัน ซึ่งก็คือการอำนวยความสะดวกในการดึงข้อมูลโมดูล เมื่อคุณใช้ npm search เพื่อดึงข้อมูลโมดูล โมดูลจะจับคู่ description และ keywords การเขียน description และ keywords ที่ดีจะช่วยให้โมดูลของคุณได้รับการเปิดเผยที่แม่นยำยิ่งขึ้น:
ในการอธิบายนักพัฒนา: author และ contributors author หมายถึงผู้เขียนหลักของแพ็คเกจ และ author หนึ่งคนหมายถึงบุคคลหนึ่งคน
ข้อมูล
contributors contributors สอดคล้องกับผู้มีส่วนร่วมหลายคน ค่าเป็นอาร์เรย์
"ชื่อ" : "โคนาร์ดลี",
"อีเมล" : "[email protected]",
"url" : "https://github.com/ConardLi"
} {
"homepage": "http://ant.design/",
"ข้อบกพร่อง": {
"url": "https://github.com/ant-design/ant-design/issues"
-
"พื้นที่เก็บข้อมูล": {
"type": "git",
"url": "https://github.com/ant-design/ant-design"
-
} homepage ใช้เพื่อระบุหน้าแรกของโมดูลนี้
repository ใช้เพื่อระบุที่เก็บโค้ดของโมดูล
bugs ระบุที่อยู่หรืออีเมลที่ผู้ที่มีคำถามเกี่ยวกับโมดูลของคุณสามารถไปที่นี่เพื่อถามคำถาม
โครงการของเราอาจขึ้นอยู่กับแพ็คเกจการพึ่งพาภายนอกตั้งแต่หนึ่งแพ็คเกจขึ้นไป เรากำหนดค่าแพ็คเกจเหล่านั้นภายใต้แอตทริบิวต์ต่อไปนี้: dependencies、devDependencies、peerDependencies、bundledDependencies、optionalDependencies
ก่อนที่จะแนะนำการกำหนดค่าการขึ้นต่อกันหลายรายการ ขั้นแรกเรามาดูกฎการกำหนดค่าการขึ้นต่อกันกันก่อน การกำหนดค่าแพ็คเกจการขึ้นต่อกันที่คุณเห็นอาจเป็นดังนี้:
"การขึ้นต่อกัน": {
"antd": "การออกแบบมด/การออกแบบมด#4.0.0-alpha.8",
"axios": "^1.2.0",
"test-js": "ไฟล์:../test",
"test2-js": "http://cdn.com/test2-js.tar.gz",
"core-js": "^1.1.5",
} การกำหนดค่าการพึ่งพาเป็นไปตามกฎการกำหนดค่าต่อไปนี้:
依赖包名称:VERSION VERSION คือการกำหนดค่าหมายเลขเวอร์ชันที่เป็นไปตามข้อกำหนด SemVer เมื่อ npm install มันจะไปที่เซิร์ฟเวอร์ npm เพื่อดาวน์โหลดแพ็คเกจที่ตรงตามช่วงเวอร์ชันที่ระบุ依赖包名称:DWONLOAD_URL DWONLOAD_URL คือที่อยู่แพ็คเกจบีบอัด tarball ที่ดาวน์โหลดได้ เมื่อติดตั้งโมดูลแล้ว . .tar นี้จะถูกดาวน์โหลดและติดตั้งในเครื่อง依赖包名称:LOCAL_PATH LOCAL_PATH คือพาธของแพ็กเกจการขึ้นต่อกันในเครื่อง เช่น file:../pacakges/pkgName เหมาะสำหรับคุณที่จะทดสอบแพ็คเกจ npm ในเครื่อง ไม่ควรใช้วิธีนี้ทางออนไลน์依赖包名称:GITHUB_URL GITHUB_URL เป็นวิธีการเขียน username/modulename ของ github เช่น: ant-design/ant-design คุณยังสามารถระบุ tag และ commit id ในภายหลังได้依赖包名称:GIT_URL GIT_URL คือ git url ของฐานรหัสโคลนปกติของเรา ซึ่งเป็นไปตามรูปแบบต่อไปนี้:<protocol>://[<user>[:<password>]@]<hostname>[:<port>] [: ][/]<path>[#<commit-ish> |. #semver:<semver>]
protocal สามารถอยู่ในรูปแบบต่อไปนี้:
git://github.com/user/project.git#commit-ishgit+ssh://user@hostname:project.git#commit-ishgit+ssh://user@hostname/project.git#commit-ishgit+http://user@hostname/project/blah.git#commit-ishgit+https://user@hostname/project/blah.git#commit-ishdependencies โมดูลที่โปรเจ็กต์ต้องพึ่งพา สามารถกำหนดค่าทั้งสภาพแวดล้อมการพัฒนาและโมดูลการพึ่งพาสภาพแวดล้อมการใช้งานจริงได้ที่นี่ เช่น
" การอ้างอิง": {
"lodash": "^4.17.13",
"ช่วงเวลา": "^2.24.0",
} มีแพ็คเกจบางอย่างใน ที่คุณสามารถใช้ในสภาพแวดล้อมการพัฒนาเท่านั้น เช่น eslint สำหรับตรวจสอบข้อกำหนดโค้ดและ jest สำหรับการทดสอบ เมื่อผู้ใช้ใช้แพ็คเกจของคุณ มันสามารถทำงานได้ตามปกติแม้ว่าจะไม่ได้ติดตั้งการขึ้นต่อกันเหล่านี้ก็ตาม จะใช้เวลาและทรัพยากรมากขึ้น ดังนั้นคุณสามารถเพิ่มการขึ้นต่อกันเหล่านี้ให้กับ devDependencies ได้ การขึ้นต่อกันเหล่านี้จะยังคงได้รับการติดตั้งและจัดการเมื่อคุณดำเนินการ npm install ในเครื่อง แต่จะไม่ถูกติดตั้งลงในสภาพแวดล้อมการใช้งานจริง:
"devDependencies" : {
"ตลก": "^24.3.1",
"eslint": "^6.1.0",
} peerDependencies ใช้เพื่อระบุเวอร์ชันที่โมดูลที่คุณกำลังพัฒนานั้นขึ้นอยู่กับและความเข้ากันได้ของเวอร์ชันแพ็คเกจที่ขึ้นอยู่กับการติดตั้งโดยผู้ใช้
ข้อความข้างต้นอาจเป็นนามธรรมเกินไป มาดูตัวอย่าง package.json ของ ant-design ant-design กัน:
"peerDependencies": {
"โต้ตอบ": ">=16.0.0",
"react-dom": ">=16.0.0"
} เมื่อคุณกำลังพัฒนาระบบและใช้ ant-design คุณจะต้องพึ่งพา React อย่างแน่นอน ในเวลาเดียวกัน ant-design ยังต้องพึ่งพา React เวอร์ชัน React ที่ต้องการเพื่อรักษาการทำงานที่เสถียรคือ 16.0.0 และเวอร์ชัน React ที่คุณใช้เมื่อพัฒนาคือ 15.x :
ในขณะนี้ ant-design จำเป็นต้องใช้ React และนำเข้า:
import * as React from 'react'; import * เป็น ReactDOM จาก 'react-dom'
สิ่งที่คุณได้รับในขณะนี้คือสภาพแวดล้อมของโฮสต์ ซึ่งเป็นเวอร์ชัน React ในสภาพแวดล้อมของคุณ ซึ่งอาจทำให้เกิดปัญหาบางอย่างได้ ใน npm2 การระบุ peerDependencies ด้านบนจะหมายถึงการบังคับให้สภาพแวดล้อมโฮสต์ติดตั้งเวอร์ชันของ react@>=16.0.0和react-dom@>=16.0.0
ในอนาคต npm3 จะไม่จำเป็นต้องมีแพ็คเกจการพึ่งพาที่ระบุโดย peerDependencies อีกต่อไป ในทางกลับกัน npm3 จะตรวจสอบว่าการติดตั้งถูกต้องหรือไม่หลังจากการติดตั้งเสร็จสมบูรณ์ หากไม่ถูกต้อง จะมีการพิมพ์คำเตือนไปยังผู้ใช้ .
"การอ้างอิง": {
"ตอบสนอง": "15.6.0",
"antd": "^3.22.0"
ตัวอย่าง เช่น
ฉันใช้ antd เวอร์ชันล่าสุดในโปรเจ็กต์ จากนั้นจึงใช้ react เวอร์ชัน 15.6.0 คำเตือนต่อไปนี้จะได้รับเมื่อติดตั้งการขึ้นต่อกัน:
ในบางสถานการณ์ แพ็คเกจที่ต้องพึ่งพาอาจไม่มีการพึ่งพาที่แข็งแกร่ง ฟังก์ชันของแพ็คเกจที่ต้องพึ่งพานี้สามารถแจกจ่ายได้ เมื่อไม่สามารถรับแพ็คเกจที่ต้องพึ่งพานี้ได้ คุณต้องการให้ npm install ทำงานต่อไปโดยไม่ทำให้เกิดความล้มเหลว คุณสามารถวางการพึ่งพานี้ได้ optionalDependencies โปรดทราบว่าการกำหนดค่าใน optionalDependencies จะแทนที่ dependencies ดังนั้นจึงจำเป็นต้องกำหนดค่าในที่เดียวเท่านั้น
แน่นอน เมื่ออ้างอิงการอ้างอิงที่ติดตั้งใน optionalDependencies จะต้องจัดการข้อยกเว้น มิฉะนั้นข้อผิดพลาดจะถูกรายงานเมื่อไม่สามารถรับโมดูลได้
แตกต่างจากค่าข้างต้น ค่าของ bundledDependencies คืออาร์เรย์ บางโมดูลสามารถระบุได้ในอาร์เรย์
"bundledDependencies": ["แพ็คเกจ 1", "แพ็คเกจ 2"]
{
"ใบอนุญาต": "เอ็มไอที"
} ช่อง license ใช้เพื่อระบุข้อตกลงโอเพ่นซอร์สของซอฟต์แวร์ ข้อตกลงโอเพ่นซอร์สให้รายละเอียดเกี่ยวกับสิทธิ์ที่ผู้อื่นมีหลังจากได้รับรหัสของคุณ การดำเนินการใดที่พวกเขาสามารถทำได้กับโค้ดของคุณ และการดำเนินการใดที่ไม่ได้รับอนุญาต ข้อตกลงเดียวกันมีหลายรูปแบบ ข้อตกลงที่หลวมเกินไปจะทำให้ผู้เขียนสูญเสียสิทธิ์ในการทำงานจำนวนมาก ในขณะที่ข้อตกลงที่เข้มงวดเกินไปจะไม่สะดวกสำหรับผู้ใช้ในการเผยแพร่ผลงาน ผู้เขียนโอเพ่นซอร์สจะต้องพิจารณาว่าพวกเขาต้องการรักษาสิทธิ์ใดบ้าง และต้องการคลายข้อจำกัดใด
ข้อตกลงซอฟต์แวร์สามารถแบ่งออกเป็นสองประเภท: โอเพ่นซอร์สและเชิงพาณิชย์ สำหรับข้อตกลงทางการค้าหรือที่เรียกว่าคำชี้แจงทางกฎหมายและข้อตกลงใบอนุญาต แต่ละซอฟต์แวร์จะมีชุดข้อความของตัวเองซึ่งเขียนโดยผู้เขียนซอฟต์แวร์หรือทนายความเฉพาะทาง ไม่จำเป็นต้องดำเนินการด้วยตนเอง ใช้เวลาและความพยายามในการเขียนข้อตกลงใบอนุญาตที่ยาวนาน การเลือกใบอนุญาตโอเพ่นซอร์สที่เผยแพร่อย่างกว้างขวางเป็นทางเลือกที่ดี
ต่อไปนี้เป็นโปรโตคอลโอเพ่นซอร์สกระแสหลักหลายประการ:
MIT : ตราบใดที่ผู้ใช้รวมประกาศลิขสิทธิ์และประกาศใบอนุญาตไว้ในสำเนาของโครงการ พวกเขาสามารถทำทุกอย่างที่ต้องการด้วยโค้ดของคุณโดยไม่ต้องรับผิดชอบในส่วนของคุณApache : คล้ายกับ MIT แต่ยังรวมคำศัพท์ที่เกี่ยวข้องกับการออกใบอนุญาตสิทธิบัตรที่จัดทำโดยผู้มีส่วนร่วมในผู้ใช้GPL : ผู้ใช้ที่แก้ไขรหัสโครงการจะต้องเผยแพร่การแก้ไขที่เกี่ยวข้องเมื่อแจกจ่ายซอร์สโค้ดหรือรหัสไบนารี่อีกครั้งหากคุณมีข้อกำหนดโดยละเอียดเพิ่มเติมสำหรับข้อตกลงโอเพ่นซอร์ส คุณสามารถไปที่ choosealicense.com/ เพื่อดูคำอธิบายโดยละเอียดเพิ่มเติมของข้อตกลงโอเพ่นซอร์ส
{
"main": "lib/index.js",
} คุณลักษณะ main สามารถระบุไฟล์รายการหลักของโปรแกรมได้ ตัวอย่างเช่น รายการโมดูล lib/index.js ที่ระบุโดย antd ข้างต้น เมื่อเราแนะนำ antd ในโค้ด: import { notification } from 'antd'; สิ่งที่แนะนำคือ lib/index.js
เมื่อโมดูลของคุณเป็นเครื่องมือบรรทัดคำสั่ง คุณต้องระบุรายการสำหรับเครื่องมือบรรทัดคำสั่ง นั่นคือ ระบุความสอดคล้องระหว่างชื่อคำสั่งของคุณกับไฟล์ที่ระบุในเครื่อง หากติดตั้งแบบโกลบอล npm จะใช้ลิงก์สัญลักษณ์เพื่อลิงก์ไฟล์ปฏิบัติการกับ /usr/local/bin หากติดตั้งแบบโลคัล ไฟล์นั้นจะลิงก์ไปยัง ./node_modules/.bin/
-
"ถังขยะ": {
"conard": "./bin/index.js"
-
} ตัวอย่างเช่น การกำหนดค่าข้างต้น: เมื่อแพ็คเกจของคุณถูกติดตั้งทั่วโลก: npm จะสร้างซอฟต์ลิงก์ชื่อ conard ภายใต้ /usr/local/bin โดยชี้ไปที่ "./bin/index.js" . ในเวลานี้ หากคุณดำเนินการ conard บนบรรทัดคำสั่ง ไฟล์ js ที่เชื่อมโยงจะถูกเรียก
ฉันจะไม่ลงรายละเอียดมากเกินไปที่นี่ เนื้อหาเพิ่มเติมจะมีการอธิบายโดยละเอียดในบทความเครื่องมือบรรทัดคำสั่งถัดไปของฉัน
{
"ไฟล์": [
"ระยะทาง",
"ลิบ",
"เอส"
-
} แอตทริบิวต์ files ใช้เพื่ออธิบายรายการไฟล์ที่คุณพุชไปยังเซิร์ฟเวอร์ npm หลังจาก npm publish หากคุณระบุโฟลเดอร์ เนื้อหาทั้งหมดในโฟลเดอร์จะถูกรวมไว้ด้วย เราจะเห็นว่าแพ็คเกจที่ดาวน์โหลดมีโครงสร้างไดเร็กทอรีดังต่อไปนี้:
นอกจากนี้ คุณยังสามารถกำหนดค่าไฟล์
.npmignoreเพื่อยกเว้นบางไฟล์เพื่อป้องกันไม่ให้ไฟล์ขยะจำนวนมากถูกพุชไปที่npmกฎจะเหมือนกับ.gitignoreที่คุณใช้ ไฟล์.gitignoreยังสามารถทำหน้าที่เป็นไฟล์.npmignoreได้อีกด้วย
man สั่ง man เป็นคำสั่งช่วยเหลือภายใต้ Linux คุณสามารถดูวิธีใช้คำสั่ง วิธีใช้ไฟล์การกำหนดค่า วิธีใช้การเขียนโปรแกรม และข้อมูลอื่น ๆ ใน Linux ได้
หากโมดูล node.js ของคุณเป็นเครื่องมือบรรทัดคำสั่งส่วนกลาง คุณสามารถระบุที่อยู่เอกสารที่ค้นหาโดยคำสั่ง man ผ่านแอตทริบิวต์ man ใน package.json
ไฟล์ man ต้องลงท้ายด้วยตัวเลข หรือหากบีบอัด .gz ตัวเลขระบุว่าไฟล์จะถูกติดตั้งในส่วนใดของ man หากชื่อไฟล์ man ไม่ได้ขึ้นต้นด้วยชื่อโมดูล ชื่อโมดูลจะถูกนำหน้าระหว่างการติดตั้ง
ตัวอย่างเช่น การกำหนดค่าต่อไปนี้:
{
"ผู้ชาย" : [
"/Users/isaacs/dev/npm/cli/man/man1/npm-access.1",
"/Users/isaacs/dev/npm/cli/man/man1/npm-audit.1"
-
} ป้อน man npm-audit บนบรรทัดคำสั่ง:
โมดูล node.js ถูกนำไปใช้ตามข้อกำหนดคุณสมบัติโมดูลาร์ CommonJS เพื่อให้สอดคล้องกับข้อกำหนด CommonJS อย่างเคร่งครัด นอกเหนือจากไฟล์คำอธิบายแพ็กเกจ package.json แล้ว ไดเร็กทอรีโมดูลยังจำเป็นต้องมีไดเร็กทอรีต่อไปนี้:
bin : โดยที่ ไฟล์ไบนารีที่ปฏิบัติการได้จะถูกจัดเก็บ Directorylib : Directory สำหรับจัดเก็บโค้ด jsdoc : Directory สำหรับจัดเก็บเอกสารtest : Directory สำหรับจัดเก็บโค้ดกรณีทดสอบหน่วยในไดเร็กทอรีโมดูล คุณอาจไม่ปฏิบัติตามโครงสร้างด้านบนอย่างเคร่งครัดเพื่อจัดระเบียบหรือตั้งชื่อ คุณสามารถระบุ directories ในคุณสมบัติ package.json เพื่อระบุว่าโครงสร้างไดเร็กทอรีของคุณสอดคล้องกับโครงสร้าง Canonical ข้างต้นอย่างไร นอกเหนือจากนี้ แอตทริบิวต์ directories ยังไม่มีแอปพลิเคชันอื่นในขณะนี้
-
"ไดเรกทอรี": {
"lib": "src/lib/",
"bin": "src/bin/",
"man": "src/man/",
"doc": "src/doc/",
"ตัวอย่าง": "src/ตัวอย่าง/"
-
อย่างไรก็ตาม เอกสารอย่างเป็นทางการระบุว่าแม้ว่าแอตทริบิวต์นี้จะไม่มีบทบาทสำคัญในปัจจุบัน แต่เทคนิคบางอย่างอาจได้รับการพัฒนาในอนาคต ตัวอย่างเช่น ไฟล์มาร์กดาวน์ที่จัดเก็บไว้ใน doc และไฟล์ตัวอย่างที่จัดเก็บไว้ในตัวอย่างอาจแสดงในลักษณะที่เป็นมิตร
{
"สคริปต์": {
"test": "jest --config .jest.js --no-cache",
"dist": "antd-tools ทำงาน dist",
"compile": "antd-tools เรียกใช้การคอมไพล์",
"build": "การรัน npm คอมไพล์ && npm run dist"
-
} scripts ใช้เพื่อกำหนดค่าตัวย่อของคำสั่งสคริปต์บางคำสั่ง สามารถใช้ npm run command ร่วมกันได้ หากเป็นคีย์เวิร์ด npm ก็สามารถเรียกได้โดยตรง ตัวอย่างเช่น การกำหนดค่าข้างต้นระบุคำสั่งต่อไปนี้: npm run test , npm run dist , npm run compile , npm run build
ฟิลด์ config ใช้เพื่อกำหนดค่าตัวแปรสภาพแวดล้อมที่ใช้ในสคริปต์ ตัวอย่างเช่น การกำหนดค่าต่อไปนี้สามารถรับได้โดยใช้ process.env.npm_package_config_port ในสคริปต์
-
"config" : { "พอร์ต" : "8080" }
} หากโมดูล node.js ของคุณใช้เพื่อติดตั้งเครื่องมือบรรทัดคำสั่งส่วนกลางเป็นหลัก ค่านี้จะถูกตั้งค่าเป็น true และผู้ใช้จะได้รับคำเตือนเมื่อติดตั้งโมดูลในเครื่อง การกำหนดค่านี้จะไม่ป้องกันผู้ใช้จากการติดตั้ง แต่จะแจ้งให้ผู้ใช้ป้องกันการใช้งานที่ไม่ถูกต้องซึ่งอาจทำให้เกิดปัญหาบางอย่าง
หากตั้งค่าแอตทริบิวต์ private เป็น true npm จะปฏิเสธที่จะเผยแพร่ นี่เป็นการป้องกันไม่ให้โมดูลส่วนตัวถูกเผยแพร่โดยไม่ได้ตั้งใจ
"publishConfig": {
"รีจิสทรี": "https://registry.npmjs.org/"
} ซึ่งเป็นการกำหนดค่าที่มีรายละเอียดมากขึ้นเมื่อเผยแพร่โมดูล เช่น คุณสามารถกำหนดค่าให้เผยแพร่เฉพาะ tag บางแท็ก กำหนดค่าแหล่งที่มา npm ส่วนตัวที่จะเผยแพร่ไป
การกำหนดค่าโดยละเอียดเพิ่มเติม โปรดดูที่
หากคุณพัฒนาโมดูลที่สามารถทำงานได้ภายใต้ระบบ darwin เท่านั้น คุณต้องแน่ใจว่าผู้ใช้ windows จะไม่ติดตั้งโมดูลของคุณเพื่อหลีกเลี่ยงข้อผิดพลาดที่ไม่จำเป็น
การใช้แอตทริบิวต์ os สามารถช่วยให้คุณบรรลุข้อกำหนดข้างต้นได้ คุณสามารถระบุได้ว่าโมดูลของคุณสามารถติดตั้งได้บนบางระบบเท่านั้น หรือระบุบัญชีดำของระบบที่ไม่สามารถติดตั้งได้:
"os" : [ "darwin", "linux" ] "os" : [ "!win32" ]
ตัวอย่างเช่น ฉันกำหนดโมดูลทดสอบให้กับบัญชีดำของระบบ: "os" : [ "!darwin" ] เมื่อฉันติดตั้งภายใต้ระบบนี้ ข้อผิดพลาดต่อไปนี้จะปรากฏขึ้น:
ในสภาพแวดล้อมของโหนด คุณสามารถใช้ process.platform เพื่อกำหนดระบบปฏิบัติการได้
คล้ายกับ os ข้างต้น เราสามารถใช้แอตทริบิวต์ cpu เพื่อจำกัดสภาพแวดล้อมการติดตั้งของผู้ใช้ได้แม่นยำยิ่งขึ้น:
"cpu" : [ "x64", "ia32" ] "cpu" : [ "!arm", "!mips" ]
ในสภาพแวดล้อมของโหนด คุณสามารถใช้ process.arch เพื่อกำหนดสถาปัตยกรรม CPU ได้
ความสำเร็จของ Nodejs ไม่สามารถแยกออกจากระบบการจัดการการพึ่งพาที่ยอดเยี่ยมของ npm ก่อนที่จะแนะนำระบบการขึ้นต่อกันทั้งหมด คุณต้องเข้าใจว่า npm จัดการเวอร์ชันของแพ็คเกจที่ต้องพึ่งพาอย่างไร บทนี้จะแนะนำข้อมูลจำเพาะเวอร์ชันรีลีสของ npm包วิธีจัดการเวอร์ชันของแพ็คเกจที่ต้องพึ่งพาต่างๆ และแนวทางปฏิบัติที่ดีที่สุดบางประการเกี่ยวกับเวอร์ชันแพ็คเกจ
คุณสามารถเรียกใช้ npm view package version เพื่อดูเวอร์ชันล่าสุดของ package
ดำเนินการเวอร์ชัน npm view conard versions เพื่อดูเวอร์ชันที่เผยแพร่ทั้งหมดของ package บนเซิร์ฟเวอร์ npm
ดำเนินการ npm ls เพื่อดูข้อมูลเวอร์ชันของแพ็กเกจทั้งหมดในแผนผังการพึ่งพาคลังสินค้าปัจจุบัน
เวอร์ชันของโมดูลใน npm包ต้องเป็นไปตามข้อกำหนด SemVer - กฎการแสดงหมายเลขเวอร์ชันแบบรวมที่เป็นแนวทางซึ่งร่างโดย Github จริงๆ แล้วมันเป็นคำย่อของ Semantic Version
เว็บไซต์อย่างเป็นทางการของข้อกำหนด SemVer: https://semver.org/
มาตรฐาน หมายเลขเวอร์ชันมาตรฐานของข้อกำหนด SemVer ใช้รูปแบบของ XYZ โดยที่ X, Y และ Z เป็นจำนวนเต็มที่ไม่เป็นลบ และมีช่องว่างภายในเป็นศูนย์ที่ด้านหน้าตัวเลขคือ ต้องห้าม X คือหมายเลขเวอร์ชันหลัก Y คือหมายเลขเวอร์ชันรอง และ Z คือหมายเลขเวอร์ชันแก้ไข แต่ละองค์ประกอบจะต้องเพิ่มขึ้นเป็นตัวเลข
major ): เมื่อคุณทำการแก้ไข API ที่เข้ากันไม่ได้minor ): เมื่อคุณสร้างฟังก์ชันการทำงานที่เข้ากันได้แบบย้อนหลังpatch ): เมื่อคุณทำการแก้ไขปัญหาความเข้ากันได้แบบย้อนหลังตัวอย่างเช่น: 1.9.1 -> 1.10.0 -> 1.11.0
เมื่อเวอร์ชันมีการเปลี่ยนแปลงที่สำคัญ ไม่เสถียร และอาจไม่ตรงตามข้อกำหนดด้านความเข้ากันได้ที่คาดไว้ คุณอาจต้องการเผยแพร่เวอร์ชันล่วงหน้าก่อน
คุณสามารถเพิ่มหมายเลขเวอร์ชันนำหน้าได้ที่ส่วนท้ายของ "หมายเลขเวอร์ชันหลัก หมายเลขเวอร์ชันรอง หมายเลขการแก้ไข" ขั้นแรกให้เพิ่มหมายเลขการเชื่อมต่อ จากนั้นจึงเพิ่มชุดตัวระบุและข้อมูลการคอมไพล์เวอร์ชันโดยคั่นด้วยจุด
alpha ):beta ):rc : Release candiateมาดูเวอร์ชันย้อนหลังของ React กัน:
จะเห็นได้ว่าเวอร์ชันดังกล่าวได้รับการเผยแพร่อย่างเคร่งครัดตามข้อกำหนด SemVer :
主版本号.次版本号.修订号อย่าง16.8.0 -> 16.8.1 -> 16.8.2alpha , beta , rc และเวอร์ชันขั้นสูงอื่นๆหลังจากแก้ไขฟังก์ชันบางอย่างของแพ็คเกจ npm แล้ว ก็มักจะจำเป็นต้องปล่อย a เวอร์ชันใหม่ วิธีการปกติของเราคือการแก้ไข package.json ให้เป็นเวอร์ชันที่ระบุโดยตรง หากการดำเนินการไม่ถูกต้อง อาจทำให้เกิดความสับสนได้ง่ายในหมายเลขเวอร์ชัน เราสามารถใช้คำสั่งที่สอดคล้องกับข้อกำหนด Semver เพื่อดำเนินการนี้ให้เสร็จสิ้น:
npm version patch : อัปเกรดหมายเลขการแก้ไขnpm version minor : อัปเกรดหมายเลขเวอร์ชันรองnpm version major : อัปเกรดเวอร์ชันหลักหมายเลขในการพัฒนาเป็นสิ่งที่ขาดไม่ได้อย่างแน่นอนสำหรับการทำงานของหมายเลขเวอร์ชันบางเวอร์ชัน หากหมายเลขเวอร์ชันเหล่านี้สอดคล้องกับข้อกำหนด SemVer เราสามารถใช้แพ็คเกจ npm semver สำหรับเวอร์ชันปฏิบัติการเพื่อช่วยเราได้ เปรียบเทียบขนาดเวอร์ชัน แยกข้อมูลเวอร์ชัน และการดำเนินการอื่นๆ
Npm ยังใช้เครื่องมือนี้เพื่อจัดการงานการกำหนดเวอร์ชันด้วย
การติดตั้ง npm semver
semver.gt ('1.2.3', '9.8.7') // false
semver.lt('1.2.3', '9.8.7') // true semver.valid('1.2.3') // '1.2.3'
semver.valid('abc') // null semver.valid(semver.coerce('v2')) // '2.0.0'
semver.valid(semver.coerce('42.6.7.9.3-alpha')) // semver.clean(' =v1.2.3 ') // '1.2.3'
semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // จริง
semver.minVersion('>=1.0.0') // '1.0.0' การใช้งานข้างต้นคือการใช้งาน semver ที่พบบ่อยที่สุด สำหรับรายละเอียดเพิ่มเติม โปรดดูเอกสารประกอบ semver: https://github.com/npm/node -semver
เรามักจะเห็นวิธีการต่างๆ ในการเขียนการขึ้นต่อกันต่างๆ ใน package.json :
"dependencies": {
"สัญญาณ": "1.4.0",
"figlet": "*",
"ตอบสนอง": "16.x",
"ตาราง": "~5.4.6",
"yargs": "^14.0.0"
} สามข้อแรกเข้าใจง่าย:
"signale": "1.4.0" : หมายเลขเวอร์ชันคงที่"figlet": "*" : Any version ( >=0.0.0 )"react": "16.x" : Match main Version ( >=16.0.0 <17.0.0 )"react": "16.3.x" : จับคู่เวอร์ชันหลักและเวอร์ชันรอง ( >=16.3.0 <16.4.0 )มาดูสองอันสุดท้ายกัน หมายเลขเวอร์ชัน สัญลักษณ์ ~ และ ^ อ้างอิงถึง:
~ : เมื่อได้รับเวอร์ชันใหม่เมื่อติดตั้งการขึ้นต่อกัน ให้ติดตั้งเวอร์ชันล่าสุดของ z ใน xyz นั่นคือ แม้ว่าหมายเลขเวอร์ชันหลักและหมายเลขเวอร์ชันรองจะไม่เปลี่ยนแปลง แต่หมายเลขเวอร์ชันล่าสุดจะยังคงอยู่^ : เมื่อได้รับเวอร์ชันใหม่เมื่อทำการติดตั้งการขึ้นต่อกัน ทั้ง y และ z ใน xyz ที่ติดตั้งจะเป็นเวอร์ชันล่าสุด นั่นคือ แม้จะรักษาหมายเลขเวอร์ชันหลักไว้ไม่เปลี่ยนแปลง แต่ให้เก็บหมายเลขเวอร์ชันรองและหมายเลขการแก้ไขให้เป็นเวอร์ชันล่าสุดการขึ้นต่อกันที่พบบ่อยที่สุดในไฟล์ package.json ควรเป็น "yargs": "^14.0.0" เนื่องจากเมื่อเราใช้ npm install package เพื่อติดตั้งแพ็คเกจ npm จะติดตั้งเวอร์ชันล่าสุดตามค่าเริ่มต้น จากนั้นจึงติดตั้งในส่วนเพิ่ม เครื่องหมาย ^ หน้าหมายเลขเวอร์ชัน
โปรดทราบว่าเมื่อหมายเลขเวอร์ชันหลักคือ 0 จะถือว่าเป็นเวอร์ชันที่ไม่เสถียร สถานการณ์แตกต่างจากด้านบน:
0 : ^0.0.z และ ~0.0.z ทั้งคู่ ถือเป็นเวอร์ชันที่แก้ไขแล้ว จะไม่มีการเปลี่ยนแปลงเกิดขึ้นเมื่อติดตั้งการขึ้นต่อกัน0 : ^0.yz ทำงานเหมือนกับ ~0.yz เฉพาะหมายเลขการแก้ไขเท่านั้นที่จะเก็บไว้เป็นเวอร์ชันล่าสุด2.5หมายเลขเวอร์ชัน 1.0.0 ใช้เพื่อกำหนด API สาธารณะ เมื่อซอฟต์แวร์ของคุณออกสู่สภาพแวดล้อมอย่างเป็นทางการ หรือมี API ที่เสถียร คุณสามารถเผยแพร่เวอร์ชัน 1.0.0 ได้ ดังนั้น เมื่อคุณตัดสินใจที่จะเผยแพร่เวอร์ชันอย่างเป็นทางการของแพ็คเกจ npm สู่โลกภายนอก ให้ทำเครื่องหมายเวอร์ชันเป็น 1.0.0
ในการพัฒนาจริง ปัญหาแปลก ๆ มักเกิดขึ้นเนื่องจากความไม่สอดคล้องกันในการขึ้นต่อกันต่างๆ หรือในบางสถานการณ์ เราไม่ต้องการให้การอัปเดตการขึ้นต่อกัน ขอแนะนำให้ใช้ package-lock.json ในระหว่างการพัฒนา
การล็อกเวอร์ชันอ้างอิงหมายความว่าเว้นแต่เราจะอัปเดตด้วยตนเอง เวอร์ชันที่แก้ไขจะถูกติดตั้งทุกครั้งที่เราติดตั้งการขึ้นต่อกัน ตรวจสอบให้แน่ใจว่าทั้งทีมใช้การอ้างอิงที่มีหมายเลขเวอร์ชันที่สอดคล้องกัน
แต่ละครั้งที่คุณติดตั้งเวอร์ชันคงที่ ไม่จำเป็นต้องคำนวณช่วงเวอร์ชันการขึ้นต่อกัน ซึ่งสามารถเร่งเวลาการติดตั้งการขึ้นต่อกันในสถานการณ์ส่วนใหญ่ได้อย่างมาก
เมื่อใช้ package-lock.json ตรวจสอบให้แน่ใจว่าเวอร์ชัน npm นั้นสูงกว่า 5.6 เนื่องจากระหว่าง 5.0 ถึง 5.6 ตรรกะการประมวลผลของ package-lock.json ได้รับการอัปเดตหลายครั้ง และตรรกะหลังการประมวลผลของเวอร์ชัน 5.6 จะค่อยๆ เสถียร
เราจะวิเคราะห์โครงสร้างโดยละเอียดของ package-lock.json ในบทต่อๆ ไป
จุดประสงค์ของเราใน
ในสถานการณ์การพัฒนาจริง แม้ว่าเราจะไม่จำเป็นต้องติดตั้งเวอร์ชันใหม่ทุกครั้ง แต่เรายังคงจำเป็นต้องอัปเกรดเวอร์ชันการพึ่งพาอย่างสม่ำเสมอ เพื่อให้เราสามารถเพลิดเพลินกับการแก้ไขปัญหา การปรับปรุงประสิทธิภาพ และการอัปเดตคุณลักษณะใหม่ที่เกิดจากการอัพเกรดแพ็คเกจการพึ่งพา
การใช้ npm outdated สามารถช่วยเราแสดงรายการการขึ้นต่อกันที่ไม่ได้รับการอัปเกรดเป็นเวอร์ชันล่าสุด:
และดำเนินการ npm update อัปเกรดการอ้างอิงสีแดงทั้งหมด
1.0.0主版本号.次版本号.修订号alpha、beta、rc เวอร์ชันขั้นสูงอื่น ๆ ก่อนnpm ทั้งหมดที่พัฒนาโดยสมาชิกในทีม ในขณะนี้ ขอแนะนำให้เปลี่ยนคำนำหน้าเวอร์ชัน ~ การขึ้นต่อกันของโปรเจ็กต์หลักจะต้องอัปเกรดทุกครั้งที่อัปเดตการขึ้นต่อกันย่อยซึ่งยุ่งยากมาก หากการขึ้นต่อกันย่อยนั้นเชื่อถือได้อย่างสมบูรณ์ ให้เปิดโดยตรง ^ อัปเกรดเป็นเวอร์ชันล่าสุดทุกครั้งdocker และการขึ้นต่อกันย่อยยังคงได้รับการพัฒนาและอัปเกรดในเครื่อง ก่อนที่จะเผยแพร่เวอร์ชัน docker เวอร์ชันการขึ้นต่อกันทั้งหมดจะต้องถูกล็อคเพื่อให้แน่ใจว่าจะไม่มีปัญหาออนไลน์หลังจากที่การขึ้นต่อกันในเครื่องนั้น ปล่อยแล้ว.npm สูงกว่า 5.6 และตรวจสอบให้แน่ใจว่าไฟล์ package-lock.json ถูกเปิดใช้งานตามค่าเริ่มต้นnpm inatall แล้ว package-lock.json จะถูกส่งไปยังคลังสินค้าระยะไกล อย่าส่ง node_modules ไปยังที่เก็บระยะไกลโดยตรงnpm update เป็นประจำเพื่ออัพเกรดการขึ้นต่อกัน และส่งไฟล์ lock เพื่อให้แน่ใจว่าสมาชิกคนอื่น ๆ จะอัพเดตการขึ้นต่อกันพร้อมกัน อย่าเปลี่ยนไฟล์ lock ด้วยตนเองlockpackage.json และดำเนินการ npm installpackage.json npm install package@version
npm install อาจจะต้องผ่านกระบวนการข้างต้น บทนี้จะพูดถึงรายละเอียดการใช้งาน การพัฒนา และเหตุผลของแต่ละกระบวนการ
เราทุกคนรู้ดีว่าหลังจากดำเนินการ npm install แล้ว แพ็คเกจที่ต้องพึ่งพาจะถูกติดตั้งลงใน node_modules มาดูกลไกเฉพาะที่ npm ติดตั้งแพ็คเกจที่ต้องพึ่งพาใน node_modules ให้ละเอียดยิ่งขึ้น
ในเวอร์ชันก่อนหน้าของ npm วิธีจัดการการขึ้นต่อกัน npm นั้นง่ายและไม่ซับซ้อน โดยจะติดตั้งการขึ้นต่อกันใน node_modules ตามลำดับและเป็นไปตามโครงสร้าง package.json และโครงสร้าง package.json ของแพ็คเกจการพึ่งพาย่อยอย่างเคร่งครัด จนกว่าจะมีแพ็คเกจย่อยที่ไม่ขึ้นอยู่กับโมดูลอื่นอีกต่อไป
ตัวอย่างเช่น โมดูล my-app ของเราตอนนี้ขึ้นอยู่กับสองโมดูล: buffer และ ignore :
{
"ชื่อ": "แอปของฉัน",
"การอ้างอิง": {
"บัฟเฟอร์": "^5.4.3",
"ละเว้น": "^5.1.4",
-
} ignore เป็นโมดูล JS ล้วนๆ ที่ไม่ขึ้นอยู่กับโมดูลอื่นๆ และ buffer ขึ้นอยู่กับสองโมดูลต่อไปนี้: base64-js และ ieee754
-
"ชื่อ": "บัฟเฟอร์",
"การอ้างอิง": {
"base64-js": "^1.0.2",
"ieee754": "^1.1.4"
-
} จากนั้น หลังจากดำเนินการ npm install โครงสร้างไดเร็กทอรีโมดูลใน node_modules ที่ได้รับจะเป็นดังนี้:
ข้อดีของวิธีนี้ชัดเจน โครงสร้างของ node_modules สอดคล้องกับโครงสร้างของ package.json แบบหนึ่งต่อหนึ่ง โครงสร้างลำดับชั้นนั้นชัดเจน และโครงสร้างไดเร็กทอรีของการติดตั้งแต่ละครั้งรับประกันว่าจะเหมือนกัน
อย่างไรก็ตาม ลองจินตนาการว่า ถ้าคุณพึ่งพาโมดูลจำนวนมาก node_modules ของคุณจะใหญ่มากและระดับการซ้อนจะลึกมาก:
Windows ความยาวพาธของไฟล์สูงสุดคือ 260 อักขระ และระดับการซ้อนที่ลึกเกินไปอาจทำให้เกิดปัญหาที่คาดเดาไม่ได้เพื่อที่จะแก้ไขปัญหาข้างต้น NPM ได้ทำการอัปเดตครั้งใหญ่ในเวอร์ชัน 3.x โดยจะเปลี่ยนโครงสร้างที่ซ้อนกันตั้งแต่ต้นไปเป็นโครงสร้างแบบเรียบ:
node_modulesด้วยโครงสร้างการพึ่งพาข้างต้น เราจะได้โครงสร้างไดเร็กทอรีต่อไปนี้หลังจากดำเนินการ npm install :
ในเวลานี้ถ้าเราพึ่งพารุ่น [email protected] ในโมดูล:
{
"ชื่อ": "my-app",
"การอ้างอิง": {
"บัฟเฟอร์": "^5.4.3"
"ละเว้น": "^5.1.4"
"base64-js": "1.0.1"
-
} node_modulesณ จุดนี้เราจะได้รับโครงสร้างไดเรกทอรีต่อไปนี้หลังจากดำเนินการ npm install :
ถ้าเราอ้างอิงโมดูลในรหัสโครงการกระบวนการค้นหาโมดูลมีดังนี้:
node_modulesnode_modulesnode_modules ทั่วโลก[email protected] buffer2@^5.4.3
ดังนั้นรุ่น npm 3.x ไม่ได้แก้ปัญหาความซ้ำซ้อนของโมดูลอย่างสมบูรณ์ของเวอร์ชันเก่าและอาจนำปัญหาใหม่มาใช้
ลองนึกภาพว่าแอพของคุณไม่ได้ขึ้นอยู่กับรุ่น [email protected] แต่คุณยังขึ้นอยู่กับ buffer และ buffer2 ที่ขึ้นอยู่กับรุ่น base64-js ที่แตกต่างกัน เนื่องจากเมื่อดำเนินการ npm install การพึ่งพาใน package.json จะถูกแยกวิเคราะห์ตามลำดับลำดับที่ buffer และ buffer2 จะถูกวางไว้ใน package.json กำหนดโครงสร้างการพึ่งพาของ node_modules :
ขึ้นอยู่กับ buffer2 ก่อน:
ขึ้นอยู่กับ buffer ก่อน:
นอกจากนี้เพื่อให้นักพัฒนาสามารถใช้แพ็คเกจการพึ่งพาล่าสุดภายใต้หลักฐานความปลอดภัยเรามักจะล็อคเฉพาะเวอร์ชันขนาดใหญ่ใน package.json ซึ่งหมายความว่าหลังจากรุ่นรองของแพ็คเกจการพึ่งพาบางส่วนได้รับการปรับปรุงโครงสร้างการพึ่งพา นอกจากนี้ยังมีการเปลี่ยนแปลง
เพื่อแก้ปัญหาความไม่แน่นอนของ npm install ไฟล์ package-lock.json ถูกเพิ่มในเวอร์ชัน npm 5.x และวิธีการติดตั้งยังเป็นไปตามวิธีการแบนของ npm 3.x
ฟังก์ชั่นของ package-lock.json package-lock.json npm install ล็อคโครงสร้างการ node_modules .
ตัวอย่างเช่นเรามีโครงสร้างการพึ่งพาต่อไปนี้:
{
"ชื่อ": "my-app",
"การอ้างอิง": {
"บัฟเฟอร์": "^5.4.3"
"ละเว้น": "^5.1.4"
"base64-js": "1.0.1"
-
} package-lock.json ที่สร้างขึ้นหลังจากดำเนินการ npm install เป็นดังนี้:
{
"ชื่อ": "my-app",
"เวอร์ชัน": "1.0.0",
"การอ้างอิง": {
"base64-js": {
"เวอร์ชัน": "1.0.1"
"แก้ไข": "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz"
"ความสมบูรณ์": "sha1-asbrszt7xze47tutdw3i/np+pag ="
-
"บัฟเฟอร์": {
"เวอร์ชัน": "5.4.3"
"แก้ไข": "https://registry.npmjs.org/buffer/-/buffer-5.4.3.tgz"
"ความซื่อสัตย์": "sha512-zvj65tkfeit3i6aj5bivjdzjjqqgs4o/snoezg1f1kyap9nu2jcudpwzrsjthmmzg0h7bzkn4rnqpimhuxwx2a =="
"กำหนดให้มี": {
"base64-js": "^1.0.2"
"IEEE754": "^1.1.4"
-
"การอ้างอิง": {
"base64-js": {
"เวอร์ชัน": "1.3.1"
"แก้ไข": "https://registry.npmjs.org/base64-js/-/base64-js-1.3.1.tgz"
"ความสมบูรณ์": "sha512-mlq4i2qo1ytvgwfwmcngko // jxaquezvwektjgqfm4jik0ku+ytmfpll8j+n5mspofjhwoag+9yhb7bwahm36g =="
-
-
-
"IEEEE754": {
"เวอร์ชัน": "1.1.13"
"แก้ไข": "https://registry.npmjs.org/ieeee754/-/ieee754-1.1.13.tgz"
"ความสมบูรณ์": "sha512-4vf7i2lyv/hawerso3xmlmkp5ez83i+/cdluxi/igts/o1sejbnhttnxzmrzfvouqj7lzjqhketvpgsfdlwztg =="
-
"ไม่สนใจ": {
"เวอร์ชัน": "5.1.4"
"แก้ไข": "https://registry.npmjs.org/ignore/-/ignore-5.1.4.tgz"
"ความซื่อสัตย์": "sha512-mzbusahktw1u7jpkkjy7lcard1fu5w2rldxlm4kdkayucwzimjkpluf9cm1alewyjgupdqewlam18y6au69a8a =="
-
-
} มาดูโครงสร้างด้านบนอย่างใกล้ชิด:
name และ version นอกสุดสองชื่อและเวอร์ชันนั้นเหมือนกับ name และ version ใน package.json และใช้เพื่ออธิบายชื่อแพ็คเกจและเวอร์ชันปัจจุบัน
dependencies เป็น key ซึ่งสอดคล้องกับ node_modules
resolvedversion node_modulesdependencies requiresintegrity hash Subresource Integrity ตรวจสอบว่าแพคเกจซอฟต์แวร์ที่ติดตั้งได้รับการแก้ไขหรือไม่ถูกต้องหรือไม่package.json การพึ่งพา Jsondependencies : โครงสร้างนั้นเหมือนกับโครงสร้าง dependencies ด้านนอกและเก็บแพ็คเกจการพึ่งพาที่ติดตั้งไว้ใน node_modules ที่พึ่งพาอาศัยกันหมายเหตุ node_modules นี่ว่าแอตทริบิวต์ย่อยทั้งหมดไม่ได้มีแอตทริบิวต์ dependencies
ตัวอย่างเช่นตรวจสอบการพึ่งพาด้านบน:
รุ่น [email protected] เราพึ่งพาความขัดแย้ง my-app กับ base64-js@^1.0.2 เราพึ่งพาใน buffer ดังนั้น [email protected] จะต้องติดตั้งใน node_modules ของ แพ็คเกจ buffer ซึ่งสอดคล้องกับแอตทริบิวต์ dependencies ของ buffer ใน package-lock.json มีการเปลี่ยนแปลง นอกจากนี้ยังสอดคล้องกับวิธีการแบนของ npm ในการพึ่งพา
ดังนั้นตามการวิเคราะห์ข้างต้นไฟล์ package-lock.json package-lock.json โครงสร้างไดเรกทอรี node_modules อยู่ในการติดต่อแบบหนึ่งต่อหนึ่ง สร้างโดยการติดตั้งแต่ละครั้ง
นอกจากนี้การใช้ package-lock.json ในโครงการสามารถเพิ่มความเร็วในการติดตั้งอย่างมีนัยสำคัญ
เราใช้คำสั่ง npm i --timing=true --loglevel=verbose lock lock กระบวนการที่สมบูรณ์ของ npm install ทำความสะอาดแคช npm ก่อนเปรียบเทียบ
โดยไม่ต้องใช้ไฟล์ lock :
ใช้ไฟล์ lock :
จะเห็นได้ว่าเวอร์ชันเฉพาะและลิงก์ดาวน์โหลดของแต่ละแพ็คเกจได้รับการแคชใน package-lock.json คำขอเครือข่ายจำนวนมาก
ในการพัฒนาแอปพลิเคชันระบบขอแนะนำให้ส่งไฟล์ package-lock.json ไปยังที่เก็บเวอร์ชันรหัสเพื่อให้แน่ใจว่าเวอร์ชันการพึ่งพาที่ติดตั้งโดยนักพัฒนาทีมทั้งหมดและลิงก์ CI นั้นสอดคล้องกันเมื่อดำเนินการ npm install
เมื่อ semver แพ็คเกจ npm แพ็คเกจ npm ของคุณจะต้องขึ้นอยู่กับที่เก็บข้อมูลอื่น ๆ ภายในขอบเขตซึ่งจะทำให้เกิดความซ้ำซ้อนที่ไม่จำเป็น ดังนั้นเราไม่ควรเผยแพร่ไฟล์ package-lock.json ( npm จะไม่เผยแพร่ไฟล์ package-lock.json ตามค่าเริ่มต้น)
หลังจากดำเนินการคำสั่ง npm install หรือ npm update เพื่อดาวน์โหลดการอ้างอิงนอกเหนือจากการติดตั้งแพ็คเกจการพึ่งพาในไดเรกทอรี node_modules แล้วสำเนาจะถูกแคชในไดเรกทอรีแคชท้องถิ่น
คุณสามารถสืบค้นได้ผ่านคำสั่ง npm config get cache : ใน Linux หรือ Mac ค่าเริ่มต้นคือไดเรกทอรี .npm/_cacache ในไดเรกทอรีบ้านของผู้ใช้
tar tar ไดเรกทอรีในไดเรกทอรีนี้ hash content-v2 content-v2 และ index-v5 index-v5
เมื่อ NPM กำลังดำเนินการติดตั้งมันสามารถสร้าง key ที่ไม่ซ้ำกันที่สอดคล้องกับบันทึกแคชในไดเรกทอรี index-v5 ตาม integrity、version、name ที่เก็บไว้ใน package-lock.json จึงค้นหา hash ของแพ็คเกจ tar จากนั้นมองหามันตาม hash tar
เราสามารถค้นหาแพ็คเกจเพื่อค้นหาและทดสอบในไดเรกทอรีแคชและค้นหาพา ธ แพ็คเกจใน index-v5 :
grep "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1 tgz "-r index -v5
จากนั้นเราจัดรูปแบบ JSON:
{
"คีย์": "pacote: เวอร์ชัน-manifest: https: //registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz: sha1-asbrszt7xze47tutdw3i/np+pag ="
"ความสมบูรณ์": "sha512-c2ekhxwxvlsbrucjtrs3xfhv7mf/y9klmkdxpte8yevcoh5h8ae69y+/lp+ahpw91crnzgo78elok2e6apjfiq =="
"เวลา": 1575554308857
"ขนาด": 1,
"ข้อมูลเมตา": {
"id": "[email protected]"
"Manifest": {
"ชื่อ": "base64-js",
"เวอร์ชัน": "1.0.1"
"เครื่องยนต์": {
"โหนด": "> = 0.4"
-
"การพึ่งพา": {},
"Optionaldependencies": {},
"DevDependencies": {
"มาตรฐาน": "^5.2.2"
"เทป": "4.x"
-
"Bundledependencies": เท็จ
"peerdependencies": {},
"เลิกใช้แล้ว": เท็จ
"_resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz"
"_integrity": "sha1-asbrszt7xze47tutdw3i/np+pag ="
"_shasum": "6926D1B194FBC737B8EED513756DE2FCDA7EA408"
"_shrinkwrap": null,
"bin": null,
"_id": "[email protected]"
-
"type": "สรุป-manifest"
-
} แอตทริบิวต์ _shasum ข้างต้น 6926d1b194fbc737b8eed513756de2fcda7ea408 เป็น hash ของแพ็คเกจ tar และ 6926 สองสามตัวแรกของ hash
กลยุทธ์การแคชข้างต้นเริ่มต้นจากเวอร์ชัน NPM V5 }.
npm มีคำสั่งหลายคำในการจัดการข้อมูลแคช:
npm cache add : คำอธิบายอย่างเป็นทางการคือคำสั่งนี้ส่วนใหญ่ใช้ภายในโดย npm แต่ยังสามารถใช้เพื่อเพิ่มแคชด้วยตนเองในแพ็คเกจที่ระบุnpm cache clean --force ลบข้อมูลทั้งหมดในไดเรกทอรีแคชnpm cache verify : ตรวจสอบความถูกต้องและความสมบูรณ์ของข้อมูลแคชและทำความสะอาดข้อมูลขยะจากข้อมูลที่แคช NPM ให้โหมดการติดตั้งออฟไลน์ซึ่งมีดังนี้:
--prefer-offline : ใช้ข้อมูลแคชก่อน--prefer-online : จัดลำดับความสำคัญการใช้ข้อมูลเครือข่าย--offline : อย่าขอเครือข่ายและใช้ข้อมูลแคชโดยตรงที่เราพูดถึงความสมบูรณ์ของไฟล์หลายครั้งข้างต้นดังนั้นการตรวจสอบความสมบูรณ์ของไฟล์คืออะไร?
ก่อนที่จะดาวน์โหลดแพ็คเกจการพึ่งพาเรามักจะได้ shasum ค่า hash hash tarball โดย npm npm info แพ็คเกจการพึ่งพา
hash ผู้ใช้ดาวน์โหลดแพ็คเกจการพึ่งพาอาศัยกันในเครื่องเขาหรือเธอต้องตรวจสอบให้แน่ใจว่าไม่มีข้อผิด hash เกิดขึ้นในระหว่างกระบวนการดาวน์โหลด เหมือนกันตรวจสอบให้แน่ใจว่าการพึ่งพาที่ดาวน์โหลดเสร็จสมบูรณ์
ตอนนี้กระบวนการโดยรวมเสร็จสมบูรณ์ให้สรุปกระบวนการข้างต้น:
ตรวจสอบไฟล์ .npmrc : ลำดับความสำคัญคือ: ไฟล์ระดับโครงการ .npmrc > ไฟล์ระดับผู้ใช้ .npmrc .npmrc ไฟล์ระดับโลก .npmrc ไฟล์
ตรวจสอบว่ามีไฟล์ lock ในโครงการหรือไม่
ไม่มีไฟล์ lock :
npmpackage.json node_modulesnode_modules ของโมดูลปัจจุบันnpm แพ็คเกจดาวน์โหลดคลังสินค้าระยะไกลnode_modulesnpmlock
package-lock.json package.jsonlocknode_modulesnode_modules การพึ่งพาpackage-lock.json .
กระบวนการข้างต้นอธิบายกระบวนการทั่วไปของ npm install npm install package --timing=true --loglevel=verbose ย่อ กระบวนการติดตั้งและรายละเอียดของแพ็คเกจที่แน่นอน
yarn package-lock.json รับการปล่อยตัวใน 2016 ในเวลานั้น npm ยังคงอยู่ในช่วง V3 ของนักพัฒนา ณ จุดนี้ yarn เกิด:
ข้างต้นเป็นข้อดีของ yarn ที่กล่าวถึงในเว็บไซต์ทางการซึ่งยังคงน่าสนใจมากในเวลานั้น แน่นอนว่า npm ในภายหลังได้ตระหนักถึงปัญหาของตัว yarn และ yarn lock ให้เหมาะสมมาก การออกแบบยังคงดีมาก
yarn ยังใช้โครงสร้างแบนของ yarn.lock npm v3 เพื่อจัดการ yarn.lock
พึ่งพา เป็นไฟล์ autogenerated # เส้นด้ายล็อคไฟล์ v1 [email protected]: เวอร์ชัน "1.0.1" แก้ไข "https://registry.yarnpkg.com/base64-js/-/base64-js-1.0.1.tgz#6926d1b194fbc737b8eed513756de2fcda7ea408" ความสมบูรณ์ sha1-asbrszt7xze47tutdw3i/np+pag = base64-js@^1.0.2: เวอร์ชัน "1.3.1" แก้ไข "https://registry.yarnpkg.com/base64-js/-/base64-js-1.3.1.tgz#58ece8cb75dd07e71ed08c736abc5fac4dbf8df1" Integrity sha512-mlq4i2qo1ytvgwfwmcngko // jxaquezvwektjgqfm4jik0ku+ytmfpll8j+n5mspofjhwoag+9yhb7bwahm36g == buffer@^5.4.3: เวอร์ชัน "5.4.3" ได้รับการแก้ไข "https://registry.yarnpkg.com/buffer/-/buffer-5.4.3.tgz#3fbc9c69eb713d323e3fc1a895eee0710c072115" Integrity SHA512-ZVJ65TKFEIT3I6AJ5BIVJDZJJQQGS4O/SNOEZG1F1KYAP9NU2JCUDPWZRSJTHMMZG0H7BZKN4RNQPIMHUXWX2A === การพึ่งพา: base64-js "^1.0.2" IEEE754 "^1.1.4" IEEE754@^1.1.4: เวอร์ชัน "1.1.13" ได้รับการแก้ไข "https://registry.yarnpkg.com/ieeee754/-/ieee754-1.1.13.TGZ#ec168558E95AA181FD87D37F55C32BBCB6708B84" ความสมบูรณ์ sha512-4vf7i2lyv/hawerso3xmlmkp5ez83i+/cdluxi/igts/o1sejbnhttnxzmrzfvouqj7lzjqhketvpgsfdlwztg == changore@^5.1.4: เวอร์ชัน "5.1.4" แก้ไข "https://registry.yarnpkg.com/ignore/-/ignore-5.1.4.tgz#84b7b3dbe64552b6ef0eca99f6743dbec6d97Adf"ความ
package-lock.json
sha512-mzbusahktw1u7jpkkjy7lcard1fu5w2rldxlm4kdkayucwzimjkpluf9cm1alewyjgupdqewlam18y6au69a8a ==
yarn.lock json package-lock.jsonyarn.lock หมายเลขเวอร์ชันของการพึ่งพานิวตรอน yarn.lock ไม่ได้รับการแก้ไขซึ่งหมายความว่า yarn.lock เพียงอย่างเดียวไม่สามารถกำหนดโครงสร้างไดเรกทอรี node_modules และจำเป็นต้องประสานงานกับไฟล์ package.json และ package-lock.json ต้องการเพียงไฟล์เดียวเพื่อกำหนดกลยุทธ์การแคชของ yarn ดูคล้ายกันมากก่อนที่ npm v5 ใช้ COMMANT yarn cache dir เพื่อดูไดเรกทอรีของข้อมูลแคช:
โดยค่าเริ่มต้น
yarnใช้โหมดprefer-onlineซึ่งหมายถึงข้อมูลเครือข่ายจะถูกใช้ก่อน
ฉันหวังว่าหลังจากอ่านบทความนี้มันจะช่วยคุณได้ดังนี้:
npmpacakge.json เพื่อให้ข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับการกำหนดค่าทางวิศวกรรมโครงการnpm install npm package-lock.json