и установки пакетов для ноды
у меня просто проблема, как бы делать реюз толстой папки node_modules а то это ужас, тупят билды знатно запилил на гитлабе кеширование в с3, но всё равно не супер уж быстро слишком много файлов генерит после yarn install еще и не могут отказаться от установки dev dependencies чтоб прод сбилдать нужно ставить все дев зависимости, если установить только прод зависимости то ниче не сбилдится😄
переходи на pnpm
пробовал тестить сегодня всё поначалу шло неплохо, НО по неведомой мне причине он для дев депенденси стал просить новые модули которых ранее не было в package.json потому плюнул, без разрабов манал красноглазить)
ну мы банально отдельным слоем это ставим и кеширование на уровне образа работает То есть COPY ./yarn.lock ./ COPY ./package.json ./ RUN yarn install ... Это в кеше первых слоев. yarn.lock/package.json меняются только когда зависимости меняются. А это не так часто. Сорян что очевидные вещи говорю. Но у нас там не рокет сайнс
> еще и не могут отказаться от установки dev dependencies На фронте это просто решается. Ставим зависимости, собираем проект. В образ копируем только результат сборки. На бэке nodejs dev зависиомсти не нужны, а если зачем-то нужны то вопросы к прогеру, зачем, и если они нужны для работы прода, то это уже не dev зависимость, а обычная. Соотвественно туда и переносится.
к сожалению деплой в прод завязан на версии тегов, которые патчатся в package.json, поэтому он изменяется частенько так то также реализовано в докерфайле
нет, только поле version в package.json
тогда же вообще замечательно. Объясните ситуацию с кешем. И дайте выбор 1) либо мы ждем долго перекчу ноде модулей при каждой смене версии 2) либо мы отказываемся от такого пустяка как version в package.json и наслаждаемся кешем и не ждем каждый раз перекачку
там видимо не совсем по правильному реализовано по хорошему нужно переделывать ибо при сборке прода нужны модули которые находятся в дев зависимостях, я то могу это перекинуть в прод, но не уверен что от этого что-то изменится, так как файлов может накопиться столько же при установке и да, у нас и фронт и бэк в одном yarn build бежит
но если у вас норм чуваки и обновляют yarn.lock нормально. Тогда в yarn.lock будет всегда соотествовать тому что указано в package.json. Поэтому скорее всего можно COPY ./yarn.lock RUN yarn COPY ./package.json Но надо чтобы прогеры нормально обновляли yarn.lock. А то будут истории, "я поставил зависимость, а ее нет в билде". Просто такая конструкция ошибок не выдаст, просто не поставит зависиомсть. А предыдушая выдаст ошибку, что зависиомсти нет в yarn.lock
касательно второго пункта имеет смысл конечно
команда на инсталл такая yarn install --frozen-lockfile я так понимаю что локфайл с таким ключем не обновляется
> фронт и бэк в одном yarn build бежит Это все решается. У нас также.
да вроде он и просто при вызове "yarn" не обновляется. Вроде --frozen-lockfile там по дефолту (я не помню)
точнее не так, У нас общий yarn.lock для фронта и бека. Ну тут опять. Я дал выбор. Либо вы разделяете это, либо смиритесь с тем что у вас в бэке лишние зависимости и образы столько весят
да, это нужно разделять разраб об этом говорил но наверное самая заезженная ситуация, сейчас много тасок, активно пилим, времени нет переделать😂
ну это же не вам надо. Если их устраивает то пусть так и остается. Проблемы вы озвучили, как можно сделать по другому тоже. Ваша работа на этом все
та вот не устраивает, если бы не одновременно много пайплайнов запускали, то может и не так болюче было бы но так как это фиче деплои и сборки, которых много и которые часто то аффектит производительность
в целом вам может подойти такой вариант: COPY ./yarn.lock ./ RUN yarn ... ... Но надо договорится чтобы не забывали обновить yarn.lock при обновлении зависимостей. Так как в таком кейсе он ошибок не выдаст, когда зависимости в package.json не соотвествуют тому что в yarn.lock
Обсуждают сегодня