Hacker News new | ask | show | jobs
by shard972 2790 days ago
Was recently looking for a reverse proxy for a project at work that utilizes multiple webpack repos that eventually gets built into one big webapp.

Without a proxy your forced to only work on one area of the app at once so hopefully something like this will let me run all webpack instances under the same endpoint during dev.

2 comments

I use hoxy[1] for a lot of similar use cases, e.g. integration testing third party code.

[1] https://github.com/greim/hoxy

https://github.com/webpack/webpack-dev-server

Would this work? Or what’s the issue you are referring to?

I'm pretty sure he's aware of Webpack's devserver. A common problem is multiple libraries (with different webpack configs) being built that are required inside a single app. I guess GP's approach is to run multiple devservers, all on a different port, and then put a reverse proxy in front of it.

Last I checked, webpack does support building multiple scripts (by turning the `entry` config setting into an array or object), but they'll all have the same settings (so that intermediate results used by multiple entry points only need to be built once). If webpack since added support for multiple entire configurations behind a single webpack dev server then that would be splendid of course, but last I checked they didn't.

We have a similar problem at my company that we build our frontend React code for the browser and for node, and the latter has subtly different build settings. Our solution is to run the webpack devserver for the browser, a webpack watch mode for the nodejs version, and then we run the nodejs version using nodemon so that it reloads whenever the webpack watch mode rebuilds. The nodejs version contains an expressjs reverse proxy to forward requests for things in the `assets` directory to the webpack devserver. It's messy, but it works. My biggest beef is that it's rather dissimilar from our production setup.

Of course if we'd done node+browser from the start we'd have written our code such that the node version could be run in node without a compilation step, but we were first frontend-only and then added server rendering, and by then the code already made use of a number of webpack-isms (such as weird require("raw!css!stylus!myfile.styl") type of stuff).

Webpack actually supports exporting an array of configurations. https://github.com/webpack/webpack-dev-server/tree/master/ex...