npm install - одна з найпопулярніших операцій з npm, але це навіть не верхівка айсбергу, це сніжинка, що лежить зверху нього. В цій статті ви дізнаєтеся про найкращі практики використання npm: від створення вашого проекту до його розгортання.
0. Познайомтесь з вашим npm
Перед подальшим використанням слід знати з чим (а точніше з якою версією) ви маєте справу.
Версія npm
Щоб отримати версію npm слід виконати наступну команду:
$ npm --version
2.13.2
Більше того, він може показати вашу версію Node.js, OpenSSL чи рушія V8:
$ npm version
{ bleak: '1.0.4',
npm: '2.15.0',
ares: '1.10.1-DEV',
http_parser: '2.5.2',
icu: '56.1',
modules: '46',
node: '4.4.2',
openssl: '1.0.2g',
uv: '1.8.0',
v8: '4.5.103.35',
zlib: '1.2.8' }
npm help
Як і більшість інструментів командного рядка, npm має вбудовану довідку.
$ npm help test
NAME
npm-test - Test a package
SYNOPSIS
npm test [-- <args>]
aliases: t, tst
DESCRIPTION
This runs a package's "test" script, if one was provided.
To run tests as a condition of installation, set the npat config to true.
1. Починайте нові проекти з npm init
При створенні нового проекту npm init в інтерактивній формі допоможе створити файл package.json, зазвичай це краще ніж робити все самому.
$ npm init --yes
Якщо ви запустите $ npm init --yes, це створить файл package.json з значеннями за замовчуванням. Встановити їх можна так:
npm config set init.author.name YOUR_NAME
npm config set init.author.email YOUR_EMAIL
2. А ви вмієте шукати пакети?
Пошук потрібного пакету іноді стає цілим випробуванням, адже їх сотні і тисячі. Давайте для прикладу оберемо модуль для http-запитів.
Полегшити цю задачу може сайт npms.io. Він також надає такі показники як якість, популярність та підтримка. Все це підраховується за купою показників, як от чи має модуль старі залежності, чи є налаштовані лінтери, який відсоток покриття коду тестами чи коли відбувся останній комміт.
3. Досліджуйте ваші пакети
Коли ви вибрали потрібний модуль (в нашому випадку request) потрібно поглянути на документацію та відкриті заявки (issues), щоб краще розуміти з чим ми маємо справу. Пам'ятайте, що чим більше пакетів ви використовуєте, тим більший ризик, що в вашому додатку будуть дірки в безпеці. Більше про безпеку і npm тут.
Щоб відкрити домашню сторінку проекту:
$ npm home request
Щоб перевірити відкриті заявки:
$ npm bugs request
Якщо просто хочете перевірити git—репозитарій пакету:
$ npm repo request
4. Збереження залежностей
Коли ви нарешті вибрали пакет, слід додати його до свого проекту. Простіше всього це зробити за допомогою npm install request.
А ще краще відразу додавати його до файлу package.json:
$ npm install request --save
Це збереже назву пакету і його версію з префіксом ^, що дозволяє оновлювати лише мінорні версії (1.1.2 => 1.2.0, але не 1.1.0 => 2.0.0). Щоб змінити цю поведінку:
$ npm config set save-prefix='~'
А якщо вам потрібні конкретні версії пакетів, в взагалі можете заборонити оновлення:
$ npm config set save-exact true
5. Заблокуйте ваші залежності
Навіть якщо ви заблокували оновлення як вказано вище, вам все ще потрібно бути обережним, адже більшість розробників цього не робить.
Це стає проблемою при розгортанні, коли на локальній та віддаленій машині в вас різні версії залежностей. І добре, якщо в новій версії не буде якогось багу, що не відтворюється на локальній машині.
Щоб вирішити цю проблему використовуйте npm shrinkwrap, що створить файл npm-shrinkwrap.json, що буде містити незаморожені версії залежностей вашого проекту, а й заморожені версії залежностей ваших залежностей, і так далі. І при наступному виклику npm install у вас буде таке ж саме оточення як і на локальній машині.
6. Перевіряйте ваші залежності
Щоб перевірити чи немає серед ваших залежностей застарілих, слід виконати наступну команду:
$ npm outdated
conventional-changelog 0.5.3 0.5.3 1.1.0 @risingstack/docker-node
eslint-config-standard 4.4.0 4.4.0 6.0.1 @risingstack/docker-node
eslint-plugin-standard 1.3.1 1.3.1 2.0.0 @risingstack/docker-node
rimraf 2.5.1 2.5.1 2.5.4 @risingstack/docker-node
З ростом проекту це стає досить складно робити, але на щастя є готові сервіси що роблять це за вас. Наприклад, Greenkeeper, який надішле pull request коли оновиться якась із ваших залежностей.
7. Ніяких devDepenendencies на продакшені
Залежності для розробки називаються так не спроста. Вам не потрібно встановлювати їх на сервері. Пам'ятайте, що чим менше модулів, тим менше потенційних дірок в безпеці. Щоб встановити залежності потрібні для роботи:
$ npm install --production
Або ви можете встановити значення змінній оточення NODE_ENV:
$ NODE_ENV=production npm install
8. Безпека, безпека і ще раз безпека
Коли ви використовуєте npm зі своїм аккаунтом, токен зберігається в файлі .npmrc. Багато розробників зберігають свої dotfiles на гітхабі, зараз там купа .npmrc, в яких є токен. Будьте обережні при публікації своїх dotfiles.
Також не публікуйте приватні файли. При публікації npm ігнорує файли описані в .gitignore. Але якщо є файл .npmignore, npm не звертає уваги на .gitignore, їх зміст не об'єднується.
9. Локальні пакети
Коли ви розробляєте свої пакети, ви спочатку захочете випробувати його на якомусь з ваших проектів без завантаження до глобального — репозитарію. Саме для цього існує npm link. Коли цю команду викликають з директорії проекту вона створює символічне посилання в глобальному каталозі. Тепер встановлення цього пакету можливе в іншому за допомогою команди npm link package-name:
# створення посилання в глобальному каталозі
/projects/request $ npm link
# створити посилання на request в node_modules
/projects/my-server $ npm link request
# тепер виклик require('request')
# буде імпортувати модуль з projects/request
Ще немає коментарів