ОБНОВЛЕНИЕ 11 января 2016 г .: PR был объединен, webpack-dev-server теперь использует http-proxy-middleware, поэтому следующий код не нужен.
ОБНОВЛЕНИЕ 3 января 2016 г .: Я внедрил http-proxy-middleware в проект webpack-dev-server. Вы можете прокомментировать / внести свой вклад в PR здесь: https://github.com/webpack/webpack-dev-server/pull/359/files
Я недавно пользуюсь Webpack и очень люблю его. Это самый простой сборщик, который я когда-либо использовал. Однако сегодня я столкнулся с проблемой и хочу вкратце о ней написать.
В проекте, над которым я работаю, есть серверный REST API, работающий на порту 8080, и интерфейсный веб-сайт, работающий на порту 8081. Поскольку проекту может потребоваться поддержка старых браузеров (например, IE8), я не могу полагаться на CORS Заголовки на стороне API. В таком случае лучший способ делать вызовы API - использовать прокси.
Оказывается, у Webpack есть прокси-функциональность, построенная поверх node-http-proxy (NHP), отлично! Не так быстро. В моем конкретном случае все запросы к frontend: 8081 / api перенаправлялись на backend: 8080. Например, запрос к frontend: 8081 / api / users / 1 должен проксировать запрос к backend: 8080 / users / 1. Оказывается, на момент написания этого нельзя было сделать с использованием какой-либо комбинации конфигурации.
Ну хватит об этом. Пора написать собственный прокси. К счастью, Webpack предлагает webpack-dev-middleware, который позволяет в значительной степени создавать собственный webpack-dev-server, хотя он не поддерживает встроенный параметр командной строки.
Моя реализация сервера разработки не является супер-полной, но она выполняет свою работу. Я использую http-proxy-middleware, поскольку это гораздо более настраиваемая прокси-библиотека для Node. Я также использую webpack-hot-middleware (не предоставляется Webpack) для горячей перезагрузки и для имитации встроенной функциональности webpack-dev-server .
