Thanks alot for this article. You were very clear. However you never told us how to configure the npm script for launching the app in development mode. Or production mode. Tried out this: ` “start”: “webpack-dev-server –progress –colors –config./webpack.config.js”,` It built 11 modules with this warning: `WARNING in configuration The ‘mode’ option has not been set. Set ‘mode’ option to ‘development’ or ‘production’ to enable defaults for this environment.` But my none of my servers was launched.

• Webpack Dev Server Inline

How do I go about this? Thank you Valentino! After setting up the HTML webpack plugin with the webpack config and the template html file in the src file, I can successfully run npm run build and get an index.html file built in my dist folder.

Webpack Dev Server Inline

However, none of the app.js content is in the output index.html. Just the html from the template.

I can see the content of the app.js in the main.js file, but not in the html. Any theories as to my goof?

Note I’m developing in windows, a big change for me at my new job. I’m used to OS. I tried using my webpack config from an app I built in OS and got the exact same problem, which makes me think it’s a windows thing.

Webpack: Configuring webpack-dev-server 3 minute read TIL how to configure webpack-dev-server (WDS) to both serve files from the publicPath and proxy APIs on different domains to avoid cross site request warnings in the browser. This post will focus on setting up WDS and some of the configuration options I wound up using. WDS works by holding your bundled files in memory on the dev server. This allows for the quick diffing and serving of changes to application assets as they change during development.

WDS “stores” these files at the output.publicPath. The following gist contains the webpack config I will reference throughout this post. NOTE: I am using so the config might look slightly different if you’re used to webpack 1 config: The devServer.contentBase Option Yet another path related configuration option what makes this one different from path and publicPath (which were covered in my last blog post)? Per the documentation, the option tells the dev server where content should be served from. In other words, if there are any files that the devServer should reference from disk (like other generated code as part of your build steps) it should be located at the contentBase. ContentBase can be an array, so there can be multiple locations in your file system that make up the devServer’s contentBase if necessary. In my case, I used contentBase to point my devServer to some static locale files that were generated during a build step for our app.

Unlike the bundled files served from publicPath, the locale files served from contentBase do not change during development, and therefore do not need to be held in memory on the dev server. They can be referenced directly from disk at the contentBase. A pro-tip I learned: if there aren’t any HTML files configured to be served from / on the devServer, if you access the base path directly you can see the files currently being stored at contentBase. If you want to see files being reference at publicPath (in other words, files held in memory on the dev server and not written to disk), navigate to /webpack-dev-server! Also, a word of warning: It appears that if a file with the same path && name exists at both the contentBase and the publicPath, that the contentBase version will be preferentially served by the devServer.

I discovered this when I had an old bundle.min.js at the contentBase while I was debugging my configuration, and changed the publicPath to be the same as my contentBase. Changes that I made to files in my bundle were not being reflected in the browser, even through a hard refresh of the page. The devServer.proxy option The whole reason I started this re-tooling process was to get to WDS proxies the moment is finally here! The option allows you to specify a path that, when a request is made to WDS with that path, the server will forward the request to the target in the configuration. So from my configuration example above: my devServer.proxy object contains a key '/api2', which itself contains a target mapping of My dev server is configured to run at NOTE: the devServer.https option is set to true in my configuration above, so my devServer will use a self-signed certificate to feign an https connection (you can also provide your own if needed).

Any requests made to will be proxied to which allows me to send requests to the domain where my app originated and get data from a different one. Pretty nifty! Diagram of What Proxy Looks Like (after pathRewrite) You might also be asking yourself: what if my other domain doesn’t have a route of /api2? Well you’re in luck, because WDS allows you to pass a pathRewrite option to your proxy mapping, in which you can pass a regex to match on the mapped path and change it to a different one that makes sense for your new domain (see configuration above). One final trick that proxy does, is it can proxy requests to https domains that have broken certificates! Just set the secure option to false, and your requests will resolve with no problem.

This wasn’t the end of my webpack learnings: I also worked on loader and plugin configuration to transpile our.jsx files to ES5 and extract our CSS from the main webpack bundles into their own files to reduce the main bundle size. Updated: April 23, 2017.