Имеет ли каждая ветвь git проекта NPM разные зависимости node_modules?

Ответ 1

По соглашению нельзя добавлять файлы, библиотеки или двоичные файлы, которые могут быть сгенерированы или извлечены из внешнего источника. Сюда относятся такие вещи, как node_modules; так как это становится доступным *, как только вы npm install, нет никакой причины или стимула **, чтобы захотеть поместить это в свой исходный контроль. В худшем случае он также раздувает ваш репозиторий, заполняя ваши отличия от вещей, которые вы просто не контролируете и не обязательно хотите просмотреть.

Я бы не ожидал, что разные ветки Git проекта NPM будут содержать разные папки node_modules. Я бы ожидал только одну папку node_modules, и если ветвь дала мне подходящие зависимости, я бы посмотрел, чтобы переустановить зависимости (и запомните это, чтобы убедиться, что что-то еще не пошло не так).

В качестве дополнения любые файлы или папки в .gitignore просто не индексируются и не отслеживаются Git. Если содержимое этих файлов или папок меняется, Git не является более мудрее. Это также означает, что при переключении между ветвями содержимое файлов или папок в .gitignore остается неизменным.

^{*: При условии, что библиотека, которую вы используете, не внезапно дергается.Или на хранилище не влияет колоссальный DDoS.}

^{**: Могут быть некоторые стимулы для этого, учитывая, что надежность некоторых пакетов NPM в этом году не была на 100%, но это решение, основанное на команде и архитектуре, и я сомневаюсь, что размещение его в исходном контроле является наиболее идеальный и удобный способ справиться с этим.}

Ответ 2

Есть две школы мысли, и у обоих есть заслуга.

1) Никогда не проверяйте в node_modules и перестраивайте при развертывании/установке

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

Положительные: ваш репозиторий намного меньше.

Модули NPM устанавливаются в среде, в которой они будут работать.

Обеспокоенность: привязана к сторонней стороне для источников. Пойдите, прочитайте о том, что left-pad. Если одна зависимость не может быть загружена, вся ваша система сборки высушена. "Cranky и параноидальные старые таймеры" приведут это в качестве причины, чтобы проверить все (или где-то запустить собственный частный NPM).

Управление филиалом. Как вы упомянули в вопросе, некоторые ветки могут не иметь одинаковых зависимостей. Dev1 добавляет новые функции и использует новый пакет. Теперь Dev2 запускает ветвь dev или что-то еще, и все сломано, и им нужно знать, чтобы npm install новый пакет npm install. Более тонкий случай, когда версия пакета npm изменена (теперь вам нужно npm update поскольку npm install будет говорить, что ничего не изменилось) или где их node_modules обновлены для работы над "новой функцией 10", но им нужно очистить все до "понизить", чтобы исправить "предыдущую ошибку 43". Если вы находитесь в активной разработке с командой более 2-3, следите за этим.

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

2) Всегда проверяйте все, что можете

Этот подход включает node_modules как часть репо.

Положительные: не зависят от сторонних источников. У вас есть то, что вам нужно для запуска. Вы можете жить самостоятельно, и не имеет значения, опущен ли npm или репо удалено.

Филиалы независимы, поэтому новые функции Dev1 автоматически включаются, когда Dev2 переключается на эту ветвь

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

Проблемы: репозиторий намного больше. Клоны кода занимают больше времени, так как есть еще много файлов.

Pull Requests требует дополнительной осторожности. Если пакет обновляется (или устанавливается) вместе с основным кодом, PR беспорядок, а иногда и непонятный. "500 файлов изменены", но на самом деле вы обновили пакет и изменили две строки кода ядра. Это может помочь разбить на два PR - один из них - беспорядок (обновление пакета) и тот, который действительно просматривается (изменение основного кода). Опять же, будьте готовы к этому. Пакеты не будут меняться слишком часто, но ваш обзор кода займет немного больше времени (или немного больше внимания), когда они это сделают.

OS Dependent Packages могут сломаться. В принципе, все, что установлено/скомпилировано с помощью gyp может быть зависимым от ОС (в частности). Большинство пакетов являются "чистыми JS" и, будучи просто скриптами, работают везде. Представьте, что все ваши разработчики запускают и тестируют на OSX во время развертывания в Linux, вы не можете проверить те пакеты, которые были скомпилированы на MAC, потому что они не будут работать в Linux. --save-dev для этого является определение большинства пакетов как "зависимостей dev" (--save-dev) и тех, которые необходимо скомпилировать как обычные ("production", --save), затем вы запускаете npm install --production чтобы dev не установлены (и уже присутствуют), но остальные.

Выводы

Это зависит. (Разве вы не слышите, что все время?)

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

Ответ 3

Две ветки, имеющие разные узловые модули, находятся в сценарии, где одна ветка находится в стадии разработки, а другая - ваша производственная ветвь. В таких случаях ветвь развития будет иметь больше модулей узлов, чем производство. Если я не ошибаюсь, любой другой сценарий может вызвать у вас проблемы.

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

Ответ 4

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

Ответ 5

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