NPM на сегодняшний день является наиболее распространенным инструментом для повседневного использования. И пока наш проект обслуживается онлайн статически, поэтому проблем с зависимостями NPM нет. Но с некоторыми мы встречались несколько раз в процессе разработки. Вы знаете, некоторые новички в проекте клонируют его и запускают npm install, а потом говорят: «Это не работает на моем компьютере». «Правда? На моем работает».
Позже мы узнали, что это было из-за `^` или `~` в этих версиях зависимостей. Когда какая-то зависимость имеет несовместимые обновления (что происходит каждую секунду), или кто-то забывает сохранить используемые зависимости в package.json, будут такие ошибки.
Поместите все в репо
Это напоминает мне, что когда я работал в другой команде, мы помещали node_modules в репозиторий. Он работал в другой среде, за исключением большого размера репо и длительного времени свежего клонирования.
Добавление новых зависимостей или обновление существующих может генерировать коммиты, которые трудно сравнивать и просматривать.
Ясно, что это недостаточно хорошее решение.
«заблокировать» версию с «-E»
Итак, теперь, когда мы знаем, что в версии зависимостей не должно быть синтаксиса диапазона, мы не должны забывать добавлять зависимости в package.json. Как насчет использования [`npm install -SE`](https://docs.npmjs.com/cli/install)? Чтобы не использовать эти параметры постоянно, их можно сохранить в .npmrc.
```
save=true
save-exact=true
```
Вроде неплохо, да? Но поскольку мы на самом деле не можем гарантировать, что используемая нами версия зависимостей не имеет синтаксиса диапазона, не будет одинакового дерева зависимостей во всех средах.
Так грустно.
npm термоусадочная упаковка
Потом я нашел термоусадочную пленку.
Эта команда блокирует версии зависимостей пакета, чтобы вы могли точно контролировать, какие версии каждой зависимости будут использоваться при установке вашего пакета.
Команда shrinkwrap заблокировала зависимости на основе того, что в настоящее время установлено в node_modules.
Вау, действительно впечатлен. Похоже, они поняли проблему и предложили это лучшее решение.
Некоторые пакеты требуют некоторых зависимостей, но по некоторым причинам мы не используем эти пакеты, а вместо этого связываем их напрямую.
Требуется гораздо больше труда, чтобы следить за обновлениями зависимостей (поскольку есть частые исправления ошибок и новые функции)
И вы должны сделать это в соответствии с лучшей практикой, чтобы избежать сбоев термоусадочной упаковки.
1. Запустите npm install — save-dev left-pad
2. Запустите npm prune, чтобы удалить дубликаты графа зависимостей, если один из ваших существующих модулей где-то использует левую панель, в противном случае npm shrinkwrap завершится ошибкой
3. Запустите npm shrinkwrap — dev, чтобы обновить файл Shrinkwrap
4. Поднимите запрос на включение, обратите внимание, что файл npm-shrinkwrap.json имеет тон нечитаемых и неожиданных изменений — наслаждайтесь тем фактом, что github отказывается отображать файл. diff в файле термоусадочной упаковки…
Несмотря на то,
Если вы хотите заблокировать определенные байты, включенные в пакет, например, чтобы иметь 100% уверенность в возможности воспроизвести развертывание или сборку, вам следует проверить свои зависимости в системе управления версиями или использовать какой-либо другой механизм, который может проверить содержание, а не версии.
Затем идет Пряжа. Хотя я не согласен с причиной, по которой они это делают, только если это решает все эти проблемы, не вызывая новых проблем, это лучшее решение.
