docs(sideEffects): documented rule and updated tree-shaking terms

src/content/configuration/module.md

@@ -8,6 +8,7 @@ contributors:
   - jhnns
   - dylanonelson
   - byzyk
+  - pnevares
 ---
 
 These options determine how the [different types of modules](/concepts/modules) within a project will be treated.
@@ -246,6 +247,13 @@ module.exports = {
 An array of [`Rules`](#rule) that is also used when the Rule matches.
 
 
+## `Rule.sideEffects`
+
+Possible values: `false | an array of paths`
+
+Indicate what parts of the module contain side effects. See [Tree Shaking](/guides/tree-shaking/#mark-the-file-as-side-effect-free) for details.
+
+
 ## `Rule.test`
 
 `Rule.test` is a shortcut to `Rule.resource.test`. If you supply a `Rule.test` option, you cannot also supply a `Rule.resource`. See [`Rule.resource`](#rule-resource) and [`Condition.test`](#condition) for details.

src/content/guides/tree-shaking.md

@@ -12,6 +12,7 @@ contributors:
   - gish
   - lumo10
   - byzyk
+  - pnevares
 related:
   - title: "webpack 4 beta — try it today!"
     url: https://medium.com/webpack/webpack-4-beta-try-it-today-6b1d27d7d7e2#9a67
@@ -23,7 +24,7 @@ related:
 
 _Tree shaking_ is a term commonly used in the JavaScript context for dead-code elimination. It relies on the [static structure](http://exploringjs.com/es6/ch_modules.html#static-module-structure) of ES2015 module syntax, i.e. [`import`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) and [`export`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export). The name and concept have been popularized by the ES2015 module bundler [rollup](https://github.com/rollup/rollup).
 
-The webpack 2 release came with built-in support for ES2015 modules (alias _harmony modules_) as well as unused module export detection. The new webpack 4 release expands on this capability with a way to provide hints to the compiler via the `"sideEffects"` `package.json` flag to denote which files in your project are "pure" and therefore safe to prune if unused.
+The webpack 2 release came with built-in support for ES2015 modules (alias _harmony modules_) as well as unused module export detection. The new webpack 4 release expands on this capability with a way to provide hints to the compiler via the `"sideEffects"` `package.json` property to denote which files in your project are "pure" and therefore safe to prune if unused.
 
 T> The remainder of this guide will stem from [Getting Started](/guides/getting-started). If you haven't read through that guide already, please do so now.
 
@@ -167,15 +168,13 @@ T> Note that any imported file is subject to tree shaking. This means if you use
 }
 ```
 
-Finally, `"sideEffects"` can also be set from the [`module.rules` config option](https://github.com/webpack/webpack/issues/6065#issuecomment-351060570).
+Finally, `"sideEffects"` can also be set from the [`module.rules` configuration option](/configuration/module/#module-rules).
 
 ## Minify the Output
 
-So we've cued up our "dead code" to be dropped by using the `import` and `export` syntax, but we still need to drop it from the bundle. To do that, we'll use the `-p` (production) webpack compilation flag to enable the uglifyjs minification plugin.
+So we've cued up our "dead code" to be dropped by using the `import` and `export` syntax, but we still need to drop it from the bundle. To do that, we'll use the `-p` (production) webpack compilation flag to enable `UglifyJSPlugin`.
 
-T> Note that the `--optimize-minimize` flag can be used to insert the `UglifyJsPlugin` as well.
-
-As of webpack 4, this is also easily toggled via the `"mode"` config option, set to `"production"`.
+As of webpack 4, this is also easily toggled via the `"mode"` configuration option, set to `"production"`.
 
 __webpack.config.js__
 
@@ -193,6 +192,8 @@ module.exports = {
 };
 ```
 
+T> Note that the `--optimize-minimize` flag can be used to enable `UglifyJSPlugin` as well.
+
 With that squared away, we can run another `npm run build` and see if anything has changed.
 
 Notice anything different about `dist/bundle.js`? Clearly the whole bundle is now minified and mangled, but, if you look carefully, you won't see the `square` function included but will see a mangled version of the `cube` function (`function r(e){return e*e*e}n.a=r`). With minification and tree shaking our bundle is now a few bytes smaller! While that may not seem like much in this contrived example, tree shaking can yield a significant decrease in bundle size when working on larger applications with complex dependency trees.
@@ -203,7 +204,7 @@ Notice anything different about `dist/bundle.js`? Clearly the whole bundle is no
 So, what we've learned is that in order to take advantage of _tree shaking_, you must...
 
 - Use ES2015 module syntax (i.e. `import` and `export`).
-- Add a "sideEffects" entry to your project's `package.json` file.
+- Add a "sideEffects" property to your project's `package.json` file.
 - Include a minifier that supports dead code removal (e.g. the `UglifyJSPlugin`).
 
 You can imagine your application as a tree. The source code and libraries you actually use represent the green, living leaves of the tree. Dead code represents the brown, dead leaves of the tree that are consumed by autumn. In order to get rid of the dead leaves, you have to shake the tree, causing them to fall.