Если папка node_modules "будет включена в репозиторий git

Мне интересно, следует ли отслеживать node_modules в нашем репо или делать установку npm при проверке кода?

ОТВЕТЫ

Ответ 1

Ответ не так прост, как предполагает Альберто Закканьи. Если вы разрабатываете приложения (особенно корпоративные приложения), включение узловых модулей в ваш git-репозиторий является жизнеспособным выбором, и выбор альтернативы зависит от вашего проекта.

Поскольку он очень хорошо спорил против node_modules, я сосредоточусь на аргументах для них.

Представьте, что вы только что завершили работу с корпоративным приложением, и вам придется поддерживать его в течение 3-5 лет. Вы определенно не хотите зависеть от чьего-то npm-модуля, который завтра может исчезнуть, и вы больше не можете обновлять свое приложение.

Или у вас есть ваши личные модули, которые не доступны из Интернета, и вы не можете создать свое приложение в Интернете. Или, может быть, по каким-то причинам вы не хотите зависеть от окончательной сборки службы npm.

Вы можете найти плюсы и минусы в этой статье Адди Османи (хотя речь идет о Бауэре, ситуация почти такая же). И я закончу цитатой с домашней страницы Бауэра и статьи о Addy:

"Если вы не создаете пакет, предназначенный для использования другими (например, вы создаете веб-приложение), вы всегда должны проверять установленные пакеты в источник контроля.

Ответ 2

Информация о модулях хранится в packages.json, этого достаточно. Нет необходимости проверять node_modules.

Люди использовали для хранения node_modules в управлении версиями для блокировки зависимостей модулей, но с npm shrinkwrap, который больше не нужен.

Еще одно оправдание для этого момента, как @ChrisCM написал в комментарии:

Также стоит отметить, что любые модули, которые содержат собственные расширения, не будут работать с архитектурой архитектуры и должны быть перестроены. Предоставление конкретного обоснования для НЕ, включая их в репо.

Ответ 3

Я бы рекомендовал не проверять в node_modules из-за таких пакетов, как PhantomJS и node -sass, которые устанавливают соответствующий бинарный файл для текущей системы.

Это означает, что если один Dev запускает npm install в Linux и проверяет в node_modules - он не будет работать для другого Dev, который клонирует репо в Windows.

Лучше проверить в tarballs, где npm устанавливает загрузку и нажимает npm-shrinkwrap.json на них. Вы можете автоматизировать этот процесс, используя shrinkpack.

Ответ 4

Не отслеживание node_modules с контролем источника является правильным выбором, потому что некоторые модули NodeJS, такие как драйвер MongoDB NodeJS, используют надстройки NodeJS С++. Эти надстройки скомпилированы при запуске команды npm install. Поэтому, когда вы отслеживаете каталог node_modules, вы можете случайно записать конкретный двоичный файл OS.

Ответ 5

Эта тема довольно старая, я вижу. Но мне не хватает некоторых обновлений приведенных здесь аргументов из-за изменившейся ситуации в экосистеме npm.

Я бы всегда советовал не ставить node_modules под контроль версий. Практически все преимущества, перечисленные в контексте принятого ответа, устарели.

  1. Опубликованные пакеты больше нельзя отозвать из реестра npm. Так что вам не нужно бояться потерять зависимости, на которые раньше полагался ваш проект.

  2. Помещение файла 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-архивами), предоставляющий некоторый ранее извлеченный набор зависимостей для загрузки.

Ответ 6

Я согласен с ivoszz, что иногда полезно проверять папку node_modules, но...

сценарий 1:

Один сценарий: Вы используете пакет, который удаляется из npm. Если у вас есть все модули в папке node_modules, то это не будет проблемой для вас. Если у вас есть только имя пакета в package.json, вы больше не сможете его получить. Если пакет менее 24 часов, вы можете легко удалить его из npm. Если он старше 24 часов, то вам необходимо связаться с ними. Но:

Если вы обратитесь в службу поддержки, они проверит, не нарушит ли удаление этой версии вашего пакета какие-либо другие установки. Если это так, мы не будем его удалять.

читать дальше

Так что шансы на это невелики, но есть сценарий 2...

сценарий 2:

Другой сценарий, где это так: Вы разрабатываете корпоративную версию своего программного обеспечения или очень важного программного обеспечения и пишете в своем package.json:

"dependencies": {
    "studpid-package": "~1.0.1"
}

Вы используете метод function1(x) этого пакета.

Теперь разработчики шипованного пакета переименовывают метод 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.

Ответ 7

Еще одна вещь, которую следует учитывать: проверка node_modules затрудняет/невозможно использовать разницу между dependencies и devDependencies.

С другой стороны, однако, можно сказать, что это обнадеживает, чтобы вытолкнуть на производство тот же самый код, который прошел тесты, - включая включение devDependencies.

Ответ 8

Нет необходимости регистрировать node_modules, если в package.json указаны зависимости. Любой другой программист может просто получить его, выполнив установку npm, и npm достаточно умен, чтобы сделать node_modules в вашем рабочем каталоге для проекта.

Ответ 9

Я хотел бы предложить альтернативу на середине пути.

  1. Не добавляйте node_modules в git.
  2. Используйте файл package-lock.json, чтобы зафиксировать версии зависимостей.
  3. В вашем CI или процессе выпуска, когда вы выпускаете версию, сделайте копию папки node_modules и сделайте резервную копию (например, в облачном хранилище).

В редких случаях, когда вы не можете получить доступ к NPM (или другим используемым вами реестрам) или конкретному пакету в NPM, у вас есть копия node_modules, и вы можете продолжать работать, пока не восстановите доступ.

Ответ 10

Протестировано в Windows для Mac ios

Если вы сделали все файлы в репозитории Git, кроме " node_modules".
Вы можете Git Clone и просто запустить команду npm install, чтобы автоматически получить папку node_modules "из файла package.json.

Убедитесь, что вы зафиксировали файл package.json, чтобы автоматически или напрямую получать зависимые модули из npm package manager.