McHack

Проблема оказалась до боли банальна, но не очевидна. В плагинах в определении конечного пути для файла я забыл указать точку. Билд функция все понимала правильно и делала все как нужно, тогда как дев-серверу нужен был относительный путь. Смотрим на живом примере:

...PAGES.map(page => new HtmlWebpackPlugin({
      template: `${PAGES_DIR}/${page}`,
      filename: `(вот она красивая, никогда не забывайте ее) => ./${(page == 'index.pug') ? '' : page.replace(/\.pug/, '')+'/'}index.html`,
      inject: 'head',
      excludeAssets: [/personal.*.js/],
      hash: false
    })),

Представьте такую ситуацию. У вас огромный проект с множеством составляющих, над ним работает 4-6 человек и у каждого собственные js и css к примеру, плюс ко всему вы работает с GIT-ом (а сейчас без него никуда). В девелоперской сборке творится корпоративный бардак, куча файлов, куча несжатых картинок и css-файлы на 8К+ строк.

Собственно, тут нам и понадобится сборщик, который соединит воедино все .css, .scss, .styl в один единый минифицированный css-файл. Тоже самое сделает и со скриптами, пожмет картинки и положит их в положенную папку. Вы на выходе имеете довольно оптимизированный и хорошо потерявший в весе проект. Отсюда вы грузите нужное вам на нужную ветку вашего Git-а и отправляется оттуда на сервер. В итоге на сервере вы имеете готовый продукт, без бардака и конечный пользователь не получает ничего лишнего.

Это самый базовый пример и более глобальная цель сборщиков и им подобного. Если же отходить от банальщины, то разработчику просто намного удобнее и приятнее работать. Если же вы не понимаете зачем это все нужно, значит вы просто еще не "доросли" до этого. Рано или поздно и вы придете в эту тему, тогда то и раскроете рот от всех возможностей, которые имеются в том же WebPack :D