Я выполнил основные инструкции по началу работы для node.js на Heroku здесь:
https://devcenter.heroku.com/categories/nodejs
В этой инструкции не указывается, что вы создаете .gitignore node_modules, и поэтому подразумеваете, что node_modules должен быть установлен в git. Когда я включаю node_modules в git, мое приложение для запуска запускается правильно.
Когда я выполнил более продвинутый пример:
https://devcenter.heroku.com/articles/realtime-polyglot-app-node-ruby-mongodb-socketio https://github.com/mongolab/tractorpush-server (источник)
Он поручил мне добавить node_modules в .gitignore. Поэтому я удалил node_modules из git, добавил его в .gitignore, а затем повторно развернул. На этот раз развернутые не удалось:
-----> Heroku receiving push
-----> Node.js app detected
-----> Resolving engine versions
Using Node.js version: 0.8.2
Using npm version: 1.0.106
-----> Fetching Node.js binaries
-----> Vendoring node into slug
-----> Installing dependencies with npm
Error: npm doesn't work with node v0.8.2
Required: [email protected] || 0.5 || 0.6
at /tmp/node-npm-5iGk/bin/npm-cli.js:57:23
at Object.<anonymous> (/tmp/node-npm-5iGk/bin/npm-cli.js:77:3)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:362:17)
at require (module.js:378:17)
at Object.<anonymous> (/tmp/node-npm-5iGk/cli.js:2:1)
at Module._compile (module.js:449:26)
Error: npm doesn't work with node v0.8.2
Required: [email protected] || 0.5 || 0.6
at /tmp/node-npm-5iGk/bin/npm-cli.js:57:23
at Object.<anonymous> (/tmp/node-npm-5iGk/bin/npm-cli.js:77:3)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:362:17)
at require (module.js:378:17)
at Object.<anonymous> (/tmp/node-npm-5iGk/cli.js:2:1)
at Module._compile (module.js:449:26)
Dependencies installed
-----> Discovering process types
Procfile declares types -> mongod, redis, web
-----> Compiled slug size is 5.0MB
-----> Launching... done, v9
Запуск "heroku ps" подтверждает сбой. Хорошо, не проблема, поэтому я откатил изменения, добавил node_module обратно в репозиторий git и удалил его из .gitignore. Однако даже после возврата я все равно получаю такое же сообщение об ошибке при развертывании, но теперь приложение снова работает правильно. Запуск "heroku ps" говорит мне, что приложение запущено.
Итак, мой вопрос - как правильно это сделать? Включить node_modules или нет? И почему я должен получать сообщение об ошибке при откате? Я предполагаю, что репозиторий git находится в плохом состоянии на стороне Heroku?
ЧаВо больше не доступно.
Из документации shrinkwrap
:
Шеннон и Стивен упомянули об этом раньше, но я думаю, что это должно быть частью принятого ответа.Если вы хотите заблокировать определенные байты, включенные в пакет, например, чтобы иметь 100% уверенность в возможности воспроизвести развертывание или сборку, тогда вы должны проверить свои зависимости в исходном контроле или преследовать какой-то другой механизм который может проверять содержимое, а не версии.
Обновлен источник, указанный в приведенной ниже рекомендации . Они больше не рекомендуют устанавливать папку node_modules
.
Обычно нет. Разрешить npm разрешать зависимости для ваших пакетов.
Для развертываемых пакетов, таких как веб-сайты и приложения, вы должны использовать npm 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
npm rebuild
.
Моя самая большая забота о том, чтобы не проверять node_modules
на git, - это то, что 10 лет в будущем, когда ваше производственное приложение все еще используется, npm может не быть рядом. Или npm может стать поврежденным; или сопровождающие могут решить удалить библиотеку, на которую вы полагаетесь, из своего репозитория; или версия, которую вы используете, может быть обрезана.
Это можно смягчить с помощью менеджеров репо, таких как maven, потому что вы всегда можете использовать свой собственный локальный Nexus или Artifactory, чтобы поддерживать зеркало с используемыми вами пакетами. Насколько я понимаю, такой системы не существует для npm. То же самое касается менеджеров библиотек на стороне клиента, таких как Bower и Jamjs.
Если вы перенесли файлы на свой собственный репозиторий git, тогда вы можете обновлять их, когда захотите, и у вас есть удобство повторяемых сборок и знания о том, что ваше приложение не будет ломаться из-за каких- партийного действия.
Вы не должны включать 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 и уменьшит вероятность подобных ситуаций в будущем.
Я собирался оставить это после этого комментария: Должен ли я проверить 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
Убедитесь, что файлы не изменены.
Я считаю, что npm install
не должен запускаться в рабочей среде. Есть несколько вещей, которые могут пойти не так - npm отключить, загрузка новых зависимостей (shrinkwrap, похоже, решила это) - это два из них.
С другой стороны, node_modules
не следует указывать на git. Помимо их большого размера, коммиты, включая их, могут стать отвлекающими.
Лучшие решения будут такими: npm install
должен работать в среде CI, которая похожа на производственную среду. Все тесты будут запущены, и будет создан файл с zip-релизом, который будет содержать все зависимости.
Я использую как фиксацию папки 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
и нажмет результаты удаленного репо.
Что работало для меня, явным образом добавлял версию npm для package.json( "npm": "1.1.x" ) и НЕ проверяла в node_modules на git. Он может быть медленнее для развертывания (поскольку он загружает пакеты каждый раз), но я не мог получить пакеты для компиляции, когда они были проверены. Heroku искал файлы, которые существовали только в моем локальном поле.
Я использую это решение:
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
node_modules
to node_modules
и добавьте node_modules
в .gitignore
.npm install
.Таким образом, вы можете легко переключаться между node_modules
на разных платформах (например, если вы разрабатываете OS X и развертываете в Linux).
От https://web.archive.org/web/20150212165006/http://www.futurealoof.com/posts/nodemodules-in-git.html:
Изменение: оригинальная ссылка была этой, но теперь она мертва. Спасибо @Flavio за указание на это.
Напомним.
- Только checkin node_modules для приложений, которые вы развертываете, а не повторно используемых пакетов, которые вы поддерживаете.
- Любые скомпилированные зависимости должны проверять исходный код, а не цели компиляции, а при развертывании - $ npm rebuild.
Моя любимая часть:
Все, кого вы добавили node_modules в ваш gitignore, удалите это дерьмо, сегодня, его артефакт эпохи, были слишком счастливы оставить позади. Эпоха глобальных модулей мертва.
Вместо проверки в node_modules создайте файл package.json для своего приложения.
В файле package.json указаны зависимости вашего приложения. Затем Heroku может указать npm для установки всех этих зависимостей. В учебнике, в котором вы были связаны, содержится раздел о файлах package.json.
http://nodejs.org/api/modules.html
[...] node начинается с родительского каталога текущего модуля и добавляет
/node_modules
и пытается загрузить модуль из этого места.Если он там не найден, , то он перемещается в родительский каталог и т.д., пока не будет достигнут корень дерева.
Если вы загружаете свои собственные модули, специфичные для вашего приложения, вы можете сохранить их (и только те) в своем приложении /node_modules
. И переместите все другие зависимости в родительский каталог.
Этот пример использования довольно увлекательный, он позволяет вам создавать модули, созданные специально для вашего приложения, с вашим приложением, и не загромождает ваше приложение с зависимостями, которые могут быть установлены позже.
node_modules
в приложения Heroku.