Відповіді:
Відповідь не така проста, як пропонує Альберто Закканні. Якщо ви розробляєте додатки (особливо корпоративні додатки), включаючи node_modules у вашому git repo - це вибір, який альтернативу ви вибрали, залежно від вашого проекту.
Оскільки він дуже добре сперечався проти node_modules, я сконцентруюся на аргументах для них.
Уявіть, що ви щойно закінчили корпоративну програму, і вам доведеться підтримувати її протягом 3-5 років. Ви точно не хочете залежати від чийого-небудь модуля npm, який завтра може зникнути, і ви більше не можете оновлювати додаток.
Або у вас є ваші приватні модулі, недоступні в Інтернеті, і ви не можете створити свою програму в Інтернеті. Або, можливо, ви не хочете з певних причин залежати від остаточного нарощування послуги npm.
Ви можете знайти плюси і мінуси в цій статті Addy Osmani (хоча йдеться про Bower, це майже однакова ситуація). І закінчу цитатою з домашньої сторінки Бауера та статті Адді:
"Якщо ви не створюєте пакет, який призначений для споживання іншими (наприклад, ви створюєте веб-додаток), ви завжди повинні перевіряти встановлені пакети на контроль джерел."
git checkout foo. Якщо node_modules не під VCS - перемикання гілок є git checkout foo ; npm installі все, що потрібно для вашої поточної версії NPM;)
Деталі модулів зберігаються в packages.json, цього достатньо. Не потрібно перевіряти node_modules.
Люди звикли зберігати node_modulesу контролі версій для блокування залежностей модулів, але з обробкою скорочень npm, яка більше не потрібна.
Ще одне виправдання для цього, як @ChrisCM написав у коментарі:
Також варто відзначити, що будь-які модулі, що передбачають вбудовані розширення, не працюватимуть архітектурою для архітектури, а потребують відновлення. Надання конкретного обґрунтування щодо НЕ включення їх у репо.
Я б рекомендував не перевіряти node_modules через такі пакети, як PhantomJS і node-sass, наприклад, які встановлюють відповідний бінарний файл для поточної системи.
Це означає, що якщо один Dev працює npm installв Linux і перевіряє node_modules - він не буде працювати для іншого Dev, який клонує репо в Windows.
Краще перевірити в тарболах, які npm встановлюють завантаження, і вказати npm-shrinkwrap.jsonна них. Ви можете автоматизувати цей процес за допомогою термоусадочного пакета .
npm install --global shrinkpackсама по собі не має відкладеної слабкості, вимагаючи інших пакетів, за допомогою яких потім встановити зменшені пакети? Це суперечить пораді Адді.
shrinkpackпотрібна залежність від того, щоб потім надійно встановити залежності побудови. Тому сама установка інструменту збірки стає слабкістю аргументу проти подання всіх залежностей збірки на контроль версій.
Я бачу, ця тема досить стара. Але я пропускаю деяке оновлення аргументів, наданих тут через зміну ситуації в екосистемі npm.
Я завжди радив би не ставити node_modules під контроль версій. Майже всі переваги від цього, перелічені в контексті прийнятої відповіді, на сьогоднішній день є досить застарілими.
Опубліковані пакети вже не можна легко відкликати з реєстру npm. Тож вам не доведеться боятися втрачати залежності, на які покладався ваш проект раніше.
Встановлення файлу package-json.lock у VCS допомагає із часто оновлюваними залежностями, що, ймовірно, призводить до різних налаштувань, хоча спирається на той самий файл package.json.
Отже, розміщення node_modules у VCS у випадку наявності інструментів збірки в режимі офлайн може вважатися єдиним, що залишився придатним для використання. Однак, node_modules зазвичай росте досить швидко. Будь-яке оновлення змінить багато файлів. І це впливає на сховища по-різному. Якщо ви дійсно вважаєте, що довгострокові наслідки можуть також стати перешкодою.
Централізоване VCS, як svn, вимагає передачі довірених і перевірених файлів по мережі, що буде повільним, як пекло, якщо мова заходить про перевірку або оновлення папки node_modules.
Що стосується git, то велика кількість додаткових файлів моментально забруднить сховище. Майте на увазі, що git не відстежує відмінності між версіями будь-якого файлу, але зберігає копії будь-якої версії файлу, як тільки один символ зміниться. Кожне оновлення будь-якої залежності призведе до іншого великого набору змін. Ваш сховище git швидко зросте величезним через це впливає на резервне копіювання та віддалену синхронізацію. Якщо ви вирішите видалити node_modules з git сховища пізніше, це все ще є частиною цього з історичних причин. Якщо ви розповсюдили своє сховище git на якомусь віддаленому сервері (наприклад, для резервного копіювання), його очищення - ще одна болюча і схильна до помилок задача, з якою ви будете працювати.
Таким чином, якщо ви дбаєте про ефективні процеси та хочете, щоб речі були "малі", я б скоріше скористався окремим сховищем артефактів, таким як Nexos Repository (або просто якийсь HTTP-сервер із ZIP-архівами), який надає раніше завантажений набір залежностей для завантаження.
Не відстеження за node_modulesдопомогою керування джерелом є правильним вибором, оскільки деякі модулі NodeJS, як, наприклад, драйвер MongoDB NodeJS, використовують додатки NodeJS C ++. Ці доповнення компілюються під час запуску npm installкоманди. Отже, коли ви відстежуєте node_modulesкаталог, ви можете випадково скористатися специфічним для ОС бінарним файлом.
Я погоджуюся з ivoszz, що іноді корисно перевірити папку node_modules, але ...
сценарій 1:
Один сценарій: Ви використовуєте пакет, який видаляється з npm. Якщо у вас є всі модулі в папці node_modules, це не буде для вас проблемою. Якщо ви маєте лише ім'я пакета в package.json, ви більше не можете його отримати. Якщо пакет менше 24 годин, ви можете легко вийняти його з npm. Якщо це старше 24 годин, то вам потрібно зв’язатися з ними. Але:
Якщо ви звернетесь до служби підтримки, вони перевірять, чи не призведе до видалення цієї версії вашого пакета будь-які інші встановлення. Якщо це так, ми його не будемо видаляти.
Тож шанси на це низькі, але є сценарій 2 ...
сценарій 2:
Інший сценарій, коли це так: Ви розробляєте корпоративну версію свого програмного забезпечення або дуже важливого програмного забезпечення та записуєте у свій package.json:
"dependencies": {
"studpid-package": "~1.0.1"
}
Ви використовуєте метод function1(x)цього пакету.
Тепер розробники studpid-пакету перейменують метод function1(x)на function2(x)і вони роблять помилку ... Вони змінюють версію свого пакета з 1.0.1на 1.1.0. Це проблема, тому що, коли ви дзвоните npm installнаступного разу, ви приймете версію, 1.1.0оскільки використовували тильду ( "studpid-package": "~1.0.1").
function1(x)Зараз дзвінки можуть спричинити помилки та проблеми.
Але:
Переміщення всієї папки node_modules (часто більше 100 Мб) до вашого сховища, обійдеться вам у пам'яті. Кілька кб (лише пакет.json) порівняно із сотнями МБ (package.json & node_modules) ... Подумайте про це.
Ви могли це зробити / повинні подумати про це, якщо:
програмне забезпечення дуже важливе.
це коштує вам грошей, коли щось не вдається.
ви не довіряєте реєстру npm. npm є централізованим і теоретично може бути вимкнено.
Вам не потрібно публікувати папку node_modules у 99,9% випадків, якщо:
ви розробляєте програмне забезпечення лише для себе.
ви щось запрограмували і просто хочете опублікувати результат на GitHub, тому що хтось інший може бути зацікавлений у цьому.
Якщо ви не хочете, щоб node_modules знаходилися у вашому сховищі, просто створіть .gitignoreфайл і додайте рядок node_modules.
npm installв Windows та MacOS може генерувати різні файли (файли, залежні від ОС) у деяких пакетах. Але я не впевнений у цьому. Чи може хтось переконатися, що це правда?
package-lock.json. Якщо в майбутньому виникає проблема з оновленням студ-пакету, ви можете відкатати файл блокування, щоб дізнатися точну версію, яка працювала для вас.
Я хотів би запропонувати середину дорожньої альтернативи.
node_modulesв git.package-lock.jsonфайл, щоб прибити свої версії залежності.У рідкісних випадках, коли ви не можете отримати доступ до NPM (або інших реєстрів, які ви використовуєте) або певного пакету в NPM, у вас є копія node_modules і ви можете продовжувати працювати, поки не відновите доступ.
Ще одне, що слід врахувати: реєстрація node_modulesускладнює / неможливо використовувати різницю між dependenciesта devDependencies.
З іншого боку, можна сказати, що це заспокійливо підштовхувати до виробництва саме той самий код, який пройшов тести - так у тому числі devDependencies.