formidable-playbook

### Start with good base plugins Webpack has a rich plugin ecosystem, including both [core](https://webpack.github.io/docs/list-of-plugins.html) and [open source](http://nipstr.com/#webpack plugin) [modules](https://www.npmjs.com/browse/keyword/webpack-plugin) modules. Webpack also has a straight forward interface to [write your own plugins](https://webpack.github.io/docs/plugins.html).   - [`UglifyJsPlugin`](#uglifyjsplugin) - [`DedupePlugin`](#dedupeplugin) - [`OccurrenceOrderPlugin`](#occurrenceorderplugin) - [`DefinePlugin`](#defineplugin) - [`lodash-webpack-plugin`](#lodash-webpack-plugin)  ##### [`UglifyJsPlugin`](https://webpack.github.io/docs/list-of-plugins.html#uglifyjsplugin) * Recommended?: **Yes** The `UglifyJsPlugin` minimizes code using [Uglifyjs](https://github.com/mishoo/UglifyJS2) and with most options proxied through to the plugin. Typical configuration: ```js new webpack.optimize.UglifyJsPlugin() ``` ##### [`DedupePlugin`](https://webpack.github.io/docs/list-of-plugins.html#dedupeplugin) * Recommended?: **Yes for `webpack@1`** Collapse identical code chunks to a single reference. The plugin looks for identical occurrences of the same code and replaces real code chunks in the bundle with integer references (think pointers in C/C++) to find an earlier instance of the same code. Typical configuration: ```js new webpack.optimize.DedupePlugin() ``` **Note - npm Deduplication**: This "deduplication" is separate from the deduplication that `npm` performs while flattening the dependency tree in `node_modules`. It is just a scan by webpack to coalesce identical code chunks to a single reference.  **Webpack 2+ Note**: This plugin has been removed as of `webpack@2` with a note that it "isn't needed anymore" because of npm deduplication. Unfortunately, npm deduplication can often fail where the plugin would yield a smaller bundle. Hopefully, this plugin will be resurrected by core or the community as a new OSS project. ##### [`OccurrenceOrderPlugin`](https://webpack.github.io/docs/list-of-plugins.html#occurrenceorderplugin) * Recommended?: **Maybe for `webpack@1`** Reorder module / chunk ids by order of most-to-least occurring. This reduces raw code size since smaller integer indexes are `require`-ed more. Also makes the order of modules deterministic. Typical configuration: ```js new webpack.optimize.OccurrenceOrderPlugin() ``` **Assessment**: The size gains are often not significant, and can make the ultimate minified + gzipped bundle size actually _larger_. And this calculus can change over time, so generally speaking size should not be a motivating factor for enabling this plugin. However, if you need a deterministic ordering of chunks and modules, this plugin is appropriate. **Webpack 2+ Note**: Enabled by default now. ##### [`DefinePlugin`](https://webpack.github.io/docs/list-of-plugins.html#defineplugin) * Recommended?: **Maybe** Add raw replacement strings for free variables in code. This literally rewrites your source code with replacements. With a bit of strategy and a project convention you can opportunistically have code paths removed / variables replaced for a bespoke optimized production build. Additionally, many frameworks / tools such as React, expect a definition of `"process.env.NODE_ENV": JSON.stringify("production")` for the most optimized build of included code. Example configuration: ```js new webpack.optimize.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("production"), // or "\"production\"" "DEBUG": false // or "false" }) ``` **Note**: to expand a variable to a quoted string, you must use `JSON.stringify`. If we had this source: ```js if (process.env.NODE_ENV === "production") { console.log("I'm in prod!"); } if (DEBUG) { console.log("Explicit debug switch"); } ``` with the above configuration, the output would be: ```js if ("production" === "production") { console.log("I'm in prod!"); } if (false) { console.log("Explicit debug switch"); } ``` which with minification would become: ```js console.log("I'm in prod!"); ``` ##### [`lodash-webpack-plugin`](https://github.com/lodash/lodash-webpack-plugin) * Recommended?: **Maybe** If your project uses [lodash](https://lodash.com/) and can handle some limiting constraints and complexities, this plugin provides some useful optimizations for reducing code size. Typically you'll want to already use the [`babel-plugin-lodash`](https://github.com/lodash/babel-plugin-lodash) which optimizes some things in a webpack / babel build. This plugin then goes further by removing lots of internal code, grouped in logical ["feature sets"](https://github.com/lodash/lodash-webpack-plugin#feature-sets) **Big Warning**: The plugin's only real value is removing internal stuff that your code **may still depend on**. And it's not always obvious what is getting removed. For example, looking to a simple example provided at: https://github.com/exogen/test-lodash-webpack-plugin we have this starting code: ```js import get from "lodash/get"; import assert from "assert"; const x = { a: { b: { c: 1 } } }; assert.strictEqual(get(x, "a.b.c"), 1); ``` Using the plugin with no configuration: ```js new LodashModuleReplacementPlugin() ``` will fail the assertion because the result of `get(x, "a.b.c")` is `undefined`. The reason is that all deep path traversal code is removed under the hood by default. Thus to support deep path traversal for the `get()` call, we would need to configure the plugin like: ```js new LodashModuleReplacementPlugin({ paths: true }) ``` Thus, this plugin is not really a "fire and forget" thing, but rather a power tool with very few safeties. You must be familiar with all the of the feature sets removed, probably need to coordinate re-enabling key ones for your specific project, and ensure that all lodash usage is tested / complies with the internal rewriting of the plugin. For example, after enabling it without configuration in the Victory project, we later found that we needed several configurations enabled. See: https://github.com/FormidableLabs/builder-victory-component/pull/64 In short, it's easier to just not add the plugin. But if you need that extra bit of super-optimized lodash tuning, you can enable the plugin and accept the complexity cost of it.