NodeJS и NPM: проблемы с рекомендацией проверить модули в git

Question

У меня проблемы с выполнением «официальной» рекомендации по проверке всех внешних зависимостей в git (статья http://www.mikealrogers.com/posts/nodemodules-in-git.html FAQ по fronted)

1. Как вы делаетеуверены, что не только зависимости верхнего уровня зарегистрированы?Большинство модулей npm в настоящее время не следуют рекомендациям.Все они имеют свои node_modules в .gitignore.Просто удаление их .gitignore кажется рискованным.

2. Для скомпилированного модуля в статье рекомендуется регистрировать только исходные коды и запускать 'npm rebuild' и время развертывания.К сожалению, npm rebuild не выполняет «чистую сборку» для всех модулей (несмотря на то, что исправление https://github.com/isaacs/npm/issues/1872 включено в npm версии 1.0.106, которую я использую).Это означает, что я должен предотвратить регистрацию целей компиляции (в противном случае я получу объектный код, скомпилированный для компьютера разработчика на рабочей машине без перезаписи npm rebuild).Но: как мне это сделать?К сожалению, модули не имеют общего выходного каталога компиляции, так что просто игнорируйте git "node_modules / / build" и "/ node_modules / / out /" (как упоминалось в этой хорошей статье eng.yammer.ru / blog / 2012/1/4 / manage-nodejs-dependencies-and-deployments-at-yammer.html не поможет в каждом случае.

Краткая версия: как это сделатьВы уверены, что на производственных серверах используется та же версия всех зависимых модулей, что и во время разработки?

Answer 1

ОБНОВЛЕНИЕ: теперь есть npm shrinkwrap, который решает проблему блокировки точных версий зависимостей, даже зависимостей зависимостей! Подробнее здесь.

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

Краткая версия: как убедиться, что рабочие серверы используют точно такую ​​же версию всех зависимых модулей, которую вы используете во время разработки?

Внутри вашего package.json будет dependencies: {}, если его там нет, то добавьте его. Чтобы достичь желаемого, добавьте свои зависимости в качестве ключа и их точные версии в качестве значения. Например. dependencies: { docpad: '2.5.0', mocha: '1.1.0' }

Однако обычно (это зависит от автора) обновления до номера ревизии (номера x.x.X) являются просто исправлениями ошибок и безопасны. Вы можете разрешить незначительные изменения, выполнив dependencies: { docpad: '2.5.x', mocha: '1.1.x' }, что избавляет вас от необходимости обновлять package.json и выпускать релиз каждый раз, когда появляется исправление ошибки. Вы даже можете делать такие вещи, как 2.x, если хотите.

Это решение, которое я решил использовать для всех своих модулей, поскольку оно гарантирует, что даже через 6 месяцев или независимо от того, какой модуль все еще будет работать, тогда как выполнение чего-то вроде >= 2.0.0 означает, что выйдет v3 зависимости , ваш модуль, вероятно, будет непригодным в это время. Гарантия того, что вы придерживаетесь определенных версий, «гарантирует» стабильность во времени.

Для справки вы можете увидеть, как я это сделал в моих модулях с открытым исходным кодом node.js здесь

Answer 2

О .gitignore ваших зависимостей (в "node_modules") npm 1.1 игнорирует файлы .gitignore, поэтому они не устанавливаются;

npm 1.1 will exclude .gitignore files from the things it installs. 
npm 1.0 did not have this feature, so you have to be careful about that. 
Deleting them recursively is fine: 
    find node_modules -name .gitignore | xargs rm 
But, in npm 1.1, you never have to do this, because it excludes them 
from the install automatically. 

Это исходит от самого вождя (Исаака), а он здесь и, кажется, охватывает почти все. «Посторонняя» проблема, которую я имею, должна быть чем-то глупым, что я сделал, я попробую чистую установку.