Changes headers

Author: Pavithra K

content/how-to/shim.md

@@ -4,7 +4,7 @@ title: How to Shim Third Party Libraries?
 
 `webpack` as a module bundler can understand modules written as ES2015 modules, CommonJS or AMD. But many times, while using third party libraries, we see that they expect dependencies which are global aka `$` for `jquery`. They might also be creating global variables which need to be exported. Here we will see different ways to help webpack understand these __broken modules__.
 
-### Prefer unminified src(CommonJs/AMD) files over bundled `dist` versions.
+## Prefer unminified CommonJs/AMD files over bundled `dist` versions.
 
 Most modules link the `dist` version in the `main` field of their `package.json`. While this is useful for most developers, for webpack it is better to alias the src version because this way webpack is able to optimize dependencies better (e.g. when using the [DedupePlugin](/concepts/plugins#DedupePlugin)). However in most cases `dist` works fine as well.
 
@@ -21,7 +21,7 @@ module.exports = {
 };
 ```
 
-### ProvidePlugin
+## ProvidePlugin
 The [ProvidePlugin](/concepts/plugins#ProvidePlugin) makes a module available as a variable in every other module required by `webpack`. The module is required only if you use the variable.
 Most legacy modules rely on the presence of specific globals, like jQuery plugins do on `$` or `jQuery`. In this scenario, you can configure webpack to prepend `var $ = require(“jquery”)` everytime it encounters the global `$` identifier.
 
@@ -38,7 +38,7 @@ var webpack = require("webpack");
     ]
 ```
 
-### `imports-loader`
+## `imports-loader`
 
 [`imports-loader`](https://github.com/webpack/imports-loader) inserts necessary globals into the required legacy module.
 For example, Some legacy modules rely on `this` being the `window` object. This becomes a problem when the module is executed in a CommonJS context where `this` equals `module.exports`. In this case you can override `this` using the `imports-loader`.
@@ -67,7 +67,7 @@ module: {
 }
 ```
 
-### `exports-loader`
+## `exports-loader`
 
 Let's say a library creates a global variable that it expects it's consumers to use. In this case we can use [`exports-loader`](https://github.com/webpack/exports-loader), to export that global variable in CommonJS format.
 
@@ -85,7 +85,7 @@ module: {
 }
 ```
 
-### `scripts-loader`
+## `scripts-loader`
 
 The [scripts-loader](https://github.com/webpack/script-loader) evaluates code in the global context, just like you would add the code into a `script` tag. In this mode every normal library should work. require, module, etc. are undefined.
 Note: The file is added as string to the bundle. It is not minimized by `webpack`, so use a minimized version. There is also no dev tool support for libraries added by this loader.
@@ -98,7 +98,7 @@ require('script-loader!legacy.js')
 globalLegacyVariable() // This global variable will be added as a result of the script loader
 ```
 
-### `noParse` option
+## `noParse` option
 
 When there is no AMD/CommonJS version of the module and you want to include the `dist`, you can flag this module as `noParse`. Then `webpack` will just include the module without parsing it, which can be used to improve the build time. This means that any feature requiring the AST, like the `ProvidePlugin`, will not work.