Besides exporting a single config object, there are a few more ways that cover other needs as well.
--env
Eventually you will find the need to disambiguate in your webpack.config.js
between development and production builds. You have (at least) two options:
Instead of exporting a configuration object, you may return a function which accepts an environment as argument. When running webpack, you may specify build environment keys via --env
, such as --env.production
or --env.platform=web
.
-module.exports = { +module.exports = function(env) { + return { plugins: [ new webpack.optimize.UglifyJsPlugin({ + compress: env.production // compress only in production build }) ] + }; };
webpack will run the function exported by the configuration file and wait for a Promise to be returned. Handy when you need to asynchronously load configuration variables.
module.exports = () => { return new Promise((resolve, reject) => { setTimeout(() => { resolve({ entry: './app.js', /* ... */ }) }, 5000) }) }
Instead of exporting a single configuration object/function, you may export multiple configurations. When running webpack, all configurations are built. For instance, this is useful for bundling a library for multiple targets such as AMD and CommonJS:
module.exports = [{ output: { filename: './dist-amd.js', libraryTarget: 'amd' }, entry: './app.js', }, { output: { filename: './dist-commonjs.js', libraryTarget: 'commonjs' }, entry: './app.js', }]
© 2012–2016 Tobias Koppers
Licensed under the Creative Commons Attribution License 4.0.
https://webpack.js.org/configuration/configuration-types/