تحليل متعمق لآلية إدارة الحزم في npm

الكاتب：Eve Cole وقت التحديث：2022-09-21 09:19:40

دورة الدخول إلى الإتقان للواجهة الأمامية (vue): الدخول في التعلم

في الوقت الحاضر، لا يمكن لطلاب تطوير الواجهة الأمامية الاستغناء عن npm ، وهي أداة لإدارة الحزم الممتازة التي تحمل مجتمع NodeJS المزدهر بأكمله، وهي مفيدة جدًا لفهم آليتها الداخلية، فهو يساعد على تعميق فهمنا لتطوير الوحدة والتكوينات الهندسية المختلفة للواجهة الأمامية لتسريع عملية استكشاف الأخطاء وإصلاحها (أعتقد أن العديد من الطلاب قد انزعجوا من مشكلات التبعية المختلفة).

تجري هذه المقالة تحليلًا تفصيليًا لآلية إدارة الحزم الخاصة بـ npm من ثلاث وجهات نظر: package.json وإدارة الإصدار وتثبيت التبعية وأمثلة محددة.

1. تحليل package.json

في Node.js ، الوحدة هي مكتبة أو إطار عمل وأيضًا مشروع Node.js يتبع مشروع Node.js بنية معيارية. عندما نقوم بإنشاء مشروع Node.js ، فهذا يعني إنشاء وحدة نمطية يجب أن تحتوي على ملف وصف، وهو package.json . إنه ملف التكوين الأكثر شيوعًا لدينا، ولكن هل فهمت حقًا التكوين الموجود فيه بالتفصيل؟ يحدد تكوين ملف package.json بشكل معقول جودة مشروعنا بشكل مباشر، لذلك سنقوم أولاً بتحليل التكوين التفصيلي لـ package.json .

1.1 السمات المطلوبة

هناك العديد من السمات في package.json ، والتي يجب ملء اثنتين منها فقط: name version . تشكل هاتان السمتان المعرف الفريد لوحدة npm .

اسم

قواعد تسمية حزمة 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/ للحصول على معلومات أكثر تفصيلاً عن الحزمة.

1.2

الوصف الأساسي

لمعلومات الوصف

{
  "description": "لغة تصميم واجهة المستخدم على مستوى المؤسسات وتنفيذ مكونات React"،
  "الكلمات الرئيسية": [
    "النملة"،
    "عنصر"،
    "عناصر"،
    "تصميم"،
    "نطاق"،
    "الواجهة الأمامية"،
    "رد فعل"،
    "مكون رد الفعل"،
    "واجهة المستخدم"
  ]
}

يتم استخدام description لإضافة معلومات وصف الوحدة لتسهيل فهم الآخرين للوحدة الخاصة بك.

يتم استخدام keywords لإضافة كلمات رئيسية إلى الوحدة النمطية الخاصة بك.

بالطبع، يلعبون أيضًا دورًا مهمًا للغاية، وهو تسهيل استرجاع الوحدة. عندما تستخدم npm search لاسترداد وحدة نمطية، فإنها ستطابق description والكلمات keywords . إن كتابة description جيد keywords ستساعد وحدتك في الحصول على عرض أكثر دقة:

هناك حقلان

للمطورين

لوصف المطورين: author contributors يشير author إلى المؤلف الرئيسي للحزمة، author واحد يتوافق مع شخص واحد. يشير contributors إلى معلومات المساهم. أحد contributors يتوافق مع عدة مساهمين. القيمة عبارة عن مصفوفة. يمكن أن يكون وصف الشخص عبارة عن سلسلة أو البنية التالية:

{ 
    "اسم" : "كوناردلي"، 
    "البريد الإلكتروني": "[email protected]"، 
    "عنوان URL": "https://github.com/ConardLi"
}

عنوان

{
  "الصفحة الرئيسية": "http://ant.design/"،
  "الأخطاء": {
    "url": "https://github.com/ant-design/ant-design/issues"
  },
  "المستودع": {
    "النوع": "جيت"،
    "url": "https://github.com/ant-design/ant-design"
  },
}

يتم استخدام homepage لتحديد الصفحة الرئيسية لهذه الوحدة.

يتم استخدام repository لتحديد مستودع التعليمات البرمجية للوحدة.

تحدد bugs عنوانًا أو بريدًا إلكترونيًا حيث يمكن للأشخاص الذين لديهم أسئلة حول الوحدة الخاصة بك الذهاب إلى هنا لطرح الأسئلة.

1.3 تكوين التبعية

قد يعتمد مشروعنا على حزمة تبعية خارجية واحدة أو أكثر وفقًا للاستخدامات المختلفة لحزم التبعية، نقوم بتكوينها تحت السمات التالية: dependencies、devDependencies、peerDependencies、bundledDependencies、optionalDependencies .

قواعد التكوين

قبل تقديم العديد من تكوينات التبعية، دعنا أولاً نلقي نظرة على قواعد تكوين التبعيات التي تراها قد تكون كما يلي:

"dependeency": {
      "antd": "ant-design/ant-design#4.0.0-alpha.8"،
      "أكسيوس": "^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-ish
git+ssh://user@hostname:project.git#commit-ish
git+ssh://user@hostname/project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish

- تحدد

تبعيات

git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish

dependencies النمطية التي يعتمد عليها المشروع، ويمكن تكوين كل من وحدات تبعية بيئة التطوير وبيئة الإنتاج هنا، مثل

التبعيات": {
      "لوداش": "^4.17.13",
      "لحظة": "^2.24.0"،
 }

هناك بعض الحزم في

devDependeency

التي لا يمكنك استخدامها إلا في بيئة التطوير، مثل eslint للتحقق من مواصفات التعليمات البرمجية و jest للاختبار، عندما يستخدم المستخدمون الحزمة الخاصة بك، يمكن تشغيلها بشكل طبيعي حتى بدون تثبيت هذه التبعيات سيستغرق الأمر المزيد من الوقت والموارد، لذا يمكنك إضافة هذه التبعيات إلى devDependencies . ستظل هذه التبعيات مثبتة وإدارتها عند إجراء npm install محليًا، ولكن لن يتم تثبيتها في بيئة الإنتاج:

"devDependeency" : {
      "مزحة": "^24.3.1",
      "إسلينت": "^6.1.0",
 }

يتم استخدام التبعيات

النظيرة

peerDependencies الإصدار الذي تعتمد عليه الوحدة النمطية التي تقوم بتطويرها وتوافق إصدار الحزمة التابعة التي قام المستخدم بتثبيتها.

قد يكون البيان أعلاه مجردًا بعض الشيء فلنأخذ ant-design كمثال، يحتوي package.json الخاص بـ ant-design على التكوين التالي:

"peerDependeency": {
    "رد": ">=16.0.0"،
    "رد فعل": ">=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 * as ReactDOM من 'react-dom'؛

ما تحصل عليه الآن هو البيئة المضيفة، وهي نسخة React في بيئتك، والتي قد تسبب بعض المشاكل. في npm2 ، تحديد peerDependencies أعلاه يعني إجبار البيئة المضيفة على تثبيت إصدارات react@>=16.0.0和react-dom@>=16.0.0 .

في المستقبل، لن يتطلب npm3 تثبيت حزم التبعية المحددة بواسطة peerDependencies ، بل على العكس من ذلك npm3 مما إذا كان التثبيت صحيحًا بعد اكتمال التثبيت، وإذا كان غير صحيح، فسيتم طباعة تحذير للمستخدم .

"التبعيات": {
    "رد فعل": "15.6.0"،
    "أنتد": "^3.22.0"
  }

على سبيل المثال، أعتمد على أحدث إصدار من antd في المشروع، ثم أعتمد على الإصدار 15.6.0 من react ، وسيتم تقديم التحذير التالي عند تثبيت التبعية:

التبعيات الاختيارية

في بعض السيناريوهات، قد لا تكون الحزمة التابعة تبعية قوية. يمكن الاستغناء عن وظيفة هذه الحزمة التابعة. عندما لا يمكن الحصول على هذه الحزمة التابعة، تريد أن يستمر npm install دون التسبب في الفشل optionalDependencies . لاحظ أن التكوين في optionalDependencies سيتجاوز dependencies لذا يجب تكوينه في مكان واحد فقط.

بالطبع، عند الإشارة إلى التبعيات المثبتة في optionalDependencies ، يجب معالجة الاستثناءات، وإلا سيتم الإبلاغ عن خطأ عندما لا يمكن الحصول على الوحدة.

تختلف قيمة التبعيات bundledDependencies عما ورد أعلاه في المصفوفة. يمكن تحديد بعض الوحدات في المصفوفة

.

"bundledDependeency": ["package1" , "package2"]

بروتوكول 1.4

{
    "الترخيص": "معهد ماساتشوستس للتكنولوجيا"
}

يتم استخدام حقل license لتحديد اتفاقية المصدر المفتوح للبرنامج. توضح اتفاقية المصدر المفتوح الحقوق التي يتمتع بها الآخرون بعد الحصول على التعليمات البرمجية الخاصة بك، وما هي العمليات التي يمكنهم تنفيذها على التعليمات البرمجية الخاصة بك، وما هي العمليات المحظورة. هناك العديد من المتغيرات لنفس الاتفاقية. فالاتفاقية الفضفاضة للغاية ستؤدي إلى خسارة المؤلف للعديد من حقوقه في العمل، في حين أن الاتفاقية الصارمة للغاية لن تكون مناسبة للمستخدمين لاستخدام العمل ونشره يجب على مؤلفي المصادر المفتوحة أن يفكروا في الحقوق التي يريدون الاحتفاظ بها والقيود التي يريدون تخفيفها.

يمكن تقسيم اتفاقيات البرامج إلى فئتين: مفتوحة المصدر وتجارية. بالنسبة للاتفاقيات التجارية، والتي تسمى أيضًا البيانات القانونية واتفاقيات الترخيص، سيكون لكل برنامج مجموعة نصية خاصة به، كتبها مؤلف البرنامج أو محامٍ متخصص. ليست هناك حاجة للقيام بذلك بنفسك. يعد اختيار ترخيص مفتوح المصدر منتشرًا على نطاق واسع خيارًا جيدًا.

فيما يلي العديد من البروتوكولات مفتوحة المصدر السائدة:

MIT : طالما قام المستخدمون بتضمين إشعار حقوق الطبع والنشر وإشعار الترخيص في نسخهم من المشروع، فيمكنهم فعل ما يريدون باستخدام الكود الخاص بك دون أي مسؤولية من جانبك.
Apache : مشابه لـ MIT ، ولكنه يتضمن أيضًا المصطلحات المتعلقة بترخيص براءات الاختراع المقدمة من المساهمين للمستخدمين.
GPL : يجب على المستخدمين الذين يقومون بتعديل كود المشروع نشر تعديلاتهم ذات الصلة عند إعادة توزيع كود المصدر أو الكود الثنائي.

إذا كانت لديك متطلبات أكثر تفصيلاً لاتفاقية المصدر المفتوح، فيمكنك الانتقال إلى موقع Choosealicense.com/ للحصول على وصف أكثر تفصيلاً لاتفاقية المصدر المفتوح.

1.5

مدخل البرنامج

المتعلق بالدليل والملف

{
  "الرئيسي": "lib/index.js",
}

يمكن للسمة main تحديد ملف الإدخال الرئيسي للبرنامج، على سبيل المثال، إدخال الوحدة النمطية lib/index.js المحدد بواسطة antd أعلاه عندما نقدم antd في الكود: import { notification } from 'antd'; ما تم تقديمه هو lib/index.js .

إدخال أداة سطر الأوامر

عندما تكون الوحدة النمطية الخاصة بك عبارة عن أداة سطر أوامر، فإنك تحتاج إلى تحديد إدخال لأداة سطر الأوامر، أي تحديد المراسلات بين اسم الأمر الخاص بك والملف المحلي القابل للتحديد. إذا تم تثبيته عالميًا، فسيستخدم npm رابطًا رمزيًا لربط الملف القابل للتنفيذ بـ /usr/local/bin . وإذا تم تثبيته محليًا، فسوف يرتبط بـ ./node_modules/.bin/ .

{
    "بن": {
    "كونارد": "./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 . من خلال أمر man ، يمكنك عرض مساعدة الأمر، ومساعدة ملف التكوين، ومساعدة البرمجة، ومعلومات أخرى في 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 : Where. يتم تخزين الملفات الثنائية القابلة للتنفيذ Directory
lib : دليل لتخزين
doc رمز js: دليل لتخزين المستندات
test : دليل لتخزين رمز حالة اختبار الوحدة
...

في دليل الوحدة، لا يجوز لك اتباع البنية المذكورة أعلاه بدقة لتنظيمها أو تسميتها. يمكنك تحديد directories في خصائص package.json لتحديد كيفية توافق بنية الدليل مع البنية الأساسية أعلاه. وبصرف النظر عن هذا، لا تحتوي سمة directories على تطبيقات أخرى في الوقت الحالي.

{
  "الدلائل": {
    "lib": "src/lib/"،
    "بن": "src/بن/"،
    "رجل": "src/man/"،
    "doc": "src/doc/",
    "مثال": "src/مثال/"
  }
}

ومع ذلك، تنص الوثيقة الرسمية على أنه على الرغم من أن هذه السمة ليس لها دور مهم حاليًا، فقد يتم تطوير بعض الحيل في المستقبل، على سبيل المثال، قد يتم عرض ملفات تخفيض السعر المخزنة في المستند والملفات النموذجية المخزنة في المثال بطريقة ودية.

1.6 البرنامج النصي لتكوين

البرنامج

النصي

{
  "البرامج النصية": {
    "اختبار": "jest --config .jest.js --no-cache"،
    "dist": "تشغيل أدوات antd dist",
    "compile": "تشغيل أدوات antd للترجمة",
    "build": "تشغيل npm ترجمة && npm تشغيل 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 في البرنامج النصي.

{
  "التكوين" : { "المنفذ" : "8080" }
}

1.7 تكوين الإصدار

مفضل عالمي

إذا كانت وحدة node.js الخاصة بك تُستخدم بشكل أساسي لتثبيت أدوات سطر الأوامر العامة، فسيتم تعيين هذه القيمة على true ، وسيحصل المستخدمون على تحذير عند تثبيت الوحدة محليًا. لن يمنع هذا التكوين المستخدمين من التثبيت، ولكنه سيطالبهم بمنع الاستخدام غير الصحيح الذي قد يسبب بعض المشاكل.

خاصة

إذا تم تعيين السمة private على true ، فسوف يرفض npm نشرها وذلك لمنع نشر الوحدة الخاصة عن طريق الخطأ.

نشر التكوين

"نشر التكوين": {
    "التسجيل": "https://registry.npmjs.org/"
  }،

تكوين أكثر تفصيلاً عند نشر الوحدة، على سبيل المثال، يمكنك التكوين لنشر tag معينة فقط، وتكوين مصدر npm الخاص للنشر إليه.

لمزيد من

التكوين التفصيلي، يرجى الرجوع إلى npm-config

os.

إذا قمت بتطوير وحدة يمكن تشغيلها فقط ضمن نظام darwin ، فأنت بحاجة إلى التأكد من أن مستخدمي windows لن يقوموا بتثبيت الوحدة الخاصة بك لتجنب الأخطاء غير الضرورية.

يمكن أن يساعدك استخدام السمة os في تحقيق المتطلبات المذكورة أعلاه. يمكنك تحديد إمكانية تثبيت الوحدة الخاصة بك على أنظمة معينة فقط، أو تحديد قائمة سوداء للأنظمة التي لا يمكن تثبيتها:

"os" : [ "darwin"، "linux" ]
"os" : [ "!win32" ]

على سبيل المثال، قمت بتعيين وحدة اختبار لقائمة سوداء للنظام: "os" : [ "!darwin" ] عندما أقوم بتثبيتها ضمن هذا النظام، سيظهر الخطأ التالي:

في بيئة العقدة، يمكنك استخدامprocess.platform لتحديد نظام التشغيل.

os cpu

المعالجة المركزية نظام

التشغيل أعلاه. يمكننا استخدام سمة وحدة المعالجة المركزية لتحديد بيئة التثبيت الخاصة بالمستخدم بشكل أكثر دقة:

"cpu" : [ "x64"، "ia32" ]
"cpu" : [ "!arm", "!mips" ]

في بيئة العقدة، يمكنك استخدامprocess.arch لتحديد بنية وحدة المعالجة المركزية.

2. تحليل آلية إدارة إصدار الحزمة

لا يمكن فصل نجاح Nodejs عن نظام إدارة التبعية الممتاز الخاص بـ npm . قبل تقديم نظام التبعية بأكمله، يجب أن تفهم كيفية إدارة npm لإصدارات الحزم التابعة. سيقدم هذا الفصل مواصفات إصدار إصدار npm包، وكيفية إدارة إصدارات الحزم التابعة المختلفة، وبعض أفضل الممارسات المتعلقة بإصدارات الحزم.

2.1 عرض إصدار حزمة npm

يمكنك تنفيذ npm view package version لعرض أحدث إصدار من package .

قم بتنفيذ npm view conard versions لعرض جميع الإصدارات المنشورة package على خادم npm.

قم بتنفيذ npm ls لعرض معلومات الإصدار لجميع الحزم في شجرة تبعية المستودع الحالية.

2.2 مواصفات SemVer

تحتاج إصدارات الوحدة في npm包إلى اتباع مواصفات SemVer - وهي قاعدة تمثيلية إرشادية وموحدة لرقم الإصدار تمت صياغتها بواسطة Github . إنه في الواقع اختصار Semantic Version .

الموقع الرسمي لمواصفات SemVer: https://semver.org/Standard

version

رقم الإصدار القياسي لمواصفات 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

فلنلقي نظرة على الإصدارات التاريخية من React :

يمكن ملاحظة أن الإصدار تم إصداره وفقًا لمواصفات SemVer :

رقم الإصدار يتوافق تمامًا مع تنسيق主版本号.次版本号.修订号إصدار التسمية
تزايدي تمامًا: 16.8.0 -> 16.8.1 -> 16.8.2

> 16.8.1 -> 16.8.2 يُصدر إصدارات رئيسية أو عندما تكون تغييرات الإصدار كبيرة، عادةً ما

يتم

إصدار

16.8.0 -> 16.8.1 -> 16.8.2
alpha beta و rc والإصدارات المتقدمة الأخرى

أولاً

بعد تعديل وظائف معينة لحزمة npm ، عادةً ما يكون من الضروري إصدار ملف الإصدار الجديد. نهجنا المعتاد هو تعديل package.json مباشرة إلى الإصدار المحدد. إذا كانت العملية غير صحيحة، فمن السهل التسبب في ارتباك في رقم الإصدار، يمكننا استخدام الأوامر التي تتوافق مع مواصفات Semver لإكمال هذه العملية:

npm version patch : ترقية رقم المراجعة
npm version minor : ترقية رقم الإصدار الثانوي
npm version major : ترقية رقم الإصدار الرئيسي

2.3 لا غنى عن استخدام أدوات الإصدار

في التطوير لتشغيل بعض أرقام الإصدارات، إذا كانت أرقام الإصدارات هذه متوافقة مع مواصفات 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

semver.valid(semver.coerce('v2')) // '2.0.0'
semver.valid(semver.coerce('42.6.7.9.3-alpha')) //

بعض الاستخدامات الأخرى لـ

'42.6.7'

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

2.4 إدارة إصدار التبعيات

غالبًا ما نرى طرقًا مختلفة لكتابة التبعيات المختلفة في package.json :

"dependeency": {
    "الإشارة": "1.4.0"،
    "التين": "*"،
    "رد": "16.x"،
    "جدول": "~5.4.6"،
    "يارجس": "^14.0.0"
  }

الثلاثة الأولى سهلة الفهم:

"signale": "1.4.0" : رقم الإصدار الثابت
"figlet": "*" : أي إصدار ( >=0.0.0 )
"react": "16.x" : مطابقة الإصدار الرئيسي ( >=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 بتثبيت أحدث إصدار افتراضيًا، ثم يقوم بتثبيته في ملف Add علامة ^ قبل رقم الإصدار.

لاحظ أنه عندما يكون رقم الإصدار الرئيسي هو 0 ، فسيتم اعتباره إصدارًا غير مستقر. يختلف الوضع عما سبق:

رقم الإصدار الرئيسي ورقم الإصدار الثانوي هما 0 : ^0.0.z و ~0.0.z كلاهما. تعتبر إصدارات ثابتة، ولن تحدث أي تغييرات عند تثبيت التبعيات.
رقم الإصدار الرئيسي هو 0 : يتصرف ^0.yz بنفس طريقة ~0.yz ، ويتم الاحتفاظ برقم المراجعة فقط كأحدث إصدار.

يتم استخدام رقم الإصدار 1.0.0 لتحديد واجهة برمجة التطبيقات العامة. عندما يتم إصدار برنامجك إلى البيئة الرسمية، أو يكون لديه واجهة برمجة تطبيقات مستقرة، يمكنك إصدار الإصدار 1.0.0. لذلك، عندما تقرر إصدار نسخة رسمية من حزمة npm للعالم الخارجي، قم بوضع علامة على نسختها على أنها 1.0.0.

2.5 قفل

ملف قفل

إصدار التبعية

في التطوير الفعلي، غالبًا ما تحدث مشكلات غريبة بسبب عدم الاتساق في التبعيات المختلفة، أو في بعض السيناريوهات، لا نريد تحديث التبعيات. يوصى باستخدام 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 وترقية جميع التبعيات الحمراء.

2.6 أفضل الممارسات لاختيار الإصدار التابع

إصدار الإصدار

عند نشر إصدار رسمي من حزمة npm خارجيًا، قم بوضع علامة على إصدارها كـ 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 في وقت واحد.

تغييرات التبعيات

وترقية التبعيات: قم بتعديل إصدار التبعية لملف package.json وتنفيذ تثبيت npm install
lock
بتنفيذ npm install package@version (لن يؤدي تغيير package.json إلى تقليل التبعيات).
بعد تغيير التبعيات

3. تحليل مبدأ تثبيت npm

من المحتمل أن يمر npm install بالعمليات المذكورة أعلاه. سيتحدث هذا الفصل عن تفاصيل التنفيذ والتطوير وسبب كل عملية.

3.1 البنية المتداخلة

نعلم جميعًا أنه بعد تنفيذ 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 json واحد لواحد، والبنية الهرمية واضحة، ويضمن أن تكون بنية الدليل لكل تثبيت هي نفسها.

ومع ذلك، تخيل فقط، إذا كنت تعتمد على الكثير من الوحدات، فستكون node_modules الخاصة بك كبيرة جدًا وسيكون مستوى التداخل عميقًا جدًا:

قد تشير التبعيات على مستويات مختلفة إلى نفس الوحدة، مما يؤدي إلى الكثير من التكرار.
في أنظمة Windows ، يبلغ الحد الأقصى لطول مسار الملف 260 حرفًا، وقد يؤدي مستوى التداخل العميق جدًا إلى حدوث مشكلات غير متوقعة.

3.2 البنية المسطحة

من أجل حل المشكلات المذكورة أعلاه، قام NPM بإجراء تحديث رئيسي في الإصدار 3.x يقوم بتغيير البنية المتداخلة المبكرة إلى بنية مسطحة:

عند تثبيت وحدة نمطية، بغض النظر عما إذا كانت تبعية مباشرة أو تبعية فرعية، يتم تثبيتها أولاً في الدليل الجذر node_modules .

ومع استخدام بنية التبعية المذكورة أعلاه، سنحصل على بنية الدليل التالية بعد تنفيذ npm install :

في هذا الوقت ، إذا كنا نعتمد على إصدار [email protected] في الوحدة النمطية:

{
  "الاسم": "التطبيق الخاص بي" ،
  "التبعيات": {
    "المخزن المؤقت": "^5.4.3" ،
    "تجاهل": "^5.1.4" ،
    "Base64-JS": "1.0.1" ،
  }
}

عند التثبيت على نفس الوحدة ، حدد ما إذا كان إصدار الوحدة النمطية المثبتة يتطابق مع نطاق الإصدار من الوحدة node_modules الجديدة.

في هذه المرحلة ، سنحصل على هيكل الدليل التالي بعد تنفيذ npm install :

في المقابل ، إذا اقتربنا من وحدة البحث عن رمز المشروع ، فإن عملية البحث عن الوحدة النمطية هي كما يلي:

ابحث
في مسار الوحدة
النمطية
node_modules
node_modules
يتم تفتيش node_modules

[email protected] buffer2@^5.4.3

لذلك ، لا يحل إصدار npm 3.x تمامًا مشكلة تكرار الوحدة النمطية للإصدار القديم ، وقد يجلب مشكلات جديدة.

تخيل أن تطبيقك لا يعتمد على إصدار [email protected] ، لكنك تعتمد أيضًا على buffer buffer2 الذي يعتمد على إصدارات base64-js المختلفة. منذ تنفيذ npm install ، يتم تحليل التبعيات في package.json بالترتيب ، والترتيب الذي يتم فيه وضع buffer node_modules buffer2 في package.json

buffer2

تعتمد على buffer أولاً:

بالإضافة إلى ذلك ، من أجل السماح للمطورين باستخدام أحدث حزم التبعية تحت فرضية السلامة ، عادة ما نقفل الإصدار الكبير فقط في package.json ، مما يعني أنه بعد تحديث الإصدار البسيط من بعض حزم التبعية ، قد يتم تحديث هيكل التبعية أيضا أن تتغير.

3.3 قفل ملف

من أجل حل مشكلة عدم اليقين npm install ، تمت إضافة ملف package-lock.json في إصدار npm 5.x ، وتتبع طريقة التثبيت أيضًا الطريقة المسطحة لـ npm 3.x

npm install وظيفة package-lock.json package-lock.json قفل بنية node_modules . .

على سبيل المثال ، لدينا بنية التبعية التالية:

{
  "الاسم": "التطبيق الخاص بي" ،
  "التبعيات": {
    "المخزن المؤقت": "^5.4.3" ،
    "تجاهل": "^5.1.4" ،
    "Base64-JS": "1.0.1" ،
  }
}

package-lock.json التي تم إنشاؤها بعد تنفيذ npm install كما يلي:

{
  "الاسم": "التطبيق الخاص بي" ،
  "الإصدار": "1.0.0"،
  "التبعيات": {
    "BASE64-JS": {
      "الإصدار": "1.0.1" ،
      "تم حل":
      "النزاهة":
    },
    "المخزن المؤقت": {
      "الإصدار": "5.4.3" ،
      "حل": "https://registry.npmjs.org/buffer/-buffer-5.4.3.tgz
      "النزاهة":
      "يتطلب": {
        "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" ،
          "النزاهة":
        }
      }
    },
    "IEEE754": {
      "الإصدار": "1.1.13" ،
      "حل": "https://registry.npmjs.org/ieee754/-/ieee754-1.1.13.tgz" ،
      "الاستيلاء":
    },
    "يتجاهل": {
      "الإصدار": "5.1.4" ،
      "حل": "https://registry.npmjs.org/ignore/-ignore-5.1.4.tgz" ،
      "النزاهة": "sha512-mzbusahktw1u7jpkjy7lcard1fu5w2rldxlm4kdkayucwzimjpluf9cm1alewyjgupdqewlam18y6au69a8a =="
    }
  }
}

دعنا نلقي نظرة فاحصة على الهيكل أعلاه:

name السمة الخارجية version هما نفس name version في package.json ، ويتم استخدامهما لوصف اسم الحزمة الحالي وإصداره.

dependencies هو key ، يتوافق مع بنية node_modules

resolved
version node_modules
: سلامة مصدر التثبيت المحددة
integrity قيمة hash ، استنادًا إلى Subresource Integrity للتحقق مما إذا كانت حزمة البرامج المثبتة قد تم تعديلها أو غير
dependencies requires package.json التبعية.
dependencies : الهيكل هو نفس بنية dependencies الخارجية ، ويخزن حزم التبعية المثبتة في node_modules دون الاعتماد.

لاحظ هنا أن جميع عمليات الاعتماد الفرعية لديها سمة dependencies node_modules

على سبيل المثال ، راجع التبعيات أعلاه:

إصدار [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 افتراضيًا).

3.4 التخزين المؤقت

بعد تنفيذ أمر npm install أو npm update لتنزيل التبعيات ، بالإضافة إلى تثبيت حزمة التبعية في دليل node_modules ، سيتم أيضًا تخزين نسخة في دليل ذاكرة التخزين المؤقت المحلية.

يمكنك الاستعلام عنه من خلال أمر npm config get cache : في Linux أو Mac يكون الافتراضي هو دليل .npm/_cacache في الدليل الرئيسي للمستخدم.

هناك دليلان tar هذا الدليل hash يتم استخدام دليل content-v2 content-v2 و index-v5 tar 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]" ،
    "يظهر": {
      "الاسم": "BASE64-JS" ،
      "الإصدار": "1.0.1" ،
      "المحركات": {
        "العقدة": "> = 0.4"
      },
      "التبعيات": {} ،
      "OptionalDependencies": {} ،
      "DevDependencies": {
        "Standard": "^5.2.2" ،
        "شريط": "4.x"
      },
      "bundledependencies": خطأ ،
      "PeerDependencies": {} ،
      "إهمال": خطأ ،
      "_resolved":
      "_integrity":
      "_shasum": "6926D1B194FBC737B8EED513756DE2FCDA7EA408" ،
      "_shrinkwrap": NULL ،
      "بن": فارغة ،
      "_id": "[email protected]"
    },
    "النوع": "نهائي المنتهى"
  }
}

سمة _shasum أعلاه 6926d1b194fbc737b8eed513756de2fcda7ea408 hash hash في حزمة tar ، ونعثر على 6926 القليلة المتمثلة في التجزئة.

تبدأ استراتيجية التخزين المؤقت أعلاه من إصدار NPM V5. }.

يوفر npm العديد من الأوامر لإدارة بيانات ذاكرة التخزين المؤقت:

npm cache add : التفسير الرسمي هو أن هذا الأمر يستخدم بشكل أساسي داخليًا بواسطة npm ، ولكن يمكن أيضًا استخدامه لإضافة ذاكرة التخزين المؤقت يدويًا إلى حزمة محددة.
npm cache clean --force حذف جميع البيانات في دليل ذاكرة التخزين المؤقت.
npm cache verify : تحقق من صحة وتكامل البيانات المخزنة مؤقتًا وتنظيف البيانات غير المرغوب فيها.

استنادًا إلى البيانات المخزنة مؤقتًا ، توفر NPM أوضاع التثبيت في وضع عدم الاتصال ، والتي هي كما يلي:

--prefer-offline : استخدم البيانات المخزنة أولاً.
--prefer-online : الأولوية لاستخدام بيانات الشبكة.
--offline تطلب الشبكة واستخدم البيانات المخزنة مؤقتًا.

3.5 سلامة الملف

ذكرنا تكامل الملف عدة مرات أعلاه ، فما هو التحقق من سلامة الملف؟

tarball shasum حزمة npm info ، يمكننا hash الحصول على قيمة hash التي يتم حسابها بواسطة npm لحزمة التبعية.

بعد تنزيل حزمة التبعية محليًا ، يحتاج هو أو هي إلى التأكد hash عدم وجود hash أثناء عملية التنزيل. هي نفسها ، تأكد من اكتمال التبعية التي تم تنزيلها.

3.6

الآن بعد اكتمال العملية الإجمالية ، دعونا نلخص العملية أعلاه:

تحقق من ملف .npmrc : الأولوية هي: ملف .npmrc على مستوى المشروع .npmrc ملف .npmrc .npmrc ملف
تحقق مما إذا كان هناك ملف lock في المشروع.
لا يوجد ملف lock :
- الحصول على معلومات الحزمة من مستودع npm عن بُعد
- وإنشاء شجرة
  - تبعية
  بناءً على package.json .
  - في دليل الجذر node_modules .
  - عند مواجهة الوحدة النمطية نفسها ، يتم الحكم على ما إذا كان إصدار الوحدة النمطية التي تم وضعها في شجرة التبعية تتطابق مع الوحدة النمطية الجديدة. تحت node_modules للوحدة الحالية.
- - شجرة
- - التبعية المنطقية ، وليس التثبيت الفعلي
- - لا يوجد أي ذاكرة التخزين المؤقت:
    - - فشل
    - npm تنزيل المستودع عن بُعد
    - من سلامة الحزمة
    - التحقق ومررات:
      - انسخ الحزمة التي تم تنزيلها إلى دليل ذاكرة التخزين npm
      - واستخراج الحزمة التي تم تنزيلها إلى node_modules وفقًا لهيكل التبعية .
  - node_modules
- node_modules
- lock
lock
- package.json package-lock.json .
- إذا لم يكن هناك تعارض ، فقم بتخطي عملية الحصول على معلومات الحزمة مباشرة وإنشاء شجرة تبعية ، وابدأ في البحث عن معلومات الحزمة في ذاكرة التخزين المؤقت.

تصف العملية المذكورة أعلاه العملية العامة npm install package --timing=true --loglevel=verbose npm install . عملية التثبيت وتفاصيل حزمة معينة.

3.7 الغزل

تم إصدار yarn في 2016 في ذلك الوقت package-lock.json كان npm في فترة V3 . من المطورين. في هذه المرحلة ، يولد yarn :

ما سبق هو مزايا yarn المذكورة على الموقع الرسمي ، والتي كانت لا تزال جذابة للغاية في ذلك الوقت. بالطبع ، yarn npm yarn lock وتجاوزت العديد من التحسينات. لا يزال التصميم جيدًا جدًا.

يستخدم yarn أيضًا التركيب المسطح yarn.lock npm v3 yarn.lock التبعيات

. هو ملف تلقائي.
# خيوط lockfile v1


[email protected]:
  نسخة "1.0.1"
  حل "https://registry.yarnpkg.com/base64-js/-/base64-js-1.0.1.tgz#6926d1b194fbc737b8eed513756de2fcda7e408"
  النزاهة sha1-asbrszt7xze47tutdw3i/np+pag =

base64-js@^1.0.2:
  نسخة "1.3.1"
  حل "https://registry.yarnpkg.com/base64-js/-/base64-js-1.3.1.tgz#58ece8cb75dd07e7eed08c736abc5fac4dbf8df1"
  النزاهة SHA512-MLQ4I2QO1YTVGWFWMCNGKO // JXAQUEZVWEKTJGQFM4JIK0KU+YTMFPLL8J+N5MSPOFJHWOAG+9YHB7BWAHM36G ==

buffer@^5.4.3:
  نسخة "5.4.3"
  تم حلها "https://registry.yarnpkg.com/buffer/-buffer-5.4.3.3
  النزاهة SHA512-ZVJ65TKFEIT3I6AJ5BIVJDZJJQQGS4O/SNOEZG1F1KEAP9NU2JCUDPWZRSJTHMZG0H7BZKN4RNQPIMHUXWX2A ==
  التبعيات:
    BASE64-JS "^1.0.2"
    IEEE754 "^1.1.4"

IEEE754@^1.1.4:
  نسخة "1.1.13"
  حل "https://registry.yarnpkg.com/ieee754/-/ieee754-1.1.13
  النزاهة SHA512-4VF7I2LYV/HAWERSO3XMLMKP5EZ83I+/CDLUXI/IGTS/O1SEJBNHTTNXZMRZFVOUQJ7LZJQHKETVPGSFDLWZTG ==

تجاهل^5.1.4:
  نسخة "5.1.4"
  حل "https://registry.yarnpkg.com/ignore/-ignore-5.1.4.tgz#84b7b3dbe64552b6ef0eca99f6743dbec6d97adf"

النزاهة

package-lock.json

json package-lock.json yarn.lock
yarn.lock لا يتم إصلاح رقم الإصدار من التبعية النيوترونية yarn.lock ، مما يعني أن yarn.lock وحده لا يمكنه تحديد بنية دليل node_modules ويجب تنسيقها مع ملف package.json . و package-lock.json يحتاج فقط إلى ملف واحد لتحديده.

تبدو استراتيجية التخزين المؤقت لـ yarn مشابهة جدًا لتخزين npm v5 . استخدم Command yarn cache dir لعرض دليل البيانات المخزنة مؤقتًا:

بشكل افتراضي ، يستخدم yarn وضع prefer-online ، مما يعني أن بيانات الشبكة يتم استخدامها أولاً.

ملخص:

آمل أنه بعد قراءة هذه المقالة ، سيساعدك ذلك على النحو التالي:

npm
التكوينات التفصيلية في pacakge.json لمزيد من الأفكار حول تكوين هندسة المشروع.
الإصدارات
npm npm install package-lock.json