на данный момент npm ci
является наиболее распространенным способом установки узловых модулей при использовании CI. Но это, честно говоря, очень медленно. Есть ли способ ускорить npm ci
с помощью кэша или не полностью удалить существующие пакеты (вся папка node_modules)?
Есть ли способ ускорить npm ci, используя кеш?
Ответ 1
Это зависит от того, какой инструмент CI/CD вы используете, но вы должны иметь возможность настроить его для кэширования каталога ~/.npm
(при условии Linux).
Например, см. Документацию для Travis CI.
Ответ 2
Вы можете указать своему CI кэшировать каталог кэша npm, а затем использовать опции --prefer-offline и --no-Audit, пример: npm ci --prefer-offline --no-аудит
Ответ 3
д-р №
npm ci
должен быть предпочтительным в CI, поскольку он учитывает файл package-lock.json
. В отличие от npm install
, который переписывает файл и всегда устанавливает новые версии.
Конструктивно эта команда всегда удаляет все локальные пакеты, удаляя каталог node_modules
в начале. Это главная причина длинных сборок. И нет возможности избежать этого раздражающего поведения.
На локальном компьютере вы можете ускорить npm ci
, добавив опцию --prefer-offline
, которая говорит NPM игнорировать минимальное время кеширования и сразу использовать локально кэшированные пакеты вместо проверки их в реестре.
Однако кэш NPM находится в ~/.npm
в Unix или %AppData%/npm-cache
в Windows. Эти папки не кэшируются по умолчанию в большинстве CI. Например, кэши GitLab CI имеют только хранилище в качестве доступного рабочего пространства. Другие каталоги, такие как домашний каталог или системные каталоги (например, apt
), не кэшируются. Поэтому этот параметр, вероятно, не повлияет на время сборки CI.
В более старой версии NPM опция --progress=false
оказала значительное влияние на время сборки, удалив индикаторы выполнения. Эта проблема, похоже, исчезла, но я больше не могу измерить заметную разницу.
Лучшая практика и, безусловно, выигрыш в скорости - это разделять пакеты для производства и разработки. Передав опцию --only=production
, NPM будет игнорировать зависимости разработки. По указанным выше причинам это не повлияет на кеширование.