ну по логике - откуда докер может знать, что npm install зависит от package.json?

А он и не должен

Ты ему говоришь

каким образом?

а что важно?

Содержимое. Хеш от тара

каким образом?

Когда делаешь докер файл

ну, конкретнее)

Сначала копируешь пакадж, потом делаешь npm i

И докер выполняет инсталл только если поменялся пакадж

ну это же неправильно. Что если я хочу последнии версии пакетов

Правильно. Хочешь последние версии пакетов - меняешь пакадж. Или ты не фиксируешь версии? Рекомендую начать

это частный случай, я говорю про то что докер много на себя берет

Например еще когда?

допустим я кулом выкачиваю что то из интернета

курлом

и хочу что всегда была последняя версия

Это значит - что-то делается не так

ну если докер просто кэширует в такой ситуации - то он не прав

Почему?

чтобы кэшировать, нужно иметь хоть какие то основания полагать, что релузьтат не изменился

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

в общем ясно, докер исходит из того что результат зависит от файлов в последнем ADD

примерно как make

но в make есть phony, в Dockerfile видимо нет такого

Докер каждый раз ориентируется на команду. Если она не менялась - берем кеш. Если менялась - ее и все дальше инвалидируем

https://github.com/docker/docker/issues/1996

Можно явно передать рандом

Сегодня ребята из Cloudflare посоветовали выделить node_modules в отдельный image

приехали

Иногда допустимо

так.. в плане идеи генерации - можно node_module версионировать ( тупо убрать из .gitignore )

ох

это сработает, но явно сделает жизнь сложнее

я про отдельный image

node_modules в гите - норм

Нодмодули в отдельном имадже нужны для ускорения сборки и уменьшении трафика

В гит их, имхо, моветон

почему? наоборот, просто и надежно

Имхо лучше делать слой пресборки

есть только проблема с бинарниками

их таки все равно нужно пересобирать

В гит их, имхо, моветон

Версионирование Bundle-ов - старая давно работающая техника

их таки все равно нужно пересобирать

Зачем?

ну если dev и prod на одной os и архитектуре - то не нужно

Версионирование Bundle-ов - старая давно работающая техника

Нет смысла в этом когда есть докер

ну если dev и prod на одной os и архитектуре - то не нужно

Ну да, хорошая идея - держать билд сервер таким же как прод

ну npm install делает дев, на дев машине

и в гит кладет бинарники

это плохо - в остальном норм

Ну да, хорошая идея - держать билд сервер таким же как прод

У нас это Kuberenetes-кластер, так что удовлетворяет условию)

для ci?

ну npm install делает дев, на дев машине

Нет. Это делает билдсервер

я говорю про node_modules в гите

И опять плохо - а сасс например? Он ж зависит от архитектуры

я и говорю, это единственная проблема

при билде нужно собирать нативные модули

для ci?

Для проекта :)

И опять плохо - а сасс например? Он ж зависит от архитектуры

SASS вообще зло

Злоо

А чего билд зависимостей не собирать в buildDependencies?

Уж всяко лучше, чем в гит кидать

Это что?)

А чего билд зависимостей не собирать в buildDependencies?

Речь шла о том, что эти зависимости должны были бы попасть в эту категорию, если бы она существовала. npm не знает никаких категорий, кроме depends и devDepends

Это то, что попадает в пакет когда он пакуется перед публикацией в реестре.

Но можно в принципе не публиковать, а собирать отдельный тар.

Получится такой пакет-пакетов, как у всех на кухнях есть)

Речь шла о том, что эти зависимости должны были бы попасть в эту категорию, если бы она существовала. npm не знает никаких категорий, кроме depends и devDepends

Не совсем понял. В npm есть 5 типов зависимостей.

Не совсем понял. В npm есть 5 типов зависимостей.

Ну остальные либо изначально специфические, либо бесполезные в данном случае

Ладно, завтра поэкспериментирую

Можно в scripts прописать что то типа "prebuild": "npm install webpack" И собрать всё, что надо с помощью node-gyp

npm default "scripts":{"preinstall": "node-gyp rebuild"} If there is a binding.gyp file in the root of your package, npm will default the preinstall command to compile using node-gyp

@vkurchatkin 👆

https://github.com/babel/phabricator-to-github

йау

есть вопрос

существует ли адекватный sanitizer жс кода?

задача - чекать есть ли во входящем жсе методы поста и гета

редиректов

или еще чего нибудь

regex? :D