Когда использовать термоусадочную пленку, npm-lockdown или npm-seal
Я исхожу из истории, гораздо более знакомой с composer, я собираюсь gulp (и т.д.) для процессов сборки и обучения node и как использовать npm как я иду.
Это очень странно (опять же, исходя из composer фон), что composer.lockПодобный манифест не включен по умолчанию. Сказав это, я читал документацию по [shrinkwrap], [npm-lockdown] и [npm-seal]. ... и чем больше документации я читаю, тем больше я запутываюсь в том, что мне следует выбирать (все думают, что их путь - лучший). Одна из проблем, которые я замечаю, заключается в том, что npm-seal не изменился за 4 года и npm-lockdown через 8 месяцев - все это заставляет меня задуматься об этом, потому что это не нужно с новейшей версией npm...
- Каковы преимущества / недостатки каждого?
- В каких случаях я использовал бы один над другим в Проекте A, но использовал бы другой в Проекте B?
- Как каждый из них повлияет на наш рабочий процесс разработки?
PS: Брауни указывает, если вы включите самый базовый пример реализации для каждого.;)
3 ответа
npm shrinkwrap это самый стандартный способ блокировки ваших зависимостей. И да, npm install не создает его по умолчанию, что очень жаль, и это то, что создатели npm определенно должны изменить.
npm-lockdown пытается сделать то же самое, что и npm shrinkwrapЕсть два небольших момента, в которых npm-lockdown лучше: он лучше обрабатывает необязательные зависимости и проверяет контрольные суммы пакета:
https://www.npmjs.com/package/lockdown
Обе эти особенности кажутся мне не такими важными; Я вполне доволен npm shrinkwrapНапример, npmjs гарантирует, что после загрузки определенного пакета в определенной версии он останется неизменным - поэтому проверка контрольных сумм ша не такая горячая (я никогда не сталкивался с ошибкой, вызванной этим).
seal предназначен для использования вместе с npm shrinkwrap, Это добавляет аспект проверки контрольной суммы. Это выглядит заброшенным и довольно сырым.
Хороший вопрос - я собираюсь пропустить все, кроме shrinkwrap потому что это де-факто способ сделать это, согласно документам NPM.
Короче говоря npm-shrinkwrap.json файл похож на ваш lock файлы, к которым вы привыкли в любом другом менеджере пакетов, хотя NPM позволяет разным версиям одного и того же пакета воспроизводиться вместе, изолируя друг от друга - буквально определяя область видимости и копируя разные целые версии в node_modules на разных уровнях дерева. Если два проекта, которые являются родительскими и дочерними по отношению друг к другу, используют одну и ту же версию, NPM скопирует версию только в родительский, а дочерний процесс переместится вверх по дереву, чтобы найти пакет.
Лучшая практика - просто обновить package.json для ваших прямых зависимостей, запустите npm install, убедитесь, что все работает во время разработки, затем запустите npm shrinkwrap когда вы только собираетесь совершить и подтолкнуть. ПРИМЕЧАНИЕ: обязательно rm npm-shrinkwrap.json перед запуском npm install во время активной разработки - если ваши прямые зависимости изменились, вы хотите package.json использоваться, а не замок! Также включить node_modules в вашем .gitignore или эквивалент в вашей системе контроля версий. Затем, когда вы развертываете и запускаете проект, запустите npm install вроде нормально. Если npm находит npm-shrinkwrap.json файл, он будет использовать это для рекурсивного извлечения всех заблокированных модулей, и он будет игнорировать package.json как в вашем проекте, так и во всех зависимых проектах.
Вы можете найти shrinkpack полезным - он проверяет в тарболах, которые npm install загружает и упаковывает их в свой репозиторий, прежде чем, наконец, переписать npm-shrinkwrap.json, чтобы вместо этого указать на этот локальный пакет.
Таким образом, ваш проект полностью заблокирован, полностью доступен в автономном режиме и намного быстрее устанавливается.