Webpack is a module bundler which reads modules with dependencies and produces static assets representing those modules.

It features an extendable loader system which allows bundles to include not only Javascript assets, but CSS, Images, HTML and much more.

For example, using the in-built Javascript loader, css-loader and url-loader:

require("./code.js") // Load Javascript dependency
var css = require("./styles.css"); // Load CSS as a string
var base64Image = require("./image.png"); // Load an image as a base64 string

Would become a single bundled file:

// From code.js
console.log("Hello, World");
// From styles.css
var css = "body { margin: 0; padding: 0; } h1 { color: #FF0000; }";
// From image.png
var base64Image = "data:image/gif;base64,R0lGODlhPQBEAPeoAJosM//AwO/AwHVYZ/z595kzAP/s7P+goOXMv8+fhw/v739/f+8PD98fH/8mJl+fn/9ZWb8/PzWlwv///6wWGbImAPgTEMImIN9gUFCEm/gDALULDN8PAD6atYdCTX9gUNKlj8wZAKUsAOzZz+UMAOsJAP/Z2ccMDA8PD/95eX5NWvsJCOVNQPtfX/8zM8+QePLl38MGBr8JCP+zs9myn/8GBqwpAP/GxgwJCPny78lzYLgjAJ8vAP9fX...";

Dependencies can be defined in any of the most common module styles (CommonJS & AMD).

webpack-hot-middleware

Use with webpack-dev-middleware, by adding webpack-hot-middleware/client to entry.

Config

Add configs as query string to the path. Example:

webpack-hot-middleware/client?path=/__what&timeout=2000&overlay=false

Option	Description
path	The path which the middleware is serving the event stream on
timeout	The time to wait after a disconnection before attempting to reconnect
overlay	Set to false to disable the DOM-based client-side overlay.
reload	Set to true to auto-reload the page when webpack gets stuck.
noInfo	Set to true to disable informational console logging.
quiet	Set to true to disable all console logging.
dynamicPublicPath	Set to true to use webpack publicPath as prefix of path. (We can set __webpack_public_path__ dynamically at runtime in the entry point, see note of output.publicPath)

Webpack loaders can be configured as "preLoaders", "loaders" and "postLoaders". Although they don't have to be, configurations which use linting or other imperative or serial operations can take advantage of these build stages in the pipeline.

The key to understanding loaders and their use is that Webpack will run each module in the require graph through the loader system. Following the example above, this means that as Webpack begins crawling through the imports of your application, it will identify the files required and using a simple regex, will determine which file or file type requires what loader or series of loaders.

Above you can see that all ".js" or ".jsx" files will be es-linted by the eslint-loader in the preLoader phase. Other js|x file types will also be run through the babel-loader in the main loader phase. Also, in the same phase, any .scss files will be loaded into the sass-loader. This allows you to import Sass files in your JS modules and have them be output to the resulting JS bundle or even another separate standalone CSS bundle (using a plugin).

Note: Importing .scss files will only work with Webpack and an appropriate loader. Node will not understand this kind of import without a pre-processor or transpiler.

Also of note in the .scss example is the ability to "chain" loaders using the ! exclamation mark as a "pipe" between different loaders. The example above pipes the output of the "sass-loader" into the "css-loader" and finally to the "style-loader" This could also be performed with an array of loaders: ['style-loader', 'css-loader', 'sass-loader']. Different options are also available to inline loader definitions and follow the query parameter syntax commonly found in URLs.

See also: https://webpack.github.io/docs/loaders.html