آموزش Node.js: راهنمای package.json — بخش چهارم

۵۲۴ بازدید

آخرین به‌روزرسانی: ۱۸ شهریور ۱۴۰۲

زمان مطالعه: ۱۰ دقیقه

آموزش Node.js: راهنمای package.json — بخش چهارم

فایل package.json یک عنصر کلیدی در بسیاری از کدبیس‌های اپلیکیشن مبتنی بر اکوسیستم Node.js است. اگر با جاوا اسکریپت کار کرده باشید یا حتی با یک پروژه پروژه فرانت‌اند برای مدتی مشغول بوده‌اید، قطعاً با فایل package.json سروکار داشته‌اید. فایل package.json نوعی مانیفست برای پروژه محسوب می‌شود.

این فایل می‌تواند کارهای زیادی انجام دهد که در برخی موارد کاملاً نامربوط به هم هستند. برای نمونه فایل package.json یک ریپازیتوری مرکزی برای ابزارها است. همچنین جایی است که npm و yarn نام‌ها و نسخه‌های پکیج‌هایی که نصب شده‌اند را نگه‌داری می‌کنند. برای مطالعه بخش قبلی از این مجموعه مقالات آموزشی، می‌توانید به لینک زیر رجوع کنید:

آموزش Node.js: معرفی NPM --- بخش سوم

ساختار فایل

در این بخش مثالی از فایل package.json را ملاحظه می‌کنید:

1{
2}

چنان که می‌بینید این فایل خالی است! هیچ الزام ثابتی در مورد محتوایی که باید در فایل package.json برای یک اپلیکیشن نوشت وجود ندارد. تنها الزام این است که قالب JSON رعایت شود، چون در غیر این صورت از سوی برنامه‌هایی که تلاش می‌کنند مشخصه‌های آن را به صورت برنامه‌نویسی شده پردازش کنند قابل خواندن نخواهد بود.

فیلم آموزش مقدماتی نود جی اس Node.js در فرادرس

کلیک کنید

اگر مشغول ساخت یک پکیج Node.js باشید که بخواهید آن را روی npm توزیع کنید، همه چیز به سرعت تغییر می‌یابند و باید مجموعه‌ی از مشخصه‌ها را داشته باشید که به افراد دیگر برای استفاده از پکیج کمک می‌کنند. در این خصوص در ادامه بیشتر توضیح خواهیم داد. به مثال زیر از یک فایل package.json توجه کنید:

1{
2  "name": "test-project"
3}

مثالی از ساختار فایل package.json

این فایل مشخصه name را تعریف می‌کند که نام اپلیکیشن یا پکیج را مشخص می‌کنند و شامل نام پوشه‌ای هستند که فایل در آن قرار دارد. در ادامه مثال بسیار پیچیده‌تری را شاهد هستیم که آن را از یک اپلیکیشن نمونه Vue.js استخراج کرده‌ایم:

1{
2  "name": "test-project",
3  "version": "1.0.0",
4  "description": "A Vue.js project",
5  "main": "src/main.js",
6  "private": true,
7  "scripts": {
8    "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js",
9    "start": "npm run dev",
10    "unit": "jest --config test/unit/jest.conf.js --coverage",
11    "test": "npm run unit",
12    "lint": "eslint --ext .js,.vue src test/unit",
13    "build": "node build/build.js"
14  },
15  "dependencies": {
16    "vue": "^2.5.2"
17  },
18  "devDependencies": {
19    "autoprefixer": "^7.1.2",
20    "babel-core": "^6.22.1",
21    "babel-eslint": "^8.2.1",
22    "babel-helper-vue-jsx-merge-props": "^2.0.3",
23    "babel-jest": "^21.0.2",
24    "babel-loader": "^7.1.1",
25    "babel-plugin-dynamic-import-node": "^1.2.0",
26    "babel-plugin-syntax-jsx": "^6.18.0",
27    "babel-plugin-transform-es2015-modules-commonjs": "^6.26.0",
28    "babel-plugin-transform-runtime": "^6.22.0",
29    "babel-plugin-transform-vue-jsx": "^3.5.0",
30    "babel-preset-env": "^1.3.2",
31    "babel-preset-stage-2": "^6.22.0",
32    "chalk": "^2.0.1",
33    "copy-webpack-plugin": "^4.0.1",
34    "css-loader": "^0.28.0",
35    "eslint": "^4.15.0",
36    "eslint-config-airbnb-base": "^11.3.0",
37    "eslint-friendly-formatter": "^3.0.0",
38    "eslint-import-resolver-webpack": "^0.8.3",
39    "eslint-loader": "^1.7.1",
40    "eslint-plugin-import": "^2.7.0",
41    "eslint-plugin-vue": "^4.0.0",
42    "extract-text-webpack-plugin": "^3.0.0",
43    "file-loader": "^1.1.4",
44    "friendly-errors-webpack-plugin": "^1.6.1",
45    "html-webpack-plugin": "^2.30.1",
46    "jest": "^22.0.4",
47    "jest-serializer-vue": "^0.3.0",
48    "node-notifier": "^5.1.2",
49    "optimize-css-assets-webpack-plugin": "^3.2.0",
50    "ora": "^1.2.0",
51    "portfinder": "^1.0.13",
52    "postcss-import": "^11.0.0",
53    "postcss-loader": "^2.0.8",
54    "postcss-url": "^7.2.1",
55    "rimraf": "^2.6.0",
56    "semver": "^5.3.0",
57    "shelljs": "^0.7.6",
58    "uglifyjs-webpack-plugin": "^1.1.1",
59    "url-loader": "^0.5.8",
60    "vue-jest": "^1.0.2",
61    "vue-loader": "^13.3.0",
62    "vue-style-loader": "^3.0.1",
63    "vue-template-compiler": "^2.5.2",
64    "webpack": "^3.6.0",
65    "webpack-bundle-analyzer": "^2.9.0",
66    "webpack-dev-server": "^2.9.1",
67    "webpack-merge": "^4.1.0"
68  },
69  "engines": {
70    "node": ">= 6.0.0",
71    "npm": ">= 3.0.0"
72  },
73  "browserslist": [
74    "> 1%",
75    "last 2 versions",
76    "not ie <= 8"
77  ]
78}

در این فایل موارد زیادی وجود دارند که نیاز به توضیح دارند:

Name – نام اپلیکیشن/پکیج را تعیین می‌کند.
version – نسخه کنونی را مشخص می‌سازد.
desctiption – توضیح خلاصه‌ای در مورد اپلیکیشن/پکیج است.
main – نقطه ورود اپلیکیشن را تعیین می‌کند.
private – اگر به صورت true تعیین شده باشد، از انتشار تصادفی اپلیکیشن/پکیج روی npm جلوگیری می‌کند.
scripts – مجموعه‌ای از اسکریپت‌های Node را تعریف می‌کند که می‌توان اجرا کرد.
dependencies – فهرستی از پکیج‌های npm را که به صورت وابستگی نصب شده‌اند تعیین می‌کند.
devDependencies – فهرستی از پکیج‌های npm را تعیین می‌کند که به صورت «وابستگی‌های توسعه» (development dependencies) نصب شده‌اند.
Engines – تعیین می‌کند که این پکیج/اپلیکیشن روی کدام نسخه‌های Node کار می‌کند.
Browserslist – برای تعیین نوع مرورگرها (و نسخه‌های آن‌ها) که می‌خواهید پشتیبانی شوند استفاده می‌شود.

همه مشخصه‌های فوق از سوی npm یا دیگر ابزارهایی که استفاده می‌کنیم، مورد بهره‌برداری قرار می‌گیرند.

تحلیل مشخصه‌ها

در این بخش مشخصه‌هایی را که می‌توان استفاده کرد به تفصیل بررسی می‌کنیم. ما در جاهای مختلف از عبارت «پکیج» (package) استفاده می‌کنیم، اما همان حالت در مورد اپلیکیشن‌های محلی که از پکیج‌ها استفاده نمی‌کنند نیز صدق می‌کند. اغلب این مشخصه‌ها تنها روی وب‌سایت npm استفاده می‌شوند و موارد دیگر از سوی اسکریپت‌هایی که با کد تعامل دارند مانند npm و نظایر آن مورد بهره‌برداری قرار می‌گیرند.

name

نام پکیج را تعیین می‌کند. مثالی از آن به صورت زیر است:

1"name": "test-project"

نام باید کمتر از 214 کاراکتر باشد و نباید فاصله داشته باشد و تنها می‌تواند شامل حروف، خط تیره (-) و زیرخط (_) باشد. دلیل این امر آن است که وقتی روی npm منتشر می‌شود یک URL خاص دریافت می‌کند که مبتنی بر همین مشخصه است. اگر بخواهید پکیج را به صورت عمومی روی گیت‌هاب منتشر کنید، همین واقعیت در مورد خصوصیت name برای نام ریپازیتوری گیت‌هاب نیز صادق است.

author

نام نویسندگان پکیج را فهرست می‌کند. مثالی از آن به صورت زیر است:

1{
2  "author": "Flavio Copes <flavio@flaviocopes.com> (https://flaviocopes.com)"
3}

این مشخصه می‌تواند با قالب زیر نیز استفاده شود:

1{
2  "author": {
3    "name": "Flavio Copes",
4    "email": "flavio@flaviocopes.com",
5    "url": "https://flaviocopes.com"
6  }
7}

contributors

همانند author، پروژه می‌تواند یک یا چند مشارکت‌کننده نیز داشته باشد. این مشخصه آرایه‌ای است که مشارکت‌کنندگان در پروژه را فهرست‌بندی می‌کند. مثالی از آن به صورت زیر است:

1{
2  "contributors": [
3    "Flavio Copes <flavio@flaviocopes.com> (https://flaviocopes.com)"
4  ]
5}

این مشخصه می‌تواند با قالب‌بندی زیر نیز باشد:

1{
2  "contributors": [
3    {
4      "name": "Flavio Copes",
5      "email": "flavio@flaviocopes.com",
6      "url": "https://flaviocopes.com"
7    }
8  ]
9}

bugs

این مشخصه ابزار «ردگیری مشکلات پکیج» (package issue tracker) را به طور عمده با صفحه issues گیت‌هاب مرتبط می‌سازد. مثالی از کاربرد این مشخصه به صورت زیر است:

1{
2  "bugs": "https://github.com/flaviocopes/package/issues"
3}

Homepage

صفحه اصلی پکیج را تعیین می‌کند. مثالی از آن به صورت زیر است:

1{
2  "homepage": "https://flaviocopes.com/package"
3}

version

تعیین‌کننده نسخه کنونی پکیج است. مثالی از آن به صورت زیر است:

1"version": "1.0.0"

این مشخصه امکان استفاده از نمادهای نسخه‌بندی معناشناختی (semver) را برای نسخه‌ها می‌دهد. منظور از نسخه‌بندی معنایی این است که نسخه‌های یک پکیج یا اپلیکیشن همواره با 3 عدد x.x.x بیان می‌شوند. عدد نخست این نسخه‌بندی عدد اصلی (major) است، عدد دوم نسخه فرعی (minor) و عدد سوم نیز وصله (patch) را نمایش می‌دهد.

این اعداد معنای خاصی دارند. انتشار یک نسخه که صرفاً اصلاح باگ باشد، یک نسخه وصله محسوب می‌شود. انتشار نسخه‌ای که تغییرهای منطبق با نسخه‌های قبل داشته باشد، یک انتشار فرعی محسوب می‌شود و انتشار نسخه‌ای که تغییرهای وارد آمده در پکیج موجب گسست آن از نسخه‌های قبلی شود، با عدد اصلی نمایش می‌یابد.

license

نشان‌دهنده لایسنس یا پروانه پکیج است. مثالی از آن به صورت زیر است:

1"license": "MIT"

keywords

این مشخصه شامل آرایه‌ای از کلیدواژه‌ها است که با پکیج مرتبط هستند. مثالی از آن به صورت زیر است:

1"keywords": [
2  "email",
3  "machine learning",
4  "ai"
5]

این کلیدواژه‌ها به پیدا شدن پکیج شما در زمان ناوبری در میان پکیج‌های مشابه یا در زمان گشتن در وب‌سایت npm کمک می‌کنند.

description

این مشخصه شامل توضیح کوتاهی از پکیج است. مثالی از آن به صورت زیر است:

1"description": "A package to work with strings"

این مشخصه به طور خاص در مواردی که تصمیم دارید پکیج خود را در npm منتشر کنید و افراد بتوانند بفهمند موضوع پکیج چیست، مفید خواهد بود.

repository

این مشخصه تعیین می‌کند که ریپازیتوری کجا قرار گرفته است. مثال از آن به صورت زیر است:

1"repository": "github:flaviocopes/testing"،

به پیشوند github دقت کنید. سرویس‌های پشتیبانی شده محبوب دیگری نیز وجود دارند:

1"repository": "gitlab:flaviocopes/testing"،
2
3"repository": "bitbucket:flaviocopes/testing"،

شما می‌توانید سیستم کنترل نسخه را به صورت صریح معرفی کنید:

1"repository": {
2  "type": "git",
3  "url": "https://github.com/flaviocopes/testing.git"
4}

شما می‌توانید از سیستم‌های کنترل نسخه متفاوتی استفاده کنید:

1"repository": {
2  "type": "svn",
3  "url": "..."
4}

main

نقطه ورود پکیج را تعیین می‌کند. زمانی که این پکیج را در یک اپلیکیشن ایمپورت می‌کنید، این همان نقطه‌ای خواهد بود که اپلیکیشن برای اکپسورت ماژول‌ها جستجو خواهد کرد. مثالی از آن به صورت زیر است:

1"main": "src/main.js"

private

اگر به صورت true تنظیم شده باشد، اپلیکیشن/پکیج نمی‌تواند به صورت تصادفی روی npm منتشر شود. مثالی از آن به صورت زیر است:

1"private": true

scripts

مجموعه‌ای از اسکریپت‌های node را تعریف می‌کند که می‌توان اجرا کرد. مثالی از آن به صورت زیر است:

1"scripts": {
2  "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js",
3  "start": "npm run dev",
4  "unit": "jest --config test/unit/jest.conf.js --coverage",
5  "test": "npm run unit",
6  "lint": "eslint --ext .js,.vue src test/unit",
7  "build": "node build/build.js"
8}

این اسکریپت‌ها اپلیکیشن‌های خط فرمان هستند. آن‌ها را می‌توان به شکل run XXXX یا yarn XXXX فراخوانی کرد که XXXX نام فرمان است. مثالی از آن به صورت زیر است:

npm run dev

شما می‌توانید از هر نامی که می‌خواهید برای یک فرمان استفاده کنید و اسکریپت‌ها به صورت تئوریک می‌توانند هر کاری را اجرا کنند.

dependencies

فهرستی از پکیج‌های نصب‌شده npm به عنوان وابستگی را تعیین می‌کند. زمانی که یک پکیج را با استفاده از npm یا yarn نصب می‌کنید:

npm install <PACKAGENAME>

yarn add <PACKAGENAME>

این پکیج به صورت خودکار در این فهرست قرار می‌گیرد. مثالی از آن به صورت زیر است:

1"dependencies": {
2  "vue": "^2.5.2"
3}

devDependencies

پکیج‌های npm را فهرست می‌کند که به صورت وابستگی‌های توسعه نصب شده‌اند. این موارد از dependencies که در بخش قبلی اشاره کردیم متفاوت هستند و پکیج‌هایی هستند که تنها در روی سیستم توسعه نصب می‌شوند و لازم نیست در توزیع نهایی کد وجود داشته باشند. زمانی که یک بسته را با استفاده از دستورهای npm یا yarn نصب می‌کنید:

npm install --dev <PACKAGENAME>

yarn add --dev <PACKAGENAME>

این پکیج به صورت خودکار در این فهرست قرار می‌گیرد. مثالی از آن به صورت زیر است:

1"devDependencies": {
2  "autoprefixer": "^7.1.2",
3  "babel-core": "^6.22.1"
4}

Engines

تعیین می‌کند که این پکیج/اپلیکیشن روی کدام نسخه‌ها از Node.js و دیگر فرمان‌ها کار می‌کند. مثالی از آن به صورت زیر است:

1"engines": {
2  "node": ">= 6.0.0",
3  "npm": ">= 3.0.0",
4  "yarn": "^0.13.0"
5}

browserslist

این مشخصه برای این استفاده می‌شود که مشخص شود کدام مرورگرها (و کدام نسخه از آن‌ها) پشتیبانی می‌شوند. این مشخصه از سوی Babel ،Autoprefixer و دیگر ابزارها پشتیبانی می‌شود تا تنها polyfill-ها و fallback-های مورد نیاز مرورگرهای هدف اضافه شوند. مثالی از آن به صورت زیر است:

1"browserslist": [
2  "> 1%",
3  "last 2 versions",
4  "not ie <= 8"
5]

این پیکربندی به آن معنی است که می‌خواهیم از 2 نسخه اصلی همه مرورگرهایی که دست‌کم 1% استفاده دارند به جز IE8 و پایین‌تر، پشتیبانی شود. آمار این مرورگرها از وب‌سایت CanIUse.com (+) استخراج می‌شود.

مشخصه‌های خاص دستور

فایل package.json می‌تواند میزبان پیکربندی خاص دستور، برای نمونه Babel ،ESLint و موارد دیگر باشد. هر یک از این موارد مشخصه خاصی مانند eslintConfig ،babel و موارد دیگر دارند. این مشخصه‌ها به نام مشخصه‌های خاص دستور شناخته می‌شوند و شیوه استفاده از آن‌ها را می‌توان در مستندات مربوط به دستور/پروژه یافت.

فیلم آموزش پروژه محور نود جی اس Node.js – ساخت چت روم ویدئویی در فرادرس

کلیک کنید

نسخه‌های پکیج

در بخش قبلی توضیح‌هایی در مورد اعداد نسخه‌ها مانند 3.0.0~ یا 0.13.0^ ارائه کردیم. شاید بپرسید معنی آن‌ها چیست و از کدام روش‌های دیگر برای توصیف نسخه می‌توان استفاده کرد. این نماد تعیین می‌کند که پکیج کدام به‌روزرسانی‌ها از آن وابستگی می‌پذیرد.

با فرض این که از semver استفاده می‌کنید، همه نسخه‌ها 3 رقم دارند که رقم نخست انتشار اصلی، دومی انتشار فرعی و سومی انتشار وصله است و قواعد زیر در مورد آن‌ها صدق می‌کند:

~: اگر عدد به صورت 0.13.0~ نوشته شود، بدین معنی است که می‌خواهید صرفاً انتشار وصله استفاده شود. در این حالت 0.13.1 درست است، اما 0.14.0 صدق نمی‌کند.
^: اگر عدد به صورت 0.13.0^ نوشته شده باشد، به این معنی است که انتشارهای وصله و فرعی نصب می‌شوند. برای نمونه 0.13.1، 0.14.0 و مواردی از این دست.
*: اگر عدد به صورت * نوشته باشد، به این معنی است که همه به‌روزرسانی‌ها شامل ارتقای نسخه‌های اصلی مورد قبول است.
>: این مقدار به آن معنی است که هر نسخه‌ای بالاتر از آن که تعیین شده مورد قبول است.
>=: نسخه‌ای معادل یا بالاتر از آن که تعیین شده مورد پذیرش است.
<=: نسخه‌ای معادل یا پایین‌تر از آن که تعیین شده مورد قبول است.
<: هر نسخه‌ای پایین‌تر از آن که اشاره کرده پذیرش می‌شود.

قواعد دیگری مانند زیر نیز وجود دارند:

no symbol: تنها نسخه خاصی که تعیین شده مورد پذیرش است.
Latest: از آخرین نسخه موجود استفاده می‌شود.

همچنین می‌توان برخی از قواعد فوق را برای داشتن بازه‌های خاص با هم ترکیب کرد برای نمونه:

.0.0 || >=1.1.0 <1.2.0

باعث می‌شود که از نسخه 1.0.0 یا انتشارهایی از 1.1.0 به بالا و پایین‌تر از 1.2.0 استفاده کنیم.

فایل package-lock.json

فایل package-lock.json به صورت خودکار در زمان نصب کردن پکیج‌های node ایجاد می‌شود. npm در نسخه 5 فایل package-lock.json را معرفی کرده است. در بخش قبلی در مورد فایل package.json که رواج و قدمت بیشتری دارد توضیحات مفصلی ارائه کردیم. هدف از این فایل آن است که ردپای نسخه دقیق هر پکیج که نصب می‌شود، حفظ شود، به طوری که محصول 100% به همان ترتیبی که پکیج‌ها از سوی نگه‌دارندگانشان به‌روزرسانی می‌شوند، قابل بازتولید باشنبد.

این فایل یک مشکل خاص را که فایل package.json حل‌نشده باقی گذاشته بود حل می‌کند. در فایل package.json می‌توان با استفاده از نمادگذاری semver تعیین کرد که می‌خواهیم کدام نسخه‌ها ارتقا یابند. برای نمونه به مثال‌های زیر توجه کنید:

اگر بنویسیم 0.13.0~ به این معنی است که می‌خواهیم انتشارهای وصله به‌روزرسانی شود، برای مثال 0.1.13.1، 0.14.0 و غیره.
اگر بنویسیم 0.13.0^ به این معنی است که می‌خواهیم انتشارهای وصله و فرعی به‌روزرسانی شوند یعنی 0.13.1، 0.14.0 و غیره.
اگر بنویسیم 0.13.0 به این معنی است که همواره می‌خواهیم آن نسخه دقیق تعیین شده مورد استفاده قرار گیرد.

چرا به آن نیاز داریم؟

ما معمولاً پوشه node_modules را به گیت کامیت نمی‌کنیم، چون عموماً پوشه بزرگی است و زمانی که پروژه را روی ماشین دیگری با استفاده از دستور npm install کپی کنیم، در صورتی که از ساختار ~ استفاده کرده باشیم یک نسخه وصله از پکیج انتشار می‌یابد که باید نصب شود. همین وضعیت در مورد ^ و انتشارهای فرعی نیز صدق می‌کند.

اگر عدد دقیق نسخه مثلاً به صورت 0.13.0 تعیین شده باشد، تحت تأثیر این مشکل قرار نخواهید گرفت. در هر حال ممکن است خود شما یا کس دیگری تلاش کنید تا پروژه را در سمت دیگر با اجرای دستور npm install مقداردهی اولیه کنید.

بدین ترتیب پروژه اصلی و پروژه مقداردهی شده جدید در عمل متفاوت خواهند بود. حتی اگر انتشار نسخه وصله یا فرعی، تغییرهای غیر گسسته‌ای در پکیج ایجاد کرده باشند، می‌دانیم که این وضعیت مستعد بروز باگ است.

فایل package-lock.json نسخه نصب‌شده کنونی از هر پکیج را ثابت می‌کند و npm از آن نسخه‌های دقیق در زمان استفاده از دستور npm install بهره خواهد گرفت. این مفهوم جدیدی نیست و ابزارهای مدیریت بسته در زبان‌های برنامه‌نویسی دیگر مثلاً کامپوزر در PHP سال‌ها است که از سیستم مشابهی استفاده می‌کنند. اگر پروژه عمومی باشد یا همکارانی داشته باشید و یا اگر از گیت به عنوان منبعی برای توزیع استفاده کنید، فایل package-lock.json باید به ریپازیتوری گیت کامیت شود تا افراد دیگر بتوانند آن را واکشی کنند.

نسخه‌های وابستگی‌ها در زمان اجرای دستور npm update در فایل package-lock.json به‌روزرسانی خواهند شد.

مثال

در این بخش مثالی از ساختار یک فایل package-lock.json ارائه می‌کنیم که در زمان اجرای دستور npm install cowsay در یک پوشه خالی به دست می‌آید:

1{
2  "requires": true,
3  "lockfileVersion": 1,
4  "dependencies": {
5    "ansi-regex": {
6      "version": "3.0.0",
7      "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-3.
80.0.tgz",
9      "integrity": "sha1-7QMXwyIGT3lGbAKWa922Bas32Zg="
10    },
11    "cowsay": {
12      "version": "1.3.1",
13      "resolved": "https://registry.npmjs.org/cowsay/-/cowsay-1.3.1.tgz"
14,
15      "integrity": "sha512-3PVFe6FePVtPj1HTeLin9v8WyLl+VmM1l1H/5P+BTTDkM
16Ajufp+0F9eLjzRnOHzVAYeIYFF5po5NjRrgefnRMQ==",
17      "requires": {
18        "get-stdin": "^5.0.1",
19        "optimist": "~0.6.1",
20        "string-width": "~2.1.1",
21        "strip-eof": "^1.0.0"
22      }
23    },
24    "get-stdin": {
25      "version": "5.0.1",
26      "resolved": "https://registry.npmjs.org/get-stdin/-/get-stdin-5.0.
271.tgz",
28      "integrity": "sha1-Ei4WFZHiH/TFJTAwVpPyDmOTo5g="
29    },
30    "is-fullwidth-code-point": {
31      "version": "2.0.0",
32      "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/
33is-fullwidth-code-point-2.0.0.tgz",
34      "integrity": "sha1-o7MKXE8ZkYMWeqq5O+764937ZU8="
35    },
36    "minimist": {
37      "version": "0.0.10",
38      "resolved": "https://registry.npmjs.org/minimist/-/minimist-0.0.10
39.tgz",
40      "integrity": "sha1-3j+YVD2/lggr5IrRoMfNqDYwHc8="
41    },
42    "optimist": {
43      "version": "0.6.1",
44      "resolved": "https://registry.npmjs.org/optimist/-/optimist-0.6.1.tgz",
45      "integrity": "sha1-2j6nRob6IaGaERwybpDrFaAZZoY=",
46      "requires": {
47        "minimist": "~0.0.1",
48        "wordwrap": "~0.0.2"
49      }
50    },
51    "string-width": {
52      "version": "2.1.1",
53      "resolved": "https://registry.npmjs.org/string-width/-/string-width-2.1.1.tgz",
54      "integrity": "sha512-nOqH59deCq9SRHlxq1Aw85Jnt4w6KvLKqWVik6oA9ZklXLNIOlqg4F2yrT1MVaTjAqvVwdfeZ7w7aCvJD7ugkw==",
55      "requires": {
56        "is-fullwidth-code-point": "^2.0.0",
57        "strip-ansi": "^4.0.0"
58      }
59    },
60    "strip-ansi": {
61      "version": "4.0.0",
62      "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-4.0.0.tgz",
63      "integrity": "sha1-qEeQIusaw2iocTibY1JixQXuNo8=",
64      "requires": {
65        "ansi-regex": "^3.0.0"
66      }
67    },
68    "strip-eof": {
69      "version": "1.0.0",
70      "resolved": "https://registry.npmjs.org/strip-eof/-/strip-eof-1.0.0.tgz",
71      "integrity": "sha1-u0P/VZim6wXYm1n80SnJgzE2Br8="
72    },
73    "wordwrap": {
74      "version": "0.0.3",
75      "resolved": "https://registry.npmjs.org/wordwrap/-/wordwrap-0.0.3.tgz",
76      "integrity": "sha1-o9XabNXAvAAI03I0u68b7WMFkQc="
77    }
78  }
79}

ما cowsay را نصب کرده‌ایم که به موارد زیر وابسته است:

get-stdin
optimist
string-width
strip-eof

چنان که در مشخصه requires می‌بینیم، این پکیج‌ها به نوبه خود نیازمند پکیج‌های دیگری هستند:

ansi-regex
is-fullwidth-code-point
minimist
wordwrap
strip-eof

این موارد در فایل با ترتیب الفبایی اضافه شده‌اند و هر یک فیلد version، یک فیلد resolved که به مکان پکیج اشاره دارد و یک رشته دارند که از آن برای اعتبارسنجی پکیج استفاده می‌کنیم. بدین ترتیب به پایان این بخش از سری مقالات آموزش Node.js می‌رسیم. در بخش بعدی در مورد برخی دستورهای دیگر npm صحبت خواهیم کرد.

برای مطالعه قسمت بعدی این مجموعه مطلب آموزشی روی لینک زیر کلیک کنید:

آموزش Node.js: آشنایی با npm و npx --- بخش پنجم

اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

بر اساس رای ۴ نفر

آیا این مطلب برای شما مفید بود؟

اگر بازخوردی درباره این مطلب دارید یا پرسشی دارید که بدون پاسخ مانده است، آن را از طریق بخش نظرات مطرح کنید.

ثبت نظر

منابع:

freecodecamp

میثم لطفی (+)

«میثم لطفی» در رشته‌های ریاضیات کاربردی و مهندسی کامپیوتر به تحصیل پرداخته و شیفته فناوری است. وی در حال حاضر علاوه بر پیگیری علاقه‌مندی‌هایش در رشته‌های برنامه‌نویسی، کپی‌رایتینگ و محتوای چندرسانه‌ای، در زمینه نگارش مقالاتی با محوریت نرم‌افزار با مجله فرادرس همکاری دارد.

نظر شما چیست؟

برچسب‌ها