Ответы:
Ответ не так прост, как предполагает Альберто Закканьи. Если вы разрабатываете приложения (особенно корпоративные приложения), включение узловых модулей в ваш git-репозиторий является жизнеспособным выбором, и выбор альтернативы зависит от вашего проекта.
Поскольку он очень хорошо спорил против node_modules, я сосредоточусь на аргументах для них.
Представьте, что вы только что завершили работу с корпоративным приложением, и вам придется поддерживать его в течение 3-5 лет. Вы определенно не хотите зависеть от чьего-то модуля npm, который завтра может исчезнуть, и вы больше не можете обновлять свое приложение.
Или у вас есть ваши личные модули, которые не доступны из Интернета, и вы не можете создать свое приложение в Интернете. Или, может быть, по некоторым причинам вы не хотите зависеть от вашей окончательной сборки службы npm.
Вы можете найти плюсы и минусы в этой статье Addy Osmani (хотя речь идет о Бауэре, это почти та же ситуация). И я закончу цитатой с домашней страницы Бауэра и статьи Адди:
«Если вы не создаете пакет, который предназначен для использования другими (например, вы создаете веб-приложение), вы всегда должны проверять установленные пакеты в системе контроля версий».
git checkout foo. Если node_modules не находятся под VCS - переключение ветвей есть git checkout foo ; npm installи все, что требуется от текущей версии NPM;)
Детали модулей хранятся в packages.json, этого достаточно. Там нет необходимости регистрироваться node_modules.
Раньше люди хранили node_modulesконтроль версий для блокировки зависимостей модулей, но с npm shrinkwrap это больше не нужно.
Еще одно оправдание этому пункту, как @ChrisCM написал в комментарии:
Также стоит отметить, что любые модули, которые включают собственные расширения, не будут переводить архитектуру в архитектуру и должны быть перестроены. Предоставление конкретного обоснования НЕ включения их в репо.
Я бы рекомендовал не проверять в node_modules из-за таких пакетов, как PhantomJS и node-sass, например, которые устанавливают соответствующий двоичный файл для текущей системы.
Это означает, что если один Dev работает npm installв Linux и проверяет наличие node_modules - он не будет работать для другого Dev, который клонирует репозиторий в Windows.
Лучше проверить в tar-архивах, которые устанавливают npm, и указать npm-shrinkwrap.jsonна них. Вы можете автоматизировать этот процесс с помощью shrinkpack .
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, такие как драйвер NodeJS MongoDB, используют дополнения 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-package переименовывают метод 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 МБ) в ваш репозиторий обойдется вам в пространство памяти. Несколько КБ (только package.json) по сравнению с сотнями МБ (package.json & node_modules) ... Подумайте об этом.
Вы можете сделать это / должны подумать об этом, если:
программное обеспечение очень важно.
это стоит ваших денег, когда что-то не получается.
Вы не доверяете реестру npm. npm централизован и теоретически может быть отключен.
Вам не нужно публиковать папку node_modules в 99,9% случаев, если:
Вы разрабатываете программное обеспечение только для себя.
Вы что-то запрограммировали и просто хотите опубликовать результат на GitHub, потому что это может заинтересовать кого-то другого.
Если вы не хотите, чтобы node_modules были в вашем хранилище, просто создайте .gitignoreфайл и добавьте строку node_modules.
npm installWindows и MacOS может генерировать разные файлы (файлы, зависящие от ОС) в некоторых пакетах. Но я не уверен в этом. Может кто-нибудь проверить, что это правда?
package-lock.json. Если в будущем возникнет проблема с обновлением studpid-package, вы можете откатить файл блокировки, чтобы узнать точную версию, которая сработала для вас.
Я хотел бы предложить середину дорожной альтернативы.
node_modulesв мерзавец.package-lock.jsonфайл, чтобы записать версии зависимостей.В редких случаях, когда вы не можете получить доступ к NPM (или другим используемым вами реестрам) или конкретному пакету в NPM, у вас есть копия node_modules, и вы можете продолжать работать, пока не восстановите доступ.
Еще одна вещь, которую стоит учесть: регистрация node_modulesусложняет / делает невозможным использование разницы между dependenciesи devDependencies.
Однако, с другой стороны, можно сказать, что отрадно подтолкнуть к созданию точно такой же код, который прошел тестирование - включая, в том числе devDependencies.