Comments 14
Решал подобный кейс для установки оффлайн через npm-модуль shrinkpack
По сути это упакованные в tar-архив зависимости, которые честно ставятся npm в node_modules, но уже без доступа к интернету. Есть конечно проблемы при установке модулей, которые выкачивают бинарники в процессе установки, например phantomjs, но это тоже решаемо.
По сути это упакованные в tar-архив зависимости, которые честно ставятся npm в node_modules, но уже без доступа к интернету. Есть конечно проблемы при установке модулей, которые выкачивают бинарники в процессе установки, например phantomjs, но это тоже решаемо.
Решал подобную задачу на скорую руку. Вариант с кеширующим прокси мне не понравился. Он плохо масштабируется если нескольким разработчикам надо актуализировать зависимости.
Решил вопрос некрасиво, но руки не доходят сделать лучше.
Поднял локальный коуч и набрасал на том же node зеркалирующую утилиту. Она парсит package-lock.json, выгружате пакеты с оригинального npm и публикает на локальной версии, если их там нет. К сожалению резолвинг версий ломается полностью и без package-lock.json проекты в большинстве случаев не собрать.
Плюс очень много проблем с тем же gyp. И есть проблемы с правами доступа на коуч. Заливать пакеты как есть (с оригинальными авторами и информацией) можно только из под всея админа коуча.
Для полноценной реализации нужна и сильная доработка оригинальных npm скриптов на коуч, и серьёзная доработка зеркалирующей утилиты.
Очень грустно, что многие веб разработчики с которыми я общался о вопросах зеркалирования даже не задумываются считая интернет вечным.
Решил вопрос некрасиво, но руки не доходят сделать лучше.
Поднял локальный коуч и набрасал на том же node зеркалирующую утилиту. Она парсит package-lock.json, выгружате пакеты с оригинального npm и публикает на локальной версии, если их там нет. К сожалению резолвинг версий ломается полностью и без package-lock.json проекты в большинстве случаев не собрать.
Плюс очень много проблем с тем же gyp. И есть проблемы с правами доступа на коуч. Заливать пакеты как есть (с оригинальными авторами и информацией) можно только из под всея админа коуча.
Для полноценной реализации нужна и сильная доработка оригинальных npm скриптов на коуч, и серьёзная доработка зеркалирующей утилиты.
Очень грустно, что многие веб разработчики с которыми я общался о вопросах зеркалирования даже не задумываются считая интернет вечным.
gyp и вообще все, у чего есть привязка к платформам — определенно проблема, но ее я решил в итоге пересборкой тарбола с уже поставленными нейтив частями и вырезанием постинстолла, а так же sha проверок в package.json соответствующих. Я не совсем понял про актуализацию зависимостей несколькими разработчиками — это про что? Когда хотим получить все самое свеженькое по возможности и для разных проектов?
Актуализация зависимостей, это когда несколько разработчиков используют разные пакеты и иногда им надо обновляться.
Если я в своё время правильно понял документацию на кеширующие npm прокси, когда изучал вопрос, то просто добавить новые файлы в их хранилище не получится и надо сначала взять с сервера полный кеш, потом на нём обновиться, потом вернуть обновлённый обратно на сервер. Но изучал я этот вопрос больше года назад. Мог что-то не правильно понять сам. Могла измениться ситуация за это время.
Если я в своё время правильно понял документацию на кеширующие npm прокси, когда изучал вопрос, то просто добавить новые файлы в их хранилище не получится и надо сначала взять с сервера полный кеш, потом на нём обновиться, потом вернуть обновлённый обратно на сервер. Но изучал я этот вопрос больше года назад. Мог что-то не правильно понять сам. Могла измениться ситуация за это время.
Nexus есть универсальное опенсорс решение, может какие хочешь пакетные менеджеры
ставиться одной командой запуска докер образа)
ставиться одной командой запуска докер образа)
Ну докер-образы были, увы, не вариант в доставшейся среде. Я бегло мазнул взглядом и не совсем понял, Nexus, он таки только про проксирование? Как выглядит кейс переноса кэша с машины с инторнетами на машину без оных?
Nexus про всё. Прокси и\или локальный, NPM и многое другое. Прекрасно работает не в Docker.
Есть standalone инсталяция.
Можно настраивать и приватные (без интернета) и проксированные (например, npmjs.com) репозитории. А еще оба варианта можно обьединить в репозиторий-группу.
Переносить, в любом случае, очень просто. Nexus тупо хранит всё, что ему (или через него) загрузили, у себя в отдельной папке $NEXUS_WORK/storage/%имя репозитория%
Из минусов — нет поиска по пакетам
Тут ссылка для почитать про настройку NPM репозиториев
Вообще интересное решение, спасибо всем предложившим, сегодня поставил у себя на машине и поигрался немного. Может быть слегка оверкил, если нужно только npm перенос настроить, но в целом здорово, если бы сразу загуглилась эта вещь, стоять бы ей вместо verdaccio. :)
Есть поиск…
Можно еще посмотреть на yarn и его опцию offline-mirror.
Так можно будет обойтись без локального сервера, пакетный менеджер будет сам копировать файлы из кеша вместо запросов к серверу.
Классно, спасибо за статью. Nexus для моего случая правда немного перебор, а с Node.js приходится решать ровно ту же самую задачу, которую Вы уже решили.
Sign up to leave a comment.
Локальный (offline) npm репозиторий