Должен ли я проверить node_modules на git при создании приложения node.js на Heroku?

Ответ 1

Второе обновление

ЧаВо больше не доступно.

Из документации shrinkwrap:

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

Update

Обновлен источник, указанный в приведенной ниже рекомендации . Они больше не рекомендуют устанавливать папку node_modules.

Обычно нет. Разрешить npm разрешать зависимости для ваших пакетов.

Для развертываемых пакетов, таких как веб-сайты и приложения, вы должны использовать npm shrinkwrap, чтобы заблокировать ваше полное дерево зависимостей:

https://docs.npmjs.com/cli/shrinkwrap

Оригинальное сообщение

Для справки, npm FAQ отвечает на ваш вопрос четко:

Проверьте node_modules на git на вещи, которые вы развертываете, например на веб-сайтах и приложения. Не проверяйте node_modules на git для библиотек и модулей предназначенные для повторного использования. Используйте npm для управления зависимостями в своем dev среде, но не в сценариях развертывания.

и для некоторого хорошего объяснения для этого, прочитайте сообщение Майкеля Роджерса на этом.

Источник: https://docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git

Ответ 2

Моя самая большая забота о том, чтобы не проверять node_modules на git, - это то, что 10 лет в будущем, когда ваше производственное приложение все еще используется, npm может не быть рядом. Или npm может стать поврежденным; или сопровождающие могут решить удалить библиотеку, на которую вы полагаетесь, из своего репозитория; или версия, которую вы используете, может быть обрезана.

Это можно смягчить с помощью менеджеров репо, таких как maven, потому что вы всегда можете использовать свой собственный локальный Nexus или Artifactory, чтобы поддерживать зеркало с используемыми вами пакетами. Насколько я понимаю, такой системы не существует для npm. То же самое касается менеджеров библиотек на стороне клиента, таких как Bower и Jamjs.

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

Ответ 3

Вы не должны включать node_modules в .gitignore (или, скорее, вы должны включить node_modules в свой источник, развернутый в Heroku).

Если node_modules:

• существует, тогда npm install будет использовать эти выпущенные libs и будет восстанавливать любые двоичные зависимости с помощью npm rebuild.
• не существует, тогда npm install придется извлекать все зависимости, которые добавляют время на этап компиляции slug.

Смотрите Node.js buildpack source для этих точных шагов

Однако исходная ошибка выглядит несовместимой между версиями npm и node. Рекомендуется избегать таких ситуаций: engines раздел packages.json в соответствии с этим руководством.

{
  "name": "myapp",
  "version": "0.0.1",
  "engines": {
    "node": "0.8.x",
    "npm":  "1.1.x"
  }
}

Это обеспечит dev/prod parity и уменьшит вероятность подобных ситуаций в будущем.

Ответ 4

Я собирался оставить это после этого комментария: Должен ли я проверить node_modules на git при создании приложения node.js на Heroku?

Но stackoverflow форматировал его странно. Если у вас нет одинаковых машин и вы проверяете node_modules, сделайте .gitignore в собственных расширениях. Наш .gitignore выглядит следующим образом:

# Ignore native extensions in the node_modules folder (things changed by npm rebuild)
node_modules/**/*.node
node_modules/**/*.o
node_modules/**/*.a
node_modules/**/*.mk
node_modules/**/*.gypi
node_modules/**/*.target
node_modules/**/.deps/
node_modules/**/build/Makefile
node_modules/**/**/build/Makefile

Протестируйте это, предварительно проверив все, а затем попросите другого разработчика сделать следующее:

rm -rf node_modules
git checkout -- node_modules
npm rebuild
git status

Убедитесь, что файлы не изменены.

Ответ 5

Я использую как фиксацию папки node_modules, так и термоусадочную упаковку. Оба решения не сделали меня счастливым.

Короче: commit node_modules добавляет слишком много шума в репозиторий.
И shrinkwrap.json нелегко управлять, и нет никакой гарантии, что некоторые проекты, упакованные в термоусадочную пленку, будут построены через несколько лет.

Я обнаружил, что Mozilla использует отдельный репозиторий для одного из своих проектов https://github.com/mozilla-b2g/gaia-node-modules

Поэтому мне не потребовалось много времени, чтобы реализовать эту идею в инструменте node CLI https://github.com/bestander/npm-git-lock

Перед каждой сборкой добавьте npm- git -lock --repo [git @bitbucket.org: ваш/посвященный/node_modules/git/repository.git]

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

Ответ 6

Я считаю, что npm install не должен запускаться в рабочей среде. Есть несколько вещей, которые могут пойти не так - npm отключить, загрузка новых зависимостей (shrinkwrap, похоже, решила это) - это два из них.

С другой стороны, node_modules не следует указывать на git. Помимо их большого размера, коммиты, включая их, могут стать отвлекающими.

Лучшие решения будут такими: npm install должен работать в среде CI, которая похожа на производственную среду. Все тесты будут запущены, и будет создан файл с zip-релизом, который будет содержать все зависимости.

Ответ 7

Что работало для меня, явным образом добавлял версию npm для package.json( "npm": "1.1.x" ) и НЕ проверяла в node_modules на git. Он может быть медленнее для развертывания (поскольку он загружает пакеты каждый раз), но я не мог получить пакеты для компиляции, когда они были проверены. Heroku искал файлы, которые существовали только в моем локальном поле.

Ответ 8

Вместо проверки в node_modules создайте файл package.json для своего приложения.

В файле package.json указаны зависимости вашего приложения. Затем Heroku может указать npm для установки всех этих зависимостей. В учебнике, в котором вы были связаны, содержится раздел о файлах package.json.

Ответ 9

От https://web.archive.org/web/20150212165006/http://www.futurealoof.com/posts/nodemodules-in-git.html:

Изменение: оригинальная ссылка была этой, но теперь она мертва. Спасибо @Flavio за указание на это.

Напомним.

• Только checkin node_modules для приложений, которые вы развертываете, а не повторно используемых пакетов, которые вы поддерживаете.
• Любые скомпилированные зависимости должны проверять исходный код, а не цели компиляции, а при развертывании - $ npm rebuild.

Моя любимая часть:

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

Ответ 10

Я использую это решение:

• Создайте отдельный репозиторий, содержащий node_modules. Если у вас есть собственные модули, которые должны быть созданы для конкретной платформы, тогда создайте отдельный репозиторий для каждой платформы.
• Прикрепите эти репозитории к репозиторию проекта с помощью git submodule:

git submodule add .../your_project_node_modules_windows.git node_modules_windows

git submodule add .../your_project_node_modules_linux_x86_64 node_modules_linux_x86_64

3. Создайте ссылку из специфичного для платформы каталога node_modules to node_modules и добавьте node_modules в .gitignore.
4. Запустите npm install.
5. Изменять изменения в подменю подменю.
6. Зафиксируйте изменения в репозитории проекта.

Таким образом, вы можете легко переключаться между node_modules на разных платформах (например, если вы разрабатываете OS X и развертываете в Linux).

Ответ 11

http://nodejs.org/api/modules.html

[...] node начинается с родительского каталога текущего модуля и добавляет /node_modules и пытается загрузить модуль из этого места.

Если он там не найден, , то он перемещается в родительский каталог и т.д., пока не будет достигнут корень дерева.

Если вы загружаете свои собственные модули, специфичные для вашего приложения, вы можете сохранить их (и только те) в своем приложении /node_modules. И переместите все другие зависимости в родительский каталог.

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