Pull to refresh

Comments 14

Решал подобный кейс для установки оффлайн через npm-модуль shrinkpack
По сути это упакованные в tar-архив зависимости, которые честно ставятся npm в node_modules, но уже без доступа к интернету. Есть конечно проблемы при установке модулей, которые выкачивают бинарники в процессе установки, например phantomjs, но это тоже решаемо.
Решал подобную задачу на скорую руку. Вариант с кеширующим прокси мне не понравился. Он плохо масштабируется если нескольким разработчикам надо актуализировать зависимости.
Решил вопрос некрасиво, но руки не доходят сделать лучше.
Поднял локальный коуч и набрасал на том же node зеркалирующую утилиту. Она парсит package-lock.json, выгружате пакеты с оригинального npm и публикает на локальной версии, если их там нет. К сожалению резолвинг версий ломается полностью и без package-lock.json проекты в большинстве случаев не собрать.
Плюс очень много проблем с тем же gyp. И есть проблемы с правами доступа на коуч. Заливать пакеты как есть (с оригинальными авторами и информацией) можно только из под всея админа коуча.
Для полноценной реализации нужна и сильная доработка оригинальных npm скриптов на коуч, и серьёзная доработка зеркалирующей утилиты.
Очень грустно, что многие веб разработчики с которыми я общался о вопросах зеркалирования даже не задумываются считая интернет вечным.
gyp и вообще все, у чего есть привязка к платформам — определенно проблема, но ее я решил в итоге пересборкой тарбола с уже поставленными нейтив частями и вырезанием постинстолла, а так же sha проверок в package.json соответствующих. Я не совсем понял про актуализацию зависимостей несколькими разработчиками — это про что? Когда хотим получить все самое свеженькое по возможности и для разных проектов?
Актуализация зависимостей, это когда несколько разработчиков используют разные пакеты и иногда им надо обновляться.
Если я в своё время правильно понял документацию на кеширующие npm прокси, когда изучал вопрос, то просто добавить новые файлы в их хранилище не получится и надо сначала взять с сервера полный кеш, потом на нём обновиться, потом вернуть обновлённый обратно на сервер. Но изучал я этот вопрос больше года назад. Мог что-то не правильно понять сам. Могла измениться ситуация за это время.
Нет, если я правильно вас понял, то с этим серьезных проблем нет — все что пройдет через npm i окажется в сторадже, несколько версий вместе выглядят как-то так:
image
Собственно потом накатывается или с заменой всего или с заменой старого, чтобы не морочаться с отбором только новых вещей.
Nexus есть универсальное опенсорс решение, может какие хочешь пакетные менеджеры
ставиться одной командой запуска докер образа)
Ну докер-образы были, увы, не вариант в доставшейся среде. Я бегло мазнул взглядом и не совсем понял, Nexus, он таки только про проксирование? Как выглядит кейс переноса кэша с машины с инторнетами на машину без оных?
Nexus про всё. Прокси и\или локальный, NPM и многое другое. Прекрасно работает не в Docker.

Есть standalone инсталяция.
Можно настраивать и приватные (без интернета) и проксированные (например, npmjs.com) репозитории. А еще оба варианта можно обьединить в репозиторий-группу.


Переносить, в любом случае, очень просто. Nexus тупо хранит всё, что ему (или через него) загрузили, у себя в отдельной папке $NEXUS_WORK/storage/%имя репозитория%


Из минусов — нет поиска по пакетам


Тут ссылка для почитать про настройку NPM репозиториев

Вообще интересное решение, спасибо всем предложившим, сегодня поставил у себя на машине и поигрался немного. Может быть слегка оверкил, если нужно только npm перенос настроить, но в целом здорово, если бы сразу загуглилась эта вещь, стоять бы ей вместо verdaccio. :)

Вы правы, я работал с REST API Nexus'а, и вот там поиска по артефактам нет.
Сам npm работает с пакетами в своём индексе и там всё хорошо.

Можно еще посмотреть на yarn и его опцию offline-mirror.


Так можно будет обойтись без локального сервера, пакетный менеджер будет сам копировать файлы из кеша вместо запросов к серверу.

Классно, спасибо за статью. Nexus для моего случая правда немного перебор, а с Node.js приходится решать ровно ту же самую задачу, которую Вы уже решили.
Sign up to leave a comment.

Articles