Comments 23
"serve": "webpack-dev-server --config ./webpack.config.js --profile --watch --progress",
"hmr": "webpack-dev-server --config ./webpack.config.js --profile --watch --progress",
serve и hmr имеют одинаковый код, это нормально?Я только не понял как здесь работать, с сервером данных? Можно ли его здесь подтянуть например как middleware?
Установка глобальных модулей
А вы знали, что npm подкладывает локальную папку ./node_modules/.bin
в $PATH, так что глобальные модули ставить не обязательно?
Достаточно добавить webpack в package.json, и его можно будет использовать в секции scripts.
Вот статья с более подробным объяснением: https://www.joezimjs.com/javascript/no-more-global-npm-packages/
Конфиг вебпака у вас получился какой-то чрезмерно усложненный. Почитают люди статьи вроде вашей, и у них складывается впечатление, что проще делать невозможно. А на самом деле можно и нужно.
- Зачем вам такая куча профилей и команд для вебпака? По сути, обычно нужны только две
- build — собирает для продакшена, со AOT и другими оптимизациями
- dev — запускает dev-server с дебаг-сборкой и hot-reload
Остальные команды лишь сбивают с толку, чтобы новый разработчик на проекте запутался в их многообразии
- Я правильно понимаю, что команда
npm run prodServer
запускает вебпак просто чтобы открыть статические файлы? Не проще будет использовать однострочникpython -mSimpleHTTPServer
, который есть в любой системе, или npm-модуль serve, если хочется все на JS? Создание пустого файла./webpack-prod-server.js
чтобы надурить вебпак, это дичайший костыль, не надо так
После выкидывания лишних команд и другого оверхеда в коде останутся лишь простые бинарные условия, типа
if(isProd) {
config.push(new AotPlugin({...}));
config.push(new webpack.optimize.UglifyJsPlugin());
}
Такой конфиг и при разработке понятнее, и статья с ним выглядит аккуратнее
1) представленные команды: dev, hmr — показывают разницу между обычной разработкой и hmr. Prod — собираем прод. Clean наврятли кого-то запутал.
2) специально показано как не используя доп. Модулей запустить статический сервер.
- От изобилия команд для запуска вебпака наглядность только падает. Определитесь сами, нужен вам hmr или нет, и оставьте только одну из двух. Читатели и пользователи от этого только выиграют.
- Не используя дополнительных иструментов можно и гвоздь микроскопом забить, но зачем? Использовать вебпак в качестве статического сервера — тот еще изврат.
А еще советую посмотреть на webpack-blocks, если еще не видели.
Это набор типовых конфигураций для webpack, которые подключаются в пару строк.
Недавно посмотрел на последний Quick start и слегка удивился. SystemJS убрали совсем и все делают через Web Pack, что слегка, обескураживает, поскольку при малейшем изменении в коде приходится пересобрать проект, что бы увидеть его на экране. У нас же достаточно сохранить .ts файл и нажать F5 в браузере. Typescript автоматом пересоздаст .js (compile on save = true), System JS его автоматом подхватит. Очень удобно и nodejs постоянно в разработке не нужен поскольку Typescript у нас компилируется через Visual Studio.
Может я не понял нового подхода, предлагаемого как в Angular Quick start, так и в этой статье? На первый взгляд это кажется очень неудобно.
webpack --watch
и в принципе это всё, имеете то же самое обновление по F5. Только компиляция .ts должна быть настроена не отдельно, а тоже через вебпак.
Если запустить webpack --watch
, то он будет отслеживать изменения файлов и пересобирать только часть. Проект целиком пересобирать не нужно. Еще можно использовать webpack-dev-server
, c ним еще и страница в браузере сама перезагрузится.
Польза от вебпака в дев-моде в том, что вы используете один и тот же тул для разработки и продакшена. Так будет меньше шансов словить какой-то баг, который не воспроизвести локально, а только в проде.
Настройка среды разработки Webpack 3 + Angular 4: от сложного к простому