Resolve conflicts on next branch

.gitignore

@@ -5,3 +5,4 @@ generated
 support-*.json
 starter-kits-data.json
 .antwar
+.vscode

src/components/SidebarItem/SidebarItem.scss

@@ -38,6 +38,7 @@
     padding-left: 1.5em;
     overflow: hidden;
     list-style: none;
+    line-height: 19px;
 
     &:before {
       content: '';

src/content/api/stats.md

@@ -3,6 +3,7 @@ title: Stats Data
 sort: 3
 contributors:
   - skipjack
+  - franjohn21
 ---
 
 When compiling source code with webpack, users can generate a JSON file containing statistics about modules. These statistics can be used to analyze an application's dependency graph as well as to optimize compilation speed. The file is typically generated with the following CLI command:
@@ -24,6 +25,7 @@ The top-level structure of the output JSON file is fairly straightforward but th
   "hash": "11593e3b3ac85436984a", // Compilation specific hash
   "time": 2469, // Compilation time in milliseconds
   "filteredModules": 0, // A count of excluded modules when [`exclude`](/configuration/stats/#stats) is passed to the [`toJson`](/api/node/#stats-tojson-options-) method
+  "outputPath": "/", // path to webpack output directory
   "assetsByChunkName": {
     // Chunk name to emitted asset(s) mapping
     "main": "web.js?h=11593e3b3ac85436984a",

src/content/configuration/configuration-languages.md

@@ -26,8 +26,8 @@ and then proceed to write your configuration:
 __webpack.config.ts__
 
 ```typescript
-import * as webpack from 'webpack';
-import * as path from 'path';
+import path from 'path';
+import webpack from 'webpack';
 
 const config: webpack.Configuration = {
   entry: './foo.js',
@@ -40,6 +40,8 @@ const config: webpack.Configuration = {
 export default config;
 ```
 
+Above sample assumes version >= 2.7 or newer of TypeScript is used with the new `esModuleInterop` and `allowSyntheticDefaultImports` compiler options in your `tsconfig.json` file.
+
 Note that you'll also need to check your `tsconfig.json` file. If the module in `compilerOptions` in `tsconfig.json` is `commonjs`, the setting is complete, else webpack will fail with an error. This occurs because `ts-node` does not support any module syntax other than `commonjs`.
 
 There are two solutions to this issue:

src/content/guides/production.md

@@ -177,7 +177,7 @@ __webpack.prod.js__
 +       sourceMap: true
 +     })
     ]
-  })
+  });
 ```
 
 T> Avoid `inline-***` and `eval-***` use in production as they can increase bundle size and reduce the overall performance.
@@ -200,12 +200,13 @@ __webpack.prod.js__
     plugins: [
       new UglifyJSPlugin({
         sourceMap: true
-      }),
+-     })
++     }),
 +     new webpack.DefinePlugin({
 +       'process.env.NODE_ENV': JSON.stringify('production')
 +     })
     ]
-  })
+  });
 ```
 
 T> Technically, `NODE_ENV` is a system environment variable that Node.js exposes into running scripts. It is used by convention to determine dev-vs-prod behavior by server tools, build scripts, and client-side libraries. Contrary to expectations, `process.env.NODE_ENV` is not set to `"production"` __within__ the build script `webpack.config.js`, see [#2537](https://github.com/webpack/webpack/issues/2537). Thus, conditionals like `process.env.NODE_ENV === 'production' ? '[name].[hash].bundle.js' : '[name].bundle.js'` within webpack configurations do not work as expected.

src/content/guides/progressive-web-application.md

@@ -3,6 +3,7 @@ title: Progressive Web Application
 sort: 14
 contributors:
   - johnnyreilly
+  - chenxsan
 ---
 
 T> This guide extends on code examples found in the [Output Management](/guides/output-management) guide.
@@ -78,7 +79,7 @@ __webpack.config.js__
 +     title: 'Progressive Web Application'
 -   })
 +   }),
-+   new WorkboxPlugin({
++   new WorkboxPlugin.GenerateSW({
 +     // these options encourage the ServiceWorkers to get in there fast 
 +     // and not allow any straggling "old" SWs to hang around
 +     clientsClaim: true,

src/content/guides/tree-shaking.md

@@ -40,7 +40,7 @@ webpack-demo
   |- index.html
 |- /src
   |- index.js
-  |- math.js
++ |- math.js
 |- /node_modules
 ```
 
@@ -172,6 +172,8 @@ module.exports = {
 };
 ```
 
+T> Note that the `--optimize-minimize` flag can be used to insert the `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.