Должна ли папка "node modules" быть включена в репозиторий git

Question

Должна ли папка "node modules" быть включена в репозиторий git

Мне интересно, должны ли мы отслеживать node_modules в нашем РЕПО или выполнять установку npm при проверке кода?

1192 7

git version-control node.js npm

7 ответов:

Comments

Ничего не найдено.

ivoszz · Accepted Answer · 2017-10-20 05:37:57

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

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

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

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

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

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

Alberto Zaccagni · Accepted Answer · 2015-01-13 15:37:41

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

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

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

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

fold_left · Accepted Answer · 2016-07-15 11:22:04

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

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

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

M.Z. · Accepted Answer · 2017-07-26 22:13:04

не отслеживая node_modules с исходным кодом является правильным выбором, потому что некоторые модули NodeJS, такие как MongoDB NodeJS driver, используют надстройки NodeJS C++. Эти дополнения компилируются при запуске

Jan Żankowski · Accepted Answer · 2017-09-05 00:36:07

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

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

Himanshu · Accepted Answer · 2018-04-08 15:24:17

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

cepharum · Accepted Answer · 2018-10-07 12:35:59

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

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

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

положить пакет в формате JSON.файл блокировки в VCS помогает с часто обновляемыми зависимостями, которые, вероятно, приводят к различным настройкам, хотя и полагаются на один и тот же пакет.файл json.

таким образом, размещение node_modules в VCS в случае наличия автономных инструментов сборки может считаться единственным подходящим вариантом использования. Однако, папки node_modules обычно растет довольно быстро. Любое обновление изменит много файлов. И это влияет репозитории по-разному. Если вы действительно рассматриваете долгосрочные последствия, это также может быть препятствием.

централизованные VCS, такие как svn, требуют передачи зафиксированных и проверенных файлов по сети, которая будет медленной, как ад, когда дело доходит до проверки или обновления папки node_modules.

когда дело доходит до git, это большое количество дополнительных файлов мгновенно загрязняет репозиторий. Имейте в виду, что git не отслеживает различия между версии любого файла, но сохраняет копии любой версии файла, как только один символ изменился. Каждое обновление любой зависимости приведет к еще одному большому набору изменений. Ваш репозиторий git быстро вырастет огромным из-за этого, влияющего на резервные копии и удаленную синхронизацию. Если вы решите удалить node_modules из репозитория git позже, он все еще является его частью по историческим причинам. Если вы распространили свой репозиторий git на какой-либо удаленный сервер (например, для резервного копирования), очистите его up-это еще одна болезненная и подверженная ошибкам задача, с которой вы столкнетесь.

таким образом, если вы заботитесь об эффективных процессах и хотите сохранить вещи "маленькими", я бы предпочел использовать отдельный репозиторий артефактов, такой как репозиторий Nexos (или просто какой-то HTTP-сервер с ZIP-архивами), предоставляющий некоторый ранее выбранный набор зависимостей для загрузки.