Да вроде "есть не просит", работает. Однако некоторые пакеты, тот же [node-config](https://www.npmjs.com/package/config) припасли сюрпризы для любителей es-импортов.
Думаю очевидно, что пример, описанный в статье, синтетический. И оговаривалось, что речь исключительно про Webpack, нравится он вам или нет.
Но что если у нас несколько prod и dev конгифов? Описанная в статье идея используется на реальном проекте, где один и тот же код собирается в статичесий сайт и в веб-компонент (с shadow DOM). Для dev-режима у нас есть классическая сборка (удобнее разрабатывать), а есть и сборка в режиме веб-компонента с shadow DOM (нужно тестировать, так как в проде работает именно в таком режиме).
Получается уже 4 разных конфига. `webpack-merge` решает задачу, да. Но вот читаемости и сопровождаемости конфигурационного файла он никак не обеспечивает.
Формальное определение и математическая формула, всё же, корректны. Пример, да, может вызывать споры, но моя цель была максимально упростить понимание для новичков. Если взяли Петины апельсины, сложили с Мишиными, а потом с Танечкиными, то их количество будет таким же, как если сложить сначала Танечкины и Петины апельсины, а потом к ним прибавить Мишины. Но по сути, это "от перестановки слагаемых сумма не меняется".
На своих проектах я запилил конфиг Webpack-а, используя паттерн "Строитель". Строк кода, может быть и больше, чем лапша на if-ах, но зато всё по полочкам и понятно что происходит.
Спасибо за идею вынести всё в отдельных npm-пакет.
Наверно тут важно сравнение с предыдущими результатами измерений, с накопленной статистикой. Если новое измерение (на основе 5 проверок) сильно отличается от предыдущих, то с релизом что-то не так.
Jquery — да, боль болючая. Но никто не мешает в ActiveAdmin встраивать компоненты на Vue. Мы пробовали, полёт нормальный. Всё-таки отдельный SPA требует слишком много ресурсов на создание/поддержку. Зачастую бизнес их не даёт.
Беда в том, что бывают и довольно популярные пакеты, которые могут класть болт на semver. Спасибо автору за то, что он несколько раз повторил и выделил жирным шрифтом, что надо всё тестировать и проверять даже после минорных апдейтов.
Где баги — там напряги
А давайте на Rust перепишем вообще ВСЁ!
Да вроде "есть не просит", работает. Однако некоторые пакеты, тот же [node-config](https://www.npmjs.com/package/config) припасли сюрпризы для любителей es-импортов.
Думаю очевидно, что пример, описанный в статье, синтетический. И оговаривалось, что речь исключительно про Webpack, нравится он вам или нет.
Но что если у нас несколько prod и dev конгифов? Описанная в статье идея используется на реальном проекте, где один и тот же код собирается в статичесий сайт и в веб-компонент (с shadow DOM). Для dev-режима у нас есть классическая сборка (удобнее разрабатывать), а есть и сборка в режиме веб-компонента с shadow DOM (нужно тестировать, так как в проде работает именно в таком режиме).
Получается уже 4 разных конфига. `webpack-merge` решает задачу, да. Но вот читаемости и сопровождаемости конфигурационного файла он никак не обеспечивает.
Вывод: обновляйте ваши постгресы, друзья мои!
Книжка Get Programming Haskell, страница 564-565, она же в русском переводе "Программируй на Haskell"
Да, вы совершенно правы, спасибо.
Формальное определение и математическая формула, всё же, корректны. Пример, да, может вызывать споры, но моя цель была максимально упростить понимание для новичков. Если взяли Петины апельсины, сложили с Мишиными, а потом с Танечкиными, то их количество будет таким же, как если сложить сначала Танечкины и Петины апельсины, а потом к ним прибавить Мишины. Но по сути, это "от перестановки слагаемых сумма не меняется".
То есть в CI-пайплайне в логи будет попадать мешанина?
На своих проектах я запилил конфиг Webpack-а, используя паттерн "Строитель". Строк кода, может быть и больше, чем лапша на if-ах, но зато всё по полочкам и понятно что происходит.
Спасибо за идею вынести всё в отдельных npm-пакет.
Автору не 25, инфа 100%. Автор — тот ещё тролль, инфа 100%. Автор — технический специалист высочайшего уровня, инфа 100%.
¯\_(ツ)_/¯