#node.js #git #npm
#node.js #git #npm
Вопрос:
Я предполагаю, что при разработке NPM проекта каждая git ветвь (или любая другая система контроля версий, которую вы используете), вероятно, указывает на другой набор node_modules в файловой системе. Это правда? Как это работает? Создает ли это какие-либо проблемы для дискового пространства и т.д.?
Или, возможно, поскольку node_modules это наиболее распространено .gitignore'd , node_modules файлы являются общими для ветвей Git? Опять же, как бы это работало?
* Обратите внимание, что Node.js / NPM принципиально отличается от других платформ / языков, поскольку зависимости обычно хранятся локально в proejct, а не в каком-то центральном расположении на компьютере.
Комментарии:
1. Нет. Вероятно, есть способ сделать это, но я добавляю
node_modulesв.gitignoreи поскольку одновременно извлекается только одна ветвь в одном каталоге, то все они используют одни и те же модули.2. это не имеет смысла — что, если одна ветвь имеет совершенно другие зависимости или версии, чем другая ветвь. Я не думаю, что gitignore решает эту проблему…
3. Если ветвь имеет совершенно другие зависимости, чем другая, то это просто может быть другой проект и, возможно, принадлежит его собственному репозиторию. Вы когда-нибудь намеревались объединить эти ветви обратно вместе? При этом вы можете полностью фиксировать разные
node_modulesдля расходящихся ветвей, но диск будет быстро съеден, особенно потому, что git хранит не дельты, а моментальные снимки всего репозитория. Вероятно, было бы лучше зафиксировать разныеpackage.jsonфайлы и запустить git-хук, который переустановил бы зависимости при проверке ветви.
Ответ №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 загружаются и устанавливаются (и / или компилируются) при каждом запуске deploy.
Положительные стороны: Ваш репозиторий намного меньше.
Модули NPM устанавливаются в среде, в которой они будут выполняться.
Проблемы: Привязан к сторонним источникам — Прочитайте обо всем этом left-pad . Если не удается загрузить одну зависимость, вся ваша система сборки вывешивается для просушки. «Капризные и параноидальные старожилы» будут ссылаться на это как на причину проверить все (или запустить где-нибудь свой собственный NPM).
Управление ветвями — Как вы упомянули в вопросе, некоторые ветви могут не иметь одинаковых зависимостей. Dev1 добавляет новые функции и использует новый пакет. Теперь Dev2 запускает dev ветвь или что-то еще, и все сломано, и им нужно знать, чтобы npm install создать новый пакет. Более тонким является случай, когда у пакета npm изменена версия (теперь вам нужно npm update как npm install будет сказать, что ничего не изменилось), или когда их node_modules обновили для работы с «новой функцией 10», но им нужно все очистить, чтобы «понизить версию», чтобы исправить «предыдущую ошибку 43». Если вы активно разрабатываете с командой из более чем 2-3 человек, обратите внимание на эту.
Время сборки — Если это вызывает беспокойство, загрузка и установка всего занимает немного больше времени. Или намного больше.
2) Всегда проверяйте все, что вы можете
Этот подход включает node_modules как часть репозитория.
Положительные стороны: не зависит от сторонних источников. У вас есть то, что вам нужно для запуска. Ваш код может жить сам по себе вечно, и не имеет значения, отключен npm или удален репозиторий.
Ветви независимы, поэтому новые функции из Dev1 автоматически включаются, когда Dev2 переключается на эту ветвь
Время развертывания сокращается, потому что не так много требуется установить.
Проблемы: репозиторий намного больше. Клонирование кода занимает больше времени, поскольку файлов намного больше.
Запросы на извлечение требуют особой осторожности. Если пакет обновляется (или устанавливается) вместе с основным кодом, PR является беспорядочным и иногда неразборчивым. «Изменено 500 файлов», но на самом деле вы обновили пакет и изменили две строки основного кода. Это может помочь разбить на два PR-файла — тот, который находится в беспорядке (обновление пакета), и тот, который действительно можно просмотреть (изменение основного кода). Опять же, будьте готовы к этому. Пакеты не будут меняться слишком часто, но ваш просмотр кода займет немного больше времени (или немного больше внимания), когда они это сделают.
Пакеты, зависящие от операционной системы, могут ломаться. В принципе, все, что устанавливается / компилируется с gyp , может зависеть от операционной системы (среди прочих). Большинство пакетов являются «чистым JS» и, будучи просто скриптами, выполняются везде. Представьте, что все ваши разработчики запускаются и тестируются в OSX во время развертывания в Linux, вы не можете проверить те пакеты, которые были скомпилированы на MAC, потому что они не будут запускаться в Linux. Странный обходной путь для этого — определить большинство пакетов как «dev dependencies» ( --save-dev ) и те, которые нужно скомпилировать как обычно («production», --save ), затем вы запускаете npm install --production , поэтому зависимости dev не установлены (и уже присутствуют), но остальные установлены.
Выводы
Это зависит. (Разве тебе не неприятно слышать это все время? : )
В зависимости от вашей команды и ваших проблем, вы можете выбрать любой подход. У обеих есть свои достоинства, и вы сами решите, что для вас более выгодно. У обеих также есть недостатки, так что помните о них, прежде чем получите bit!
Ответ №3:
Лично я игнорирую .node_modules, но у меня другой package.json в другой ветке, и когда я переключаюсь, я переустанавливаю зависимости
Ответ №4:
Две ветви, имеющие разный набор модулей узла, находятся в сценарии, где одна ветвь находится в стадии разработки, а другая — ваша производственная ветвь. В таких случаях в ветви разработки будет больше модулей узла, чем в производственной. Если я не ошибаюсь, любой другой сценарий может вызвать у вас проблемы.
Отправка node_modules в репозиторий удаленного управления версиями — плохая практика, поэтому просто полагайтесь на npm install всякий раз, когда вы клонируете ветку или извлекаете код для загрузки любого нового модуля узла, добавленного в package.json.
Ответ №5:
Очевидно, поскольку у вас нет ваших node_modules в вашем реальном репозитории, вам нужно снова установить модули узла, и у каждой ветви могут быть свои собственные требования, поскольку вы можете обновить свой server.js с новой зависимостью, и вам также нужно убедиться, что у вас есть эти недавно добавленные зависимости узла на вашем рабочем сервере.