Comments 5
Почему не обратиться к документации и не распились на отдельные prod и dev конфиги, а общую часть вынести в common? Потом это все смержить с помощью webpack-merge . Вместо того чтобы создавать своего Франкенштейна.
Кажется что все уже давно за вас придумали, но мы же инженеры, надо свое эдакое написать. Чтобы потом люди приходили и разбирались, что тут происходит, когда на Vite решат переехать.
Думаю очевидно, что пример, описанный в статье, синтетический. И оговаривалось, что речь исключительно про Webpack, нравится он вам или нет.
Но что если у нас несколько prod и dev конгифов? Описанная в статье идея используется на реальном проекте, где один и тот же код собирается в статичесий сайт и в веб-компонент (с shadow DOM). Для dev-режима у нас есть классическая сборка (удобнее разрабатывать), а есть и сборка в режиме веб-компонента с shadow DOM (нужно тестировать, так как в проде работает именно в таком режиме).
Получается уже 4 разных конфига. `webpack-merge` решает задачу, да. Но вот читаемости и сопровождаемости конфигурационного файла он никак не обеспечивает.
В целом не так уж и плохо. Почему до сих пор сидите на require'ах? Это дерьмо мамонта уже с 13-й версии ноды не обязтельно использовать. А в данный момент текущая LTS версия уже 20-я. Переходите на импорты уже, время давно настало.
Да вроде "есть не просит", работает. Однако некоторые пакеты, тот же [node-config](https://www.npmjs.com/package/config) припасли сюрпризы для любителей es-импортов.
Очень многие пакеты сейчас уже переходят в своих новых версиях на чистую поддержку ES синтаксиса, да и правильно это. Как пример: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c
А легаси всякое давно пора потихоньку вычищать и уж точно не следует его сейчас поддерживать. Ещё год-два - и жизнь на устаревших requier'ах начнёт превращаться в боль просто потому что всё меньше свежих версий библиотек в принципе будет поддерживать работу с устаревшей системой загрузки модулей.
Наводим порядок в конфигах Webpack