Merge branch 'master' into docs-patch-71docs-patch-71

22 files changed, 683 insertions, 643 deletions

diff --git a/doc/development/fe_guide/accessibility.md b/doc/development/fe_guide/accessibility.md
index df32242a522..64c793cfd64 100644
--- a/doc/development/fe_guide/accessibility.md
+++ b/doc/development/fe_guide/accessibility.md
@@ -5,8 +5,16 @@
 [Chrome Accessibility Developer Tools][chrome-accessibility-developer-tools]
 are useful for testing for potential accessibility problems in GitLab.
 
-Accessibility best-practices and more in-depth information is available on
-[the Audit Rules page][audit-rules] for the Chrome Accessibility Developer Tools.
+The [axe][axe-website] browser extension (available for [Firefox][axe-firefox-extension] and [Chrome][axe-chrome-extension]) is
+also a handy tool for running audits and getting feedback on markup, CSS and even potentially problematic color usages.
+
+Accessibility best-practices and more in-depth information are available on
+[the Audit Rules page][audit-rules] for the Chrome Accessibility Developer Tools. The "[awesome a11y][awesome-a11y]" list is also a
+useful compilation of accessibility-related material.
 
 [chrome-accessibility-developer-tools]: https://github.com/GoogleChrome/accessibility-developer-tools
 [audit-rules]: https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules
+[axe-website]: https://www.deque.com/axe/
+[axe-firefox-extension]: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/
+[axe-chrome-extension]: https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd
+[awesome-a11y]: https://github.com/brunopulis/awesome-a11y
diff --git a/doc/development/fe_guide/architecture.md b/doc/development/fe_guide/architecture.md
index c67389b169e..3d27f67a8a6 100644
--- a/doc/development/fe_guide/architecture.md
+++ b/doc/development/fe_guide/architecture.md
@@ -11,7 +11,7 @@ Architectural decisions should be accessible to everyone, so please document
 them in the relevant Merge Request discussion or by updating our documentation
 when appropriate.
 
-You can find the Frontend Architecture experts on the [team page](https://about.gitlab.com/team).
+You can find the Frontend Architecture experts on the [team page](https://about.gitlab.com/company/team/).
 
 ## Examples
 
diff --git a/doc/development/fe_guide/axios.md b/doc/development/fe_guide/axios.md
index 0d9397c3bd5..6e7cf523f36 100644
--- a/doc/development/fe_guide/axios.md
+++ b/doc/development/fe_guide/axios.md
@@ -1,15 +1,18 @@
 # Axios
+
 We use [axios][axios] to communicate with the server in Vue applications and most new code.
 
 In order to guarantee all defaults are set you *should not use `axios` directly*, you should import `axios` from `axios_utils`.
 
 ## CSRF token
+
 All our request require a CSRF token.
 To guarantee this token is set, we are importing [axios][axios], setting the token, and exporting `axios` .
 
 This exported module should be used instead of directly using `axios` to ensure the token is set.
 
 ## Usage
+
 ```javascript
   import axios from './lib/utils/axios_utils';
 
@@ -35,7 +38,7 @@ Advantages over [`spyOn()`]:
 
 - no need to create response objects
 - does not allow call through (which we want to avoid)
-- simple API to test error cases 
+- simple API to test error cases
 - provides `replyOnce()` to allow for different responses
 
 We have also decided against using [axios interceptors] because they are not suitable for mocking.
diff --git a/doc/development/fe_guide/components.md b/doc/development/fe_guide/components.md
index 52462a4bec9..096ce8ca25a 100644
--- a/doc/development/fe_guide/components.md
+++ b/doc/development/fe_guide/components.md
@@ -14,28 +14,29 @@ See also the [corresponding UX guide](https://design.gitlab.com/#/components/dro
 1. Use the HTML structure provided by the [docs][bootstrap-dropdowns]
 1. Add a specific class to the top level `.dropdown` element
 
-    ```Haml
-    .dropdown.my-dropdown
-      %button{ type: 'button', data: { toggle: 'dropdown' }, 'aria-haspopup': true, 'aria-expanded': false }
-        %span.dropdown-toggle-text
-          Toggle Dropdown
-        = icon('chevron-down')
-
-      %ul.dropdown-menu
-        %li
-          %a
-            item!
-    ```
-
-    Or use the helpers
-    ```Haml
-    .dropdown.my-dropdown
-      = dropdown_toggle('Toogle!', { toggle: 'dropdown' })
-      = dropdown_content
-        %li
-          %a
-            item!
-    ```
+   ```Haml
+   .dropdown.my-dropdown
+     %button{ type: 'button', data: { toggle: 'dropdown' }, 'aria-haspopup': true, 'aria-expanded': false }
+       %span.dropdown-toggle-text
+         Toggle Dropdown
+       = icon('chevron-down')
+
+     %ul.dropdown-menu
+       %li
+         %a
+           item!
+   ```
+
+   Or use the helpers
+
+   ```Haml
+   .dropdown.my-dropdown
+     = dropdown_toggle('Toogle!', { toggle: 'dropdown' })
+     = dropdown_content
+       %li
+         %a
+           item!
+   ```
 
 [bootstrap-dropdowns]: https://getbootstrap.com/docs/3.3/javascript/#dropdowns
 
diff --git a/doc/development/fe_guide/design_patterns.md b/doc/development/fe_guide/design_patterns.md
index 0342d16a87c..2f372f783f5 100644
--- a/doc/development/fe_guide/design_patterns.md
+++ b/doc/development/fe_guide/design_patterns.md
@@ -53,6 +53,7 @@ When writing a class that needs to manipulate the DOM guarantee a container opti
 This is useful when we need that class to be instantiated more than once in the same page.
 
 Bad:
+
 ```javascript
 class Foo {
   constructor() {
@@ -63,6 +64,7 @@ new Foo();
 ```
 
 Good:
+
 ```javascript
 class Foo {
   constructor(opts) {
@@ -72,6 +74,7 @@ class Foo {
 
 new Foo({ container: '.my-element' });
 ```
+
 You can find an example of the above in this [class][container-class-example];
 
 [container-class-example]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/mini_pipeline_graph_dropdown.js
diff --git a/doc/development/fe_guide/development_process.md b/doc/development/fe_guide/development_process.md
index f3fdaa3b883..ae0e2361840 100644
--- a/doc/development/fe_guide/development_process.md
+++ b/doc/development/fe_guide/development_process.md
@@ -12,8 +12,7 @@ This checklist is intended to help us during development of bigger features/refa
 
 Please use your best judgement when to use it and please contribute new points through merge requests if something comes to your mind.
 
----
-
+```
 ### Frontend development
 
 #### Planning development
@@ -24,15 +23,15 @@ Please use your best judgement when to use it and please contribute new points t
 - [ ] Are all necessary UX specifications available that you will need in order to implement? Are there new UX components/patterns in the designs? Then contact the UI component team early on. How should error messages or validation be handled?
 - [ ] **Library usage** Use Vuex as soon as you have even a medium state to manage, use Vue router if you need to have different views internally and want to link from the outside. Check what libraries we already have for which occasions.
 - [ ] **Plan your implementation:**
-    - [ ] **Architecture plan:** Create a plan aligned with GitLab's architecture, how you are going to do the implementation, for example Vue application setup and its components (through [onion skinning](https://gitlab.com/gitlab-org/gitlab-ce/issues/35873#note_39994091)), Store structure and data flow, which existing Vue components can you reuse. It's a good idea to go through your plan with another engineer to refine it.
-    - [ ] **Backend:** The best way is to kickoff the implementation in a call and discuss with the assigned Backend engineer what you will need from the backend and also when. Can you reuse existing API's? How is the performance with the planned architecture? Maybe create together a JSON mock object to already start with development.
-    - [ ] **Communication:** It also makes sense to have for bigger features an own slack channel (normally called #f_{feature_name}) and even weekly demo calls with all people involved.
-    - [ ] **Dependency Plan:** Are there big dependencies in the plan between you and others, then maybe create an execution diagram to show what is blocking which part and the order of the different parts.
-    - [ ] **Task list:** Create a simple checklist of the subtasks that are needed for the implementation, also consider creating even sub issues. (for example show a comment, delete a comment, update a comment, etc.). This helps you and also everyone else following the implementation
+  - [ ] **Architecture plan:** Create a plan aligned with GitLab's architecture, how you are going to do the implementation, for example Vue application setup and its components (through [onion skinning](https://gitlab.com/gitlab-org/gitlab-ce/issues/35873#note_39994091)), Store structure and data flow, which existing Vue components can you reuse. It's a good idea to go through your plan with another engineer to refine it.
+  - [ ] **Backend:** The best way is to kickoff the implementation in a call and discuss with the assigned Backend engineer what you will need from the backend and also when. Can you reuse existing API's? How is the performance with the planned architecture? Maybe create together a JSON mock object to already start with development.
+  - [ ] **Communication:** It also makes sense to have for bigger features an own slack channel (normally called #f_{feature_name}) and even weekly demo calls with all people involved.
+  - [ ] **Dependency Plan:** Are there big dependencies in the plan between you and others, then maybe create an execution diagram to show what is blocking which part and the order of the different parts.
+  - [ ] **Task list:** Create a simple checklist of the subtasks that are needed for the implementation, also consider creating even sub issues. (for example show a comment, delete a comment, update a comment, etc.). This helps you and also everyone else following the implementation
 - [ ] **Keep it small** To make it easier for you and also all reviewers try to keep merge requests small and merge into a feature branch if needed. To accomplish that you need to plan that from the start. Different methods are:
-    - [ ] **Skeleton based plan** Start with an MR that has the skeleton of the components with placeholder content. In following MRs you can fill the components with interactivity. This also makes it easier to spread out development on multiple people.
-    - [ ] **Cookie Mode** Think about hiding the feature behind a cookie flag if the implementation is on top of existing features
-    - [ ] **New route** Are you refactoring something big then you might consider adding a new route where you implement the new feature and when finished delete the current route and rename the new one. (for example 'merge_request' and 'new_merge_request')
+  - [ ] **Skeleton based plan** Start with an MR that has the skeleton of the components with placeholder content. In following MRs you can fill the components with interactivity. This also makes it easier to spread out development on multiple people.
+  - [ ] **Cookie Mode** Think about hiding the feature behind a cookie flag if the implementation is on top of existing features
+  - [ ] **New route** Are you refactoring something big then you might consider adding a new route where you implement the new feature and when finished delete the current route and rename the new one. (for example 'merge_request' and 'new_merge_request')
 - [ ] **Setup** Is there any specific setup needed for your implementation (for example a kubernetes cluster)? Then let everyone know if it is not already mentioned where they can find documentation (if it doesn't exist - create it)
 - [ ] **Security** Are there any new security relevant implementations? Then please contact the security team for an app security review. If you are not sure ask our [domain expert](https://about.gitlab.com/handbook/engineering/frontend/#frontend-domain-experts)
 
@@ -57,8 +56,7 @@ Please use your best judgement when to use it and please contribute new points t
 - [ ] Are there any big changes on how and especially how frequently we use the API then let production know about it
 - [ ] Smoke test of the RC on dev., staging., canary deployments and .com
 - [ ] Follow up on issues that came out of the review. Create issues for discovered edge cases that should be covered in future iterations.
-
----
+```
 
 ### Share your work early
 
@@ -66,7 +64,7 @@ Please use your best judgement when to use it and please contribute new points t
    GitLab's architecture.
 1. Add a diagram to the issue and ask a frontend architect in the slack channel `#fe_architectural` about it.
 
-  ![Diagram of Issue Boards Architecture](img/boards_diagram.png)
+   ![Diagram of Issue Boards Architecture](img/boards_diagram.png)
 
 1. Don't take more than one week between starting work on a feature and
    sharing a Merge Request with a reviewer or a maintainer.
diff --git a/doc/development/fe_guide/droplab/droplab.md b/doc/development/fe_guide/droplab/droplab.md
index 2f8c79abde1..1c6d895b3ab 100644
--- a/doc/development/fe_guide/droplab/droplab.md
+++ b/doc/development/fe_guide/droplab/droplab.md
@@ -25,6 +25,7 @@ If you do not provide any arguments, it will globally query and instantiate all
   <!-- ... -->
 <ul>
 ```
+
 ```js
 const droplab = new DropLab();
 droplab.init();
@@ -45,6 +46,7 @@ You can add static list items.
   <li>Static value 2</li>
 <ul>
 ```
+
 ```js
 const droplab = new DropLab();
 droplab.init();
@@ -62,6 +64,7 @@ a non-global instance of DropLab using the `DropLab.prototype.init` method.
   <!-- ... -->
 <ul>
 ```
+
 ```js
 const trigger = document.getElementById('trigger');
 const list = document.getElementById('list');
@@ -79,6 +82,7 @@ You can also add hooks to an existing DropLab instance using `DropLab.prototype.
 <a href="#" id="trigger" data-dropdown-trigger="#list">Toggle</a>
 <ul id="list" data-dropdown><!-- ... --><ul>
 ```
+
 ```js
 const droplab = new DropLab();
 
@@ -109,6 +113,7 @@ for all `data-dynamic` dropdown lists tracked by that DropLab instance.
   <li><a href="#" data-id="{{id}}">{{text}}</a></li>
 </ul>
 ```
+
 ```js
 const droplab = new DropLab();
 
@@ -131,6 +136,7 @@ the data as the second argument and the `id` of the trigger element as the first
   <li><a href="#" data-id="{{id}}">{{text}}</a></li>
 </ul>
 ```
+
 ```js
 const droplab = new DropLab();
 
@@ -160,6 +166,7 @@ dropdown lists, one of which is dynamic.
   </ul>
 </div>
 ```
+
 ```js
 const droplab = new DropLab();
 
@@ -216,6 +223,7 @@ Some plugins require configuration values, the config object can be passed as th
 <a href="#" id="trigger" data-dropdown-trigger="#list">Toggle</a>
 <ul id="list" data-dropdown><!-- ... --><ul>
 ```
+
 ```js
 const droplab = new DropLab();
 
diff --git a/doc/development/fe_guide/droplab/plugins/ajax.md b/doc/development/fe_guide/droplab/plugins/ajax.md
index b6a883ce6c4..4b76b207d88 100644
--- a/doc/development/fe_guide/droplab/plugins/ajax.md
+++ b/doc/development/fe_guide/droplab/plugins/ajax.md
@@ -17,18 +17,19 @@ Add the `Ajax` object to the plugins array of a `DropLab.prototype.init` or `Dro
 <a href="#" id="trigger" data-dropdown-trigger="#list">Toggle</a>
 <ul id="list" data-dropdown><!-- ... --><ul>
 ```
+
 ```js
-  const droplab = new DropLab();
+const droplab = new DropLab();
 
-  const trigger = document.getElementById('trigger');
-  const list = document.getElementById('list');
+const trigger = document.getElementById('trigger');
+const list = document.getElementById('list');
 
-  droplab.addHook(trigger, list, [Ajax], {
-    Ajax: {
-      endpoint: '/some-endpoint',
-      method: 'setData',
-    },
-  });
+droplab.addHook(trigger, list, [Ajax], {
+  Ajax: {
+    endpoint: '/some-endpoint',
+    method: 'setData',
+  },
+});
 ```
 
 Optionally you can set `loadingTemplate` to a HTML string. This HTML string will
diff --git a/doc/development/fe_guide/droplab/plugins/filter.md b/doc/development/fe_guide/droplab/plugins/filter.md
index 1f188c64fe4..b867394a241 100644
--- a/doc/development/fe_guide/droplab/plugins/filter.md
+++ b/doc/development/fe_guide/droplab/plugins/filter.md
@@ -17,25 +17,26 @@ Add the `Filter` object to the plugins array of a `DropLab.prototype.init` or `D
   <li><a href="#" data-id="{{id}}">{{text}}</a></li>
 <ul>
 ```
+
 ```js
-  const droplab = new DropLab();
-
-  const trigger = document.getElementById('trigger');
-  const list = document.getElementById('list');
-
-  droplab.init(trigger, list, [Filter], {
-    Filter: {
-      template: 'text',
-    },
-  });
-
-  droplab.addData('trigger', [{
-    id: 0,
-    text: 'Jacob',
-  }, {
-    id: 1,
-    text: 'Jeff',
-  }]);
+const droplab = new DropLab();
+
+const trigger = document.getElementById('trigger');
+const list = document.getElementById('list');
+
+droplab.init(trigger, list, [Filter], {
+  Filter: {
+    template: 'text',
+  },
+});
+
+droplab.addData('trigger', [{
+  id: 0,
+  text: 'Jacob',
+}, {
+  id: 1,
+  text: 'Jeff',
+}]);
 ```
 
 Above, the input string will be compared against the `test` key of the passed data objects.
diff --git a/doc/development/fe_guide/droplab/plugins/input_setter.md b/doc/development/fe_guide/droplab/plugins/input_setter.md
index e4050213869..db492da478a 100644
--- a/doc/development/fe_guide/droplab/plugins/input_setter.md
+++ b/doc/development/fe_guide/droplab/plugins/input_setter.md
@@ -22,33 +22,34 @@ You can also set the `InputSetter` config to an array of objects, which will all
   <li><a href="#" data-id="{{id}}">{{text}}</a></li>
 <ul>
 ```
+
 ```js
-  const droplab = new DropLab();
-
-  const trigger = document.getElementById('trigger');
-  const list = document.getElementById('list');
-
-  const input = document.getElementById('input');
-  const div = document.getElementById('div');
-
-  droplab.init(trigger, list, [InputSetter], {
-    InputSetter: [{
-      input: input,
-      valueAttribute: 'data-id',
-    } {
-      input: div,
-      valueAttribute: 'data-id',
-      inputAttribute: 'data-selected-id',
-    }],
-  });
-
-  droplab.addData('trigger', [{
-    id: 0,
-    text: 'Jacob',
-  }, {
-    id: 1,
-    text: 'Jeff',
-  }]);
+const droplab = new DropLab();
+
+const trigger = document.getElementById('trigger');
+const list = document.getElementById('list');
+
+const input = document.getElementById('input');
+const div = document.getElementById('div');
+
+droplab.init(trigger, list, [InputSetter], {
+  InputSetter: [{
+    input: input,
+    valueAttribute: 'data-id',
+  } {
+    input: div,
+    valueAttribute: 'data-id',
+    inputAttribute: 'data-selected-id',
+  }],
+});
+
+droplab.addData('trigger', [{
+  id: 0,
+  text: 'Jacob',
+}, {
+  id: 1,
+  text: 'Jeff',
+}]);
 ```
 
 Above, if the second list item was clicked, it would update the `#input` element
diff --git a/doc/development/fe_guide/emojis.md b/doc/development/fe_guide/emojis.md
index 38794c47965..6d324d4c4a0 100644
--- a/doc/development/fe_guide/emojis.md
+++ b/doc/development/fe_guide/emojis.md
@@ -3,10 +3,10 @@
 GitLab supports native unicode emojis and fallsback to image-based emojis selectively
 when your platform does not support it.
 
-# How to update Emojis
+## How to update Emojis
 
  1. Update the `gemojione` gem
- 1. Update `fixtures/emojis/index.json` from [Gemojione](https://github.com/jonathanwiesel/gemojione/blob/master/config/index.json).
+ 1. Update `fixtures/emojis/index.json` from [Gemojione](https://github.com/bonusly/gemojione/blob/master/config/index.json).
     In the future, we could grab the file directly from the gem.
     We should probably make a PR on the Gemojione project to get access to
     all emojis after being parsed or just a raw path to the `json` file itself.
diff --git a/doc/development/fe_guide/event_tracking.md b/doc/development/fe_guide/event_tracking.md
index 6ab3fa4acf3..1b417d4c8c2 100644
--- a/doc/development/fe_guide/event_tracking.md
+++ b/doc/development/fe_guide/event_tracking.md
@@ -1,79 +1,76 @@
-# Event Tracking
+# Event tracking
 
-We use [Snowplow](https://github.com/snowplow/snowplow) for tracking custom events (available in GitLab [Enterprise Edition](https://about.gitlab.com/pricing/) only).
+GitLab provides `Tracking`, an interface that wraps
+[Snowplow](https://github.com/snowplow/snowplow) for tracking custom events.
+It uses Snowplow's custom event tracking functions.
 
-## Generic tracking function
-
-In addition to Snowplow's built-in method for tracking page views, we use a generic tracking function which enables us to selectively apply listeners to events.
-
-The generic tracking function can be imported in EE-specific JS files as follows:
+The tracking interface can be imported in JS files as follows:
 
 ```javascript
-import { trackEvent } from `ee/stats`;
+import Tracking from `~/tracking`;
 ```
 
-This gives the user access to the `trackEvent` method, which takes the following parameters:
+## Tracking in HAML or Vue templates
 
-| parameter        | type   | description                                                                                                                                                                                                                                                                                                                            | required |
-| ---------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
-| `category`       | string | Describes the page that you're capturing click events on. Unless infeasible, please use the Rails page attribute `document.body.dataset.page` by default.                                                                                                                                                                              | true     |
-| `eventName`      | string | Describes the action the user is taking. The first word should always describe the action. For example, clicks should be `click` and activations should be `activate`. Use underscores to describe what was acted on. For example, activating a form field would be `activate_form_input`. Clicking on a dropdown is `click_dropdown`. | true     |
-| `additionalData` | object | Additional data such as `label`, `property`, and `value` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy).                                                                                                                                          | false    |
+To avoid having to do create a bunch of custom javascript event handlers, when working within HAML or Vue templates, we can add `data-track-*` attributes to elements of interest. This way, all elements that have a `data-track-event` attribute to automatically have event tracking bound.
 
-Read more about instrumentation and the taxonomy in the [Product Handbook](https://about.gitlab.com/handbook/product/feature-instrumentation).
-
-### Tracking in `.js` and `.vue` files
+Below is an example of `data-track-*` attributes assigned to a button in HAML:
 
-The most simple use case is to add tracking programmatically to an event of interest in Javascript.
+```haml
+%button.btn{ data: { track_event: "click_button", track_label: "template_preview", track_property: "my-template", track_value: "" } }
+```
 
-The following example demonstrates how to track a click on a button in Javascript by calling the `trackEvent` method explicitly:
+We can then setup tracking for large sections of a page, or an entire page by telling the Tracking interface to bind to it.
 
 ```javascript
-import { trackEvent } from `ee/stats`;
+import Tracking from '~/tracking';
 
-trackEvent('dashboard:projects:index', 'click_button', {
-    label: 'create_from_template',
-    property: 'template_preview',
-    value: 'rails',
+// for the entire document
+new Tracking().bind();
+
+// for a container element
+document.addEventListener('DOMContentLoaded', () => {
+  new Tracking('my_category').bind(document.getElementById('my-container'));
 });
+
 ```
 
-### Tracking in HAML templates
+When you instantiate a Tracking instance you can provide a category. If none is provided, `document.body.dataset.page` will be used. When you bind the Tracking instance you can provide an element. If no element is provided to bind to, the `document` is assumed.
 
-Sometimes we want to track clicks for multiple elements on a page. Creating event handlers for all elements could soon turn into a tedious task.
+Below is a list of supported `data-track-*` attributes:
 
-There's a more convenient solution to this problem. When working with HAML templates, we can add `data-track-*` attributes to elements of interest. This way, all elements that have both `data-track-label` and `data-track-event` attributes assigned get marked for event tracking. All we have to do is call the `bindTrackableContainer` method on a container which allows for better scoping.
+| attribute             | required | description |
+|:----------------------|:---------|:------------|
+| `data-track-event`    | true     | Action the user is taking. Clicks should be `click` and activations should be `activate`, so for example, focusing a form field would be `activate_form_input`, and clicking a button would be `click_button`. |
+| `data-track-label`    | false    | The `label` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). |
+| `data-track-property` | false    | The `property` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). |
+| `data-track-value`    | false    | The `value` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). If omitted, this will be the elements `value` property or an empty string. For checkboxes, the default value will be the element's checked attribute or `false` when unchecked. |
 
-Below is an example of `data-track-*` attributes assigned to a button in HAML:
+## Tracking in raw Javascript
 
-```ruby
-%button.btn{ data: { track_label: "create_from_template", track_property: "template_preview", track_event: "click_button", track_value: "my-template" } }
-```
+Custom events can be tracked by directly calling the `Tracking.event` static function, which accepts the following arguments:
+
+| argument   | type   | default value              | description |
+|:-----------|:-------|:---------------------------|:------------|
+| `category` | string | document.body.dataset.page | Page or subsection of a page that events are being captured within. |
+| `event`    | string | 'generic'                  | Action the user is taking. Clicks should be `click` and activations should be `activate`, so for example, focusing a form field would be `activate_form_input`, and clicking a button would be `click_button`. |
+| `data`     | object | {}                         | Additional data such as `label`, `property`, and `value` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). These will be set as empty strings if you don't provide them. |
 
-By calling `bindTrackableContainer('.my-container')`, click handlers get bound to all elements located in `.my-container` provided that they have the necessary `data-track-*` attributes assigned to them.
+Tracking can be programmatically added to an event of interest in Javascript, and the following example demonstrates tracking a click on a button by calling `Tracking.event` manually.
 
 ```javascript
-import Stats from 'ee/stats';
+import Tracking from `~/tracking`;
 
-document.addEventListener('DOMContentLoaded', () => {
-  Stats.bindTrackableContainer('.my-container', 'category');
-});
+document.getElementById('my_button').addEventListener('click', () => {
+  Tracking.event('dashboard:projects:index', 'click_button', {
+    label: 'create_from_template',
+    property: 'template_preview',
+    value: 'rails',
+  });
+})
 ```
 
-The second parameter in `bindTrackableContainer` is optional. If omitted, the value of `document.body.dataset.page` will be used as category instead.
-
-Below is a list of supported `data-track-*` attributes:
-
-| attribute             | description                                                                                                                                                                                                     | required |
-| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
-| `data-track-label`    | The `label` in `trackEvent`                                                                                                                                                                                     | true     |
-| `data-track-event`    | The `eventName` in `trackEvent`                                                                                                                                                                                 | true     |
-| `data-track-property` | The `property` in `trackEvent`. If omitted, an empty string will be used as a default value.                                                                                                                    | false    |
-| `data-track-value`    | The `value` in `trackEvent`. If omitted, this will be `target.value` or empty string. For checkboxes, the default value being tracked will be the element's checked attribute if `data-track-value` is omitted. | false    |
-
-Since Snowplow is an Enterprise Edition feature, it's necessary to create a CE backport when adding `data-track-*` attributes to HAML templates in most cases.
-
-## Testing
+## Toggling tracking on or off
 
 Snowplow can be enabled by navigating to:
 
diff --git a/doc/development/fe_guide/frontend_faq.md b/doc/development/fe_guide/frontend_faq.md
index e4225f2bc39..0d2aeffeac0 100644
--- a/doc/development/fe_guide/frontend_faq.md
+++ b/doc/development/fe_guide/frontend_faq.md
@@ -5,12 +5,12 @@
 1. **You talk about Frontend FAQ.**
    Please share links to it whenever applicable, so more eyes catch when content
    gets outdated.
-2. **Keep it short and simple.**
+1. **Keep it short and simple.**
    Whenever an answer needs more than two sentences it does not belong here.
-3. **Provide background when possible.**
+1. **Provide background when possible.**
    Linking to relevant source code, issue / epic, or other documentation helps
    to understand the answer.
-4. **If you see something, do something.**
+1. **If you see something, do something.**
    Please remove or update any content that is outdated as soon as you see it.
 
 ## FAQ
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 9fcd32fddfa..4fc5dfc8c3d 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -47,7 +47,7 @@ new Vue({
 });
 ```
 
-Read more about [Vue Apollo][vue-apollo] in the [Vue Apollo documentation][vue-apollo-docs].
+Read more about [Vue Apollo][vue-apollo] in the [Vue Apollo documentation](https://vue-apollo.netlify.com/guide/).
 
 ### Local state with Apollo
 
@@ -55,7 +55,6 @@ It is possible to manage an application state with Apollo by passing
 in a resolvers object when creating the default client. The default state can be set by writing
 to the cache after setting up the default client.
 
-
 ```javascript
 import Vue from 'vue';
 import VueApollo from 'vue-apollo';
@@ -115,13 +114,11 @@ defaultClient.query(query)
   .then(result => console.log(result));
 ```
 
-Read more about the [Apollo] client in the [Apollo documentation][apollo-client-docs].
+Read more about the [Apollo] client in the [Apollo documentation](https://www.apollographql.com/docs/tutorial/client/).
 
 [Apollo]: https://www.apollographql.com/
 [vue-apollo]: https://github.com/Akryum/vue-apollo/
-[vue-apollo-docs]: https://akryum.github.io/vue-apollo/
 [feature-flags]: ../feature_flags.md
 [default-client]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/lib/graphql.js
-[apollo-client-docs]: https://www.apollographql.com/docs/tutorial/client.html
 [vue-test-utils]: https://vue-test-utils.vuejs.org/
 [apollo-link-state]: https://www.apollographql.com/docs/link/links/state.html
diff --git a/doc/development/fe_guide/icons.md b/doc/development/fe_guide/icons.md
index 533e2001300..4f687d8642e 100644
--- a/doc/development/fe_guide/icons.md
+++ b/doc/development/fe_guide/icons.md
@@ -21,10 +21,10 @@ To use a sprite Icon in HAML or Rails we use a specific helper function :
 sprite_icon(icon_name, size: nil, css_class: '')
 ```
 
--   **icon_name** Use the icon_name that you can find in the SVG Sprite
-    ([Overview is available here][svg-preview]).
--   **size (optional)** Use one of the following sizes : 16, 24, 32, 48, 72 (this will be translated into a `s16` class)
--   **css_class (optional)** If you want to add additional css classes
+- **icon_name** Use the icon_name that you can find in the SVG Sprite
+  ([Overview is available here][svg-preview]).
+- **size (optional)** Use one of the following sizes : 16, 24, 32, 48, 72 (this will be translated into a `s16` class)
+- **css_class (optional)** If you want to add additional css classes
 
 **Example**
 
@@ -65,10 +65,10 @@ export default {
 </template>
 ```
 
--   **name** Name of the Icon in the SVG Sprite  ([Overview is available here][svg-preview]).
--   **size (optional)** Number value for the size which is then mapped to a specific CSS class
-    (Available Sizes: 8, 12, 16, 18, 24, 32, 48, 72 are mapped to `sXX` css classes)
--   **css-classes (optional)** Additional CSS Classes to add to the svg tag.
+- **name** Name of the Icon in the SVG Sprite  ([Overview is available here][svg-preview]).
+- **size (optional)** Number value for the size which is then mapped to a specific CSS class
+  (Available Sizes: 8, 12, 16, 18, 24, 32, 48, 72 are mapped to `sXX` css classes)
+- **css-classes (optional)** Additional CSS Classes to add to the svg tag.
 
 ### Usage in HTML/JS
 
diff --git a/doc/development/fe_guide/index.md b/doc/development/fe_guide/index.md
index 36d5e4ab96b..deaef8e768b 100644
--- a/doc/development/fe_guide/index.md
+++ b/doc/development/fe_guide/index.md
@@ -17,7 +17,7 @@ Working with our frontend assets requires Node (v8.10.0 or greater) and Yarn
 
 For our currently-supported browsers, see our [requirements][requirements].
 
----
+Use [BrowserStack](https://www.browserstack.com/) to test with our supported browsers. Login to BrowserStack with the credentials saved in GitLab's [shared 1Password account](https://about.gitlab.com/handbook/security/#1password-for-teams).
 
 ## Initiatives
 
@@ -77,8 +77,6 @@ How we use Snowplow to track custom events.
 
 Read the [frontend's FAQ](frontend_faq.md) for common small pieces of helpful information.
 
----
-
 ## Style Guides
 
 ### [JavaScript Style Guide](style_guide_js.md)
@@ -91,20 +89,14 @@ changes.
 
 Our SCSS conventions which are enforced through [scss-lint][scss-lint].
 
----
-
 ## [Performance](performance.md)
 
 Best practices for monitoring and maximizing frontend performance.
 
----
-
 ## [Security](security.md)
 
 Frontend security practices.
 
----
-
 ## [Accessibility](accessibility.md)
 
 Our accessibility standards and resources.
diff --git a/doc/development/fe_guide/performance.md b/doc/development/fe_guide/performance.md
index 2628e95dbc1..676bce32998 100644
--- a/doc/development/fe_guide/performance.md
+++ b/doc/development/fe_guide/performance.md
@@ -30,8 +30,8 @@ To improve the time to first render we are using lazy loading for images. This w
 the actual image source on the `data-src` attribute. After the HTML is rendered and JavaScript is loaded,
 the value of `data-src` will be moved to `src` automatically if the image is in the current viewport.
 
--  Prepare images in HTML for lazy loading by renaming the `src` attribute to `data-src` AND adding the class `lazy`.
--  If you are using the Rails `image_tag` helper, all images will be lazy-loaded by default unless `lazy: false` is provided.
+- Prepare images in HTML for lazy loading by renaming the `src` attribute to `data-src` AND adding the class `lazy`.
+- If you are using the Rails `image_tag` helper, all images will be lazy-loaded by default unless `lazy: false` is provided.
 
 If you are asynchronously adding content which contains lazy images then you need to call the function
 `gl.lazyLoader.searchLazyImages()` which will search for lazy images and load them if needed.
@@ -96,26 +96,26 @@ bundle and included on the page.
   DOM has loaded, you should attach an event handler to the `DOMContentLoaded`
   event with:
 
-    ```javascript
-    import initMyWidget from './my_widget';
+  ```javascript
+  import initMyWidget from './my_widget';
 
-    document.addEventListener('DOMContentLoaded', () => {
-      initMyWidget();
-    });
-    ```
+  document.addEventListener('DOMContentLoaded', () => {
+    initMyWidget();
+  });
+  ```
 
 - **Supporting Module Placement:**
-    - If a class or a module is _specific to a particular route_, try to locate
-      it close to the entry point it will be used. For instance, if
-      `my_widget.js` is only imported within `pages/widget/show/index.js`, you
-      should place the module at `pages/widget/show/my_widget.js` and import it
-      with a relative path (e.g. `import initMyWidget from './my_widget';`).
-    - If a class or module is _used by multiple routes_, place it within a
-      shared directory at the closest common parent directory for the entry
-      points that import it.  For example, if `my_widget.js` is imported within
-      both `pages/widget/show/index.js` and `pages/widget/run/index.js`, then
-      place the module at `pages/widget/shared/my_widget.js` and import it with
-      a relative path if possible (e.g. `../shared/my_widget`).
+  - If a class or a module is _specific to a particular route_, try to locate
+    it close to the entry point it will be used. For instance, if
+    `my_widget.js` is only imported within `pages/widget/show/index.js`, you
+    should place the module at `pages/widget/show/my_widget.js` and import it
+    with a relative path (e.g. `import initMyWidget from './my_widget';`).
+  - If a class or module is _used by multiple routes_, place it within a
+    shared directory at the closest common parent directory for the entry
+    points that import it.  For example, if `my_widget.js` is imported within
+    both `pages/widget/show/index.js` and `pages/widget/run/index.js`, then
+    place the module at `pages/widget/shared/my_widget.js` and import it with
+    a relative path if possible (e.g. `../shared/my_widget`).
 
 - **Enterprise Edition Caveats:**
   For GitLab Enterprise Edition, page-specific entry points will override their
@@ -161,7 +161,7 @@ General tips:
 - Use code-splitting dynamic imports wherever possible to lazy-load code that is not needed initially.
 - [High Performance Animations][high-perf-animations]
 
--------
+---
 
 ## Additional Resources
 
diff --git a/doc/development/fe_guide/security.md b/doc/development/fe_guide/security.md
index 83bb449e54d..47ac87fc895 100644
--- a/doc/development/fe_guide/security.md
+++ b/doc/development/fe_guide/security.md
@@ -1,5 +1,6 @@
 # Security
-### Resources
+
+## Resources
 
 [Mozilla’s HTTP Observatory CLI][observatory-cli] and the
 [Qualys SSL Labs Server Test][qualys-ssl] are good resources for finding
@@ -56,7 +57,7 @@ Some resources on implementing Subresource Integrity:
 
 -->
 
-### Including external resources
+## Including external resources
 
 External fonts, CSS, and JavaScript should never be used with the exception of
 Google Analytics and Piwik - and only when the instance has enabled it. Assets
@@ -64,7 +65,7 @@ should always be hosted and served locally from the GitLab instance. Embedded
 resources via `iframes` should never be used except in certain circumstances
 such as with ReCaptcha, which cannot be used without an `iframe`.
 
-### Avoiding inline scripts and styles
+## Avoiding inline scripts and styles
 
 In order to protect users from [XSS vulnerabilities][xss], we will disable
 inline scripts in the future using Content Security Policy.
diff --git a/doc/development/fe_guide/style_guide_js.md b/doc/development/fe_guide/style_guide_js.md
index b50159c2b75..125b11afcd0 100644
--- a/doc/development/fe_guide/style_guide_js.md
+++ b/doc/development/fe_guide/style_guide_js.md
@@ -20,148 +20,148 @@ See [our current .eslintrc](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/
 
 1. **Never Ever EVER** disable eslint globally for a file
 
-    ```javascript
-      // bad
-      /* eslint-disable */
+   ```javascript
+   // bad
+   /* eslint-disable */
 
-      // better
-      /* eslint-disable some-rule, some-other-rule */
+   // better
+   /* eslint-disable some-rule, some-other-rule */
 
-      // best
-      // nothing :)
-    ```
+   // best
+   // nothing :)
+   ```
 
 1. If you do need to disable a rule for a single violation, try to do it as locally as possible
 
-    ```javascript
-      // bad
-      /* eslint-disable no-new */
+   ```javascript
+   // bad
+   /* eslint-disable no-new */
 
-      import Foo from 'foo';
+   import Foo from 'foo';
 
-      new Foo();
+   new Foo();
 
-      // better
-      import Foo from 'foo';
+   // better
+   import Foo from 'foo';
 
-      // eslint-disable-next-line no-new
-      new Foo();
-    ```
+   // eslint-disable-next-line no-new
+   new Foo();
+   ```
 
 1. There are few rules that we need to disable due to technical debt. Which are:
-   1. [no-new][eslint-new]
-   1. [class-methods-use-this][eslint-this]
+   1. [no-new](https://eslint.org/docs/rules/no-new)
+   1. [class-methods-use-this](https://eslint.org/docs/rules/class-methods-use-this)
 
 1. When they are needed _always_ place ESlint directive comment blocks on the first line of a script,
    followed by any global declarations, then a blank newline prior to any imports or code.
 
-    ```javascript
-      // bad
-      /* global Foo */
-      /* eslint-disable no-new */
-      import Bar from './bar';
+   ```javascript
+   // bad
+   /* global Foo */
+   /* eslint-disable no-new */
+   import Bar from './bar';
 
-      // good
-      /* eslint-disable no-new */
-      /* global Foo */
+   // good
+   /* eslint-disable no-new */
+   /* global Foo */
 
-      import Bar from './bar';
-    ```
+   import Bar from './bar';
+   ```
 
 1. **Never** disable the `no-undef` rule. Declare globals with `/* global Foo */` instead.
 
 1. When declaring multiple globals, always use one `/* global [name] */` line per variable.
 
-    ```javascript
-      // bad
-      /* globals Flash, Cookies, jQuery */
+   ```javascript
+   // bad
+   /* globals Flash, Cookies, jQuery */
 
-      // good
-      /* global Flash */
-      /* global Cookies */
-      /* global jQuery */
-    ```
+   // good
+   /* global Flash */
+   /* global Cookies */
+   /* global jQuery */
+   ```
 
 1. Use up to 3 parameters for a function or class. If you need more accept an Object instead.
 
-    ```javascript
-      // bad
-      fn(p1, p2, p3, p4) {}
+   ```javascript
+   // bad
+   fn(p1, p2, p3, p4) {}
 
-      // good
-      fn(options) {}
-    ```
+   // good
+   fn(options) {}
+   ```
 
 #### Modules, Imports, and Exports
 
 1. Use ES module syntax to import modules
 
-    ```javascript
-      // bad
-      const SomeClass = require('some_class');
+   ```javascript
+   // bad
+   const SomeClass = require('some_class');
 
-      // good
-      import SomeClass from 'some_class';
+   // good
+   import SomeClass from 'some_class';
 
-      // bad
-      module.exports = SomeClass;
+   // bad
+   module.exports = SomeClass;
 
-      // good
-      export default SomeClass;
-    ```
+   // good
+   export default SomeClass;
+   ```
 
-    Import statements are following usual naming guidelines, for example object literals use camel case:
+   Import statements are following usual naming guidelines, for example object literals use camel case:
 
-    ```javascript
-      // some_object file
-      export default {
-        key: 'value',
-      };
+   ```javascript
+   // some_object file
+   export default {
+     key: 'value',
+   };
 
-      // bad
-      import ObjectLiteral from 'some_object';
+   // bad
+   import ObjectLiteral from 'some_object';
 
-      // good
-      import objectLiteral from 'some_object';
-    ```
+   // good
+   import objectLiteral from 'some_object';
+   ```
 
 1. Relative paths: when importing a module in the same directory, a child
    directory, or an immediate parent directory prefer relative paths.  When
    importing a module which is two or more levels up, prefer either `~/` or `ee/`.
 
-    In **app/assets/javascripts/my-feature/subdir**:
+   In **app/assets/javascripts/my-feature/subdir**:
 
-    ```javascript
-    // bad
-    import Foo from '~/my-feature/foo';
-    import Bar from '~/my-feature/subdir/bar';
-    import Bin from '~/my-feature/subdir/lib/bin';
+   ```javascript
+   // bad
+   import Foo from '~/my-feature/foo';
+   import Bar from '~/my-feature/subdir/bar';
+   import Bin from '~/my-feature/subdir/lib/bin';
 
-    // good
-    import Foo from '../foo';
-    import Bar from './bar';
-    import Bin from './lib/bin';
-    ```
+   // good
+   import Foo from '../foo';
+   import Bar from './bar';
+   import Bin from './lib/bin';
+   ```
 
-    In **spec/javascripts**:
+   In **spec/javascripts**:
 
-    ```javascript
-    // bad
-    import Foo from '../../app/assets/javascripts/my-feature/foo';
+   ```javascript
+   // bad
+   import Foo from '../../app/assets/javascripts/my-feature/foo';
 
-    // good
-    import Foo from '~/my-feature/foo';
-    ```
+   // good
+   import Foo from '~/my-feature/foo';
+   ```
 
-    When referencing an **EE component**:
+   When referencing an **EE component**:
 
-    ```javascript
-    // bad
-    import Foo from '../../../../../ee/app/assets/javascripts/my-feature/ee-foo';
+   ```javascript
+   // bad
+   import Foo from '../../../../../ee/app/assets/javascripts/my-feature/ee-foo';
 
-    // good
-    import Foo from 'ee/my-feature/foo';
-    ```
+   // good
+   import Foo from 'ee/my-feature/foo';
+   ```
 
 1. Avoid using IIFE. Although we have a lot of examples of files which wrap their
    contents in IIFEs (immediately-invoked function expressions),
@@ -170,136 +170,136 @@ See [our current .eslintrc](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/
 
 1. Avoid adding to the global namespace.
 
-    ```javascript
-      // bad
-      window.MyClass = class { /* ... */ };
+   ```javascript
+   // bad
+   window.MyClass = class { /* ... */ };
 
-      // good
-      export default class MyClass { /* ... */ }
-    ```
+   // good
+   export default class MyClass { /* ... */ }
+   ```
 
 1. Side effects are forbidden in any script which contains export
 
-    ```javascript
-      // bad
-      export default class MyClass { /* ... */ }
+   ```javascript
+   // bad
+   export default class MyClass { /* ... */ }
 
-      document.addEventListener("DOMContentLoaded", function(event) {
-        new MyClass();
-      }
-    ```
+   document.addEventListener("DOMContentLoaded", function(event) {
+     new MyClass();
+   }
+   ```
 
 #### Data Mutation and Pure functions
 
 1. Strive to write many small pure functions, and minimize where mutations occur.
 
-    ```javascript
-    // bad
-    const values = {foo: 1};
+   ```javascript
+   // bad
+   const values = {foo: 1};
 
-    function impureFunction(items) {
-      const bar = 1;
+   function impureFunction(items) {
+     const bar = 1;
 
-      items.foo = items.a * bar + 2;
+     items.foo = items.a * bar + 2;
 
-      return items.a;
-    }
+     return items.a;
+   }
 
-    const c = impureFunction(values);
+   const c = impureFunction(values);
 
-    // good
-    var values = {foo: 1};
+   // good
+   var values = {foo: 1};
 
-    function pureFunction (foo) {
-      var bar = 1;
+   function pureFunction (foo) {
+     var bar = 1;
 
-      foo = foo * bar + 2;
+     foo = foo * bar + 2;
 
-      return foo;
-    }
+     return foo;
+   }
 
-    var c = pureFunction(values.foo);
+   var c = pureFunction(values.foo);
     ```
 
 1. Avoid constructors with side-effects.
    Although we aim for code without side-effects we need some side-effects for our code to run.
 
-    If the class won't do anything if we only instantiate it, it's ok to add side effects into the constructor (_Note:_ The following is just an example. If the only purpose of the class is to add an event listener and handle the callback a function will be more suitable.)
-
-    ```javascript
-    // Bad
-    export class Foo {
-      constructor() {
-        this.init();
-      }
-      init() {
-        document.addEventListener('click', this.handleCallback)
-      },
-      handleCallback() {
-
-      }
-    }
-
-    // Good
-    export class Foo {
-      constructor() {
-        document.addEventListener()
-      }
-      handleCallback() {
-      }
-    }
-    ```
-
-    On the other hand, if a class only needs to extend a third party/add event listeners in some specific cases, they should be initialized outside of the constructor.
+   If the class won't do anything if we only instantiate it, it's ok to add side effects into the constructor (_Note:_ The following is just an example. If the only purpose of the class is to add an event listener and handle the callback a function will be more suitable.)
+
+   ```javascript
+   // Bad
+   export class Foo {
+     constructor() {
+       this.init();
+     }
+     init() {
+       document.addEventListener('click', this.handleCallback)
+     },
+     handleCallback() {
+
+     }
+   }
+
+   // Good
+   export class Foo {
+     constructor() {
+       document.addEventListener()
+     }
+     handleCallback() {
+     }
+   }
+   ```
+
+   On the other hand, if a class only needs to extend a third party/add event listeners in some specific cases, they should be initialized outside of the constructor.
 
 1. Prefer `.map`, `.reduce` or `.filter` over `.forEach`
    A forEach will most likely cause side effects, it will be mutating the array being iterated. Prefer using `.map`,
    `.reduce` or `.filter`
 
-    ```javascript
-      const users = [ { name: 'Foo' }, { name: 'Bar' } ];
+   ```javascript
+   const users = [ { name: 'Foo' }, { name: 'Bar' } ];
 
-      // bad
-      users.forEach((user, index) => {
-        user.id = index;
-      });
+   // bad
+   users.forEach((user, index) => {
+     user.id = index;
+   });
 
-      // good
-      const usersWithId = users.map((user, index) => {
-        return Object.assign({}, user, { id: index });
-      });
-    ```
+   // good
+   const usersWithId = users.map((user, index) => {
+     return Object.assign({}, user, { id: index });
+   });
+   ```
 
 #### Parse Strings into Numbers
 
 1. `parseInt()` is preferable over `Number()` or `+`
 
-    ```javascript
-      // bad
-      +'10' // 10
+   ```javascript
+   // bad
+   +'10' // 10
 
-      // good
-      Number('10') // 10
+   // good
+   Number('10') // 10
 
-      // better
-      parseInt('10', 10);
-    ```
+   // better
+   parseInt('10', 10);
+   ```
 
 #### CSS classes used for JavaScript
 
 1. If the class is being used in Javascript it needs to be prepend with `js-`
 
-    ```html
-      // bad
-      <button class="add-user">
-        Add User
-      </button>
+   ```html
+   // bad
+   <button class="add-user">
+     Add User
+   </button>
 
-      // good
-      <button class="js-add-user">
-        Add User
-      </button>
-    ```
+   // good
+   <button class="js-add-user">
+     Add User
+   </button>
+   ```
 
 ### Vue.js
 
@@ -314,43 +314,44 @@ Please check this [rules][eslint-plugin-vue-rules] for more documentation.
 1. The store has it's own file
 1. Use a function in the bundle file to instantiate the Vue component:
 
-    ```javascript
-      // bad
-      class {
-        init() {
-          new Component({})
-        }
-      }
-
-      // good
-      document.addEventListener('DOMContentLoaded', () => new Vue({
-        el: '#element',
-        components: {
-          componentName
-        },
-        render: createElement => createElement('component-name'),
-      }));
-    ```
+   ```javascript
+   // bad
+   class {
+     init() {
+       new Component({})
+     }
+   }
+
+   // good
+   document.addEventListener('DOMContentLoaded', () => new Vue({
+     el: '#element',
+     components: {
+       componentName
+     },
+     render: createElement => createElement('component-name'),
+   }));
+   ```
 
 1. Do not use a singleton for the service or the store
 
-    ```javascript
-      // bad
-      class Store {
-        constructor() {
-          if (!this.prototype.singleton) {
-            // do something
-          }
-        }
-      }
+   ```javascript
+   // bad
+   class Store {
+     constructor() {
+       if (!this.prototype.singleton) {
+         // do something
+       }
+     }
+   }
+
+   // good
+   class Store {
+     constructor() {
+       // do something
+     }
+   }
+   ```
 
-      // good
-      class Store {
-        constructor() {
-          // do something
-        }
-      }
-    ```
 1. Use `.vue` for Vue templates. Do not use `%template` in HAML.
 
 #### Naming
@@ -358,38 +359,38 @@ Please check this [rules][eslint-plugin-vue-rules] for more documentation.
 1. **Extensions**: Use `.vue` extension for Vue components. Do not use `.js` as file extension ([#34371]).
 1. **Reference Naming**: Use PascalCase for their instances:
 
-    ```javascript
-      // bad
-      import cardBoard from 'cardBoard.vue'
+   ```javascript
+   // bad
+   import cardBoard from 'cardBoard.vue'
 
-      components: {
-        cardBoard,
-      };
+   components: {
+     cardBoard,
+   };
 
-      // good
-      import CardBoard from 'cardBoard.vue'
+   // good
+   import CardBoard from 'cardBoard.vue'
 
-      components: {
-        CardBoard,
-      };
-    ```
+   components: {
+     CardBoard,
+   };
+   ```
 
 1. **Props Naming:**  Avoid using DOM component prop names.
 1. **Props Naming:** Use kebab-case instead of camelCase to provide props in templates.
 
-    ```javascript
-      // bad
-      <component class="btn">
+   ```javascript
+   // bad
+   <component class="btn">
 
-      // good
-      <component css-class="btn">
+   // good
+   <component css-class="btn">
 
-      // bad
-      <component myProp="prop" />
+   // bad
+   <component myProp="prop" />
 
-      // good
-      <component my-prop="prop" />
-    ```
+   // good
+   <component my-prop="prop" />
+   ```
 
 [#34371]: https://gitlab.com/gitlab-org/gitlab-ce/issues/34371
 
@@ -399,205 +400,205 @@ Please check this [rules][eslint-plugin-vue-rules] for more documentation.
 
    1. With more than one attribute, all attributes should be on a new line:
 
-        ```javascript
-          // bad
-          <component v-if="bar"
-              param="baz" />
+      ```javascript
+      // bad
+      <component v-if="bar"
+          param="baz" />
 
-          <button class="btn">Click me</button>
+      <button class="btn">Click me</button>
 
-          // good
-          <component
-            v-if="bar"
-            param="baz"
-          />
+      // good
+      <component
+        v-if="bar"
+        param="baz"
+      />
 
-          <button class="btn">
-            Click me
-          </button>
-        ```
+      <button class="btn">
+        Click me
+      </button>
+      ```
 
    1. The tag can be inline if there is only one attribute:
 
-        ```javascript
-          // good
-            <component bar="bar" />
+      ```javascript
+      // good
+        <component bar="bar" />
 
-          // good
-            <component
-              bar="bar"
-              />
+      // good
+        <component
+          bar="bar"
+          />
 
-          // bad
-           <component
-              bar="bar" />
-        ```
+      // bad
+       <component
+          bar="bar" />
+      ```
 
 #### Quotes
 
 1. Always use double quotes `"` inside templates and single quotes `'` for all other JS.
 
-    ```javascript
-      // bad
-      template: `
-        <button :class='style'>Button</button>
-      `
+   ```javascript
+   // bad
+   template: `
+     <button :class='style'>Button</button>
+   `
 
-      // good
-      template: `
-        <button :class="style">Button</button>
-      `
-    ```
+   // good
+   template: `
+     <button :class="style">Button</button>
+   `
+   ```
 
 #### Props
 
 1. Props should be declared as an object
 
-    ```javascript
-      // bad
-      props: ['foo']
+   ```javascript
+   // bad
+   props: ['foo']
 
-      // good
-      props: {
-        foo: {
-          type: String,
-          required: false,
-          default: 'bar'
-        }
-      }
-    ```
+   // good
+   props: {
+     foo: {
+       type: String,
+       required: false,
+       default: 'bar'
+     }
+   }
+   ```
 
 1. Required key should always be provided when declaring a prop
 
-    ```javascript
-      // bad
-      props: {
-        foo: {
-          type: String,
-        }
-      }
-
-      // good
-      props: {
-        foo: {
-          type: String,
-          required: false,
-          default: 'bar'
-        }
-      }
-    ```
+   ```javascript
+   // bad
+   props: {
+     foo: {
+       type: String,
+     }
+   }
+
+   // good
+   props: {
+     foo: {
+       type: String,
+       required: false,
+       default: 'bar'
+     }
+   }
+   ```
 
 1. Default key should be provided if the prop is not required.
    _Note:_ There are some scenarios where we need to check for the existence of the property.
    On those a default key should not be provided.
 
-    ```javascript
-      // good
-      props: {
-        foo: {
-          type: String,
-          required: false,
-        }
-      }
-
-      // good
-      props: {
-        foo: {
-          type: String,
-          required: false,
-          default: 'bar'
-        }
-      }
-
-      // good
-      props: {
-        foo: {
-          type: String,
-          required: true
-        }
-      }
-    ```
+   ```javascript
+   // good
+   props: {
+     foo: {
+       type: String,
+       required: false,
+     }
+   }
+
+   // good
+   props: {
+     foo: {
+       type: String,
+       required: false,
+       default: 'bar'
+     }
+   }
+
+   // good
+   props: {
+     foo: {
+       type: String,
+       required: true
+     }
+   }
+   ```
 
 #### Data
 
 1. `data` method should always be a function
 
-    ```javascript
-      // bad
-      data: {
-        foo: 'foo'
-      }
+   ```javascript
+   // bad
+   data: {
+     foo: 'foo'
+   }
 
-      // good
-      data() {
-        return {
-          foo: 'foo'
-        };
-      }
-    ```
+   // good
+   data() {
+     return {
+       foo: 'foo'
+     };
+   }
+   ```
 
 #### Directives
 
 1. Shorthand `@` is preferable over `v-on`
 
-    ```javascript
-      // bad
-      <component v-on:click="eventHandler"/>
+   ```javascript
+   // bad
+   <component v-on:click="eventHandler"/>
 
-      // good
-      <component @click="eventHandler"/>
-    ```
+   // good
+   <component @click="eventHandler"/>
+   ```
 
-2. Shorthand `:` is preferable over `v-bind`
+1. Shorthand `:` is preferable over `v-bind`
 
-    ```javascript
-      // bad
-      <component v-bind:class="btn"/>
+   ```javascript
+   // bad
+   <component v-bind:class="btn"/>
 
-      // good
-      <component :class="btn"/>
-    ```
+   // good
+   <component :class="btn"/>
+   ```
 
-3. Shorthand `#` is preferable over `v-slot`
+1. Shorthand `#` is preferable over `v-slot`
 
-    ```javascript
-      // bad
-      <template v-slot:header></template>
+   ```javascript
+   // bad
+   <template v-slot:header></template>
 
-      // good
-      <template #header></template>
-    ```
+   // good
+   <template #header></template>
+   ```
 
 #### Closing tags
 
 1. Prefer self closing component tags
 
-    ```javascript
-      // bad
-      <component></component>
+   ```javascript
+   // bad
+   <component></component>
 
-      // good
-      <component />
-    ```
+   // good
+   <component />
+   ```
 
 #### Ordering
 
 1. Tag order in `.vue` file
 
-    ```
-    <script>
-      // ...
-    </script>
-
-    <template>
-      // ...
-    </template>
-
-    // We don't use scoped styles but there are few instances of this
-    <style>
-      // ...
-    </style>
-    ```
+   ```
+   <script>
+     // ...
+   </script>
+
+   <template>
+     // ...
+   </template>
+
+   // We don't use scoped styles but there are few instances of this
+   <style>
+     // ...
+   </style>
+   ```
 
 1. Properties in a Vue Component:
    Check [order of properties in components rule][vue-order].
@@ -608,50 +609,50 @@ When using `v-for` you need to provide a *unique* `:key` attribute for each item
 
 1. If the elements of the array being iterated have an unique `id` it is advised to use it:
 
-    ```html
-      <div
-        v-for="item in items"
-        :key="item.id"
-      >
-        <!-- content -->
-      </div>
-    ```
+   ```html
+   <div
+     v-for="item in items"
+     :key="item.id"
+   >
+     <!-- content -->
+   </div>
+   ```
 
 1. When the elements being iterated don't have a unique id, you can use the array index as the `:key` attribute
 
-    ```html
-      <div
-        v-for="(item, index) in items"
-        :key="index"
-      >
-        <!-- content -->
-      </div>
-    ```
+   ```html
+   <div
+     v-for="(item, index) in items"
+     :key="index"
+   >
+     <!-- content -->
+   </div>
+   ```
 
 1. When using `v-for` with `template` and there is more than one child element, the `:key` values must be unique. It's advised to use `kebab-case` namespaces.
 
-    ```html
-      <template v-for="(item, index) in items">
-        <span :key="`span-${index}`"></span>
-        <button :key="`button-${index}`"></button>
-      </template>
-    ```
+   ```html
+   <template v-for="(item, index) in items">
+     <span :key="`span-${index}`"></span>
+     <button :key="`button-${index}`"></button>
+   </template>
+   ```
 
 1. When dealing with nested `v-for` use the same guidelines as above.
 
-    ```html
-      <div
-        v-for="item in items"
-        :key="item.id"
-      >
-        <span
-          v-for="element in array"
-          :key="element.id"
-        >
-          <!-- content -->
-        </span>
-      </div>
-    ```
+   ```html
+   <div
+     v-for="item in items"
+     :key="item.id"
+   >
+     <span
+       v-for="element in array"
+       :key="element.id"
+     >
+       <!-- content -->
+     </span>
+   </div>
+   ```
 
 Useful links:
 
@@ -662,35 +663,35 @@ Useful links:
 
 1. Tooltips: Do not rely on `has-tooltip` class name for Vue components
 
-    ```javascript
-      // bad
-      <span
-        class="has-tooltip"
-        title="Some tooltip text">
-        Text
-      </span>
-
-      // good
-      <span
-        v-tooltip
-        title="Some tooltip text">
-        Text
-      </span>
-    ```
+   ```javascript
+   // bad
+   <span
+     class="has-tooltip"
+     title="Some tooltip text">
+     Text
+   </span>
+
+   // good
+   <span
+     v-tooltip
+     title="Some tooltip text">
+     Text
+   </span>
+   ```
 
 1. Tooltips: When using a tooltip, include the tooltip directive, `./app/assets/javascripts/vue_shared/directives/tooltip.js`
 
 1. Don't change `data-original-title`.
 
-    ```javascript
-      // bad
-      <span data-original-title="tooltip text">Foo</span>
+   ```javascript
+   // bad
+   <span data-original-title="tooltip text">Foo</span>
 
-      // good
-      <span title="tooltip text">Foo</span>
+   // good
+   <span title="tooltip text">Foo</span>
 
-      $('span').tooltip('_fixTitle');
-    ```
+   $('span').tooltip('_fixTitle');
+   ```
 
 ### The Javascript/Vue Accord
 
@@ -713,8 +714,6 @@ The goal of this accord is to make sure we are all on the same page.
 
 [airbnb-js-style-guide]: https://github.com/airbnb/javascript
 [eslintrc]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.eslintrc
-[eslint-this]: http://eslint.org/docs/rules/class-methods-use-this
-[eslint-new]: http://eslint.org/docs/rules/no-new
 [eslint-plugin-vue]: https://github.com/vuejs/eslint-plugin-vue
 [eslint-plugin-vue-rules]: https://github.com/vuejs/eslint-plugin-vue#bulb-rules
 [vue-order]: https://github.com/vuejs/eslint-plugin-vue/blob/master/docs/rules/order-in-components.md
diff --git a/doc/development/fe_guide/style_guide_scss.md b/doc/development/fe_guide/style_guide_scss.md
index b25dce65ffe..95c4a094c04 100644
--- a/doc/development/fe_guide/style_guide_scss.md
+++ b/doc/development/fe_guide/style_guide_scss.md
@@ -6,6 +6,7 @@ easy to maintain, and performant for the end-user.
 ## Rules
 
 ### Utility Classes
+
 As part of the effort for [cleaning up our CSS and moving our components into GitLab-UI](https://gitlab.com/groups/gitlab-org/-/epics/950)
 led by the [GitLab UI WG](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/20623) we prefer the use of utility classes over adding new CSS. However, complex CSS can be addressed by adding component classes.
 
@@ -31,12 +32,12 @@ New utility classes should be added to [`utilities.scss`](https://gitlab.com/git
 
 #### When should I create component classes?
 
-We recommend a "utility-first" approach. 
+We recommend a "utility-first" approach.
 
 1. Start with utility classes.
-2. If composing utility classes into a component class removes code duplication and encapsulates a clear responsibility, do it.
+1. If composing utility classes into a component class removes code duplication and encapsulates a clear responsibility, do it.
 
-This encourages an organic growth of component classes and prevents the creation of one-off unreusable classes. Also, the kind of classes that emerge from "utility-first" tend to be design-centered (e.g. `.button`, `.alert`, `.card`) rather than domain-centered (e.g. `.security-report-widget`, `.commit-header-icon`). 
+This encourages an organic growth of component classes and prevents the creation of one-off unreusable classes. Also, the kind of classes that emerge from "utility-first" tend to be design-centered (e.g. `.button`, `.alert`, `.card`) rather than domain-centered (e.g. `.security-report-widget`, `.commit-header-icon`).
 
 Examples of component classes that were created using "utility-first" include:
 
@@ -45,8 +46,8 @@ Examples of component classes that were created using "utility-first" include:
 
 Inspiration:
 
-- https://tailwindcss.com/docs/utility-first
-- https://tailwindcss.com/docs/extracting-components 
+- <https://tailwindcss.com/docs/utility-first>
+- <https://tailwindcss.com/docs/extracting-components>
 
 ### Naming
 
@@ -211,6 +212,7 @@ selectors are intended for use only with JavaScript to allow for removal or
 renaming without breaking styling.
 
 ### IDs
+
 Don't use ID selectors in CSS.
 
 ```scss
diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md
index 8c6a73c6824..421b7265613 100644
--- a/doc/development/fe_guide/vue.md
+++ b/doc/development/fe_guide/vue.md
@@ -34,6 +34,7 @@ new_feature
 │  └── new_feature_store.js
 ├── index.js
 ```
+
 _For consistency purposes, we recommend you to follow the same structure._
 
 Let's look into each of them:
@@ -49,7 +50,9 @@ provided as a prop to the main component.
 Be sure to read about [page-specific JavaScript][page_specific_javascript].
 
 ### Bootstrapping Gotchas
+
 #### Providing data from HAML to JavaScript
+
 While mounting a Vue application may be a need to provide data from Rails to JavaScript.
 To do that, provide the data through `data` attributes in the HTML element and query them while mounting the application.
 
@@ -83,7 +86,8 @@ document.addEventListener('DOMContentLoaded', () => new Vue({
 ```
 
 #### Accessing the `gl` object
-When we need to query the `gl` object for data that won't change during the application's life cyle, we should do it in the same place where we query the DOM.
+
+When we need to query the `gl` object for data that won't change during the application's life cycle, we should do it in the same place where we query the DOM.
 By following this practice, we can avoid the need to mock the `gl` object, which will make tests easier.
 It should be done while initializing our Vue instance, and the data should be provided as `props` to the main component:
 
@@ -118,12 +122,13 @@ You can read more about components in Vue.js site, [Component System][component-
 ### A folder for the Store
 
 #### Vuex
+
 Check this [page](vuex.md) for more details.
 
 ### Mixing Vue and jQuery
 
 - Mixing Vue and jQuery is not recommended.
-- If you need to use a specific jQuery plugin in Vue, [create a wrapper around it][https://vuejs.org/v2/examples/select2.html].
+- If you need to use a specific jQuery plugin in Vue, [create a wrapper around it](https://vuejs.org/v2/examples/select2.html).
 - It is acceptable for Vue to listen to existing jQuery events using jQuery event listeners.
 - It is not recommended to add new jQuery events for Vue to interact with jQuery.
 
@@ -212,6 +217,7 @@ describe('Todos App', () => {
 ```
 
 ### `mountComponent` helper
+
 There is a helper in `spec/javascripts/helpers/vue_mount_component_helper.js` that allows you to mount a component with the given props:
 
 ```javascript
@@ -225,10 +231,12 @@ const vm = mountComponent(Component, data);
 ```
 
 ### Test the component's output
+
 The main return value of a Vue component is the rendered output. In order to test the component we
 need to test the rendered output. [Vue][vue-test] guide's to unit test show us exactly that:
 
 ## Vue.js Expert Role
+
 One should apply to be a Vue.js expert by opening an MR when the Merge Request's they create and review show:
 
 - Deep understanding of Vue and Vuex reactivy
diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md
index bf248b7f8af..557d3132d71 100644
--- a/doc/development/fe_guide/vuex.md
+++ b/doc/development/fe_guide/vuex.md
@@ -1,15 +1,18 @@
 # Vuex
+
 To manage the state of an application you should use [Vuex][vuex-docs].
 
 _Note:_ All of the below is explained in more detail in the official [Vuex documentation][vuex-docs].
 
 ## Separation of concerns
+
 Vuex is composed of State, Getters, Mutations, Actions and Modules.
 
 When a user clicks on an action, we need to `dispatch` it. This action will `commit` a mutation that will change the state.
 _Note:_ The action itself will not update the state, only a mutation should update the state.
 
 ## File structure
+
 When using Vuex at GitLab, separate this concerns into different files to improve readability:
 
 ```
@@ -21,10 +24,12 @@ When using Vuex at GitLab, separate this concerns into different files to improv
   ├── state.js          # state
   └── mutation_types.js # mutation types
 ```
+
 The following example shows an application that lists and adds users to the state.
 (For a more complex example implementation take a look at the security applications store in [here](https://gitlab.com/gitlab-org/gitlab-ee/tree/master/ee/app/assets/javascripts/vue_shared/security_reports/store))
 
 ### `index.js`
+
 This is the entry point for our store. You can use the following as a guide:
 
 ```javascript
@@ -47,6 +52,7 @@ export default createStore();
 ```
 
 ### `state.js`
+
 The first thing you should do before writing any code is to design the state.
 
 Often we need to provide data from haml to our Vue application. Let's store it in the state for better access.
@@ -66,9 +72,11 @@ Often we need to provide data from haml to our Vue application. Let's store it i
 ```
 
 #### Access `state` properties
+
 You can use `mapState` to access state properties in the components.
 
 ### `actions.js`
+
 An action is a payload of information to send data from our application to our store.
 
 An action is usually composed by a `type` and a `payload` and they describe what happened.
@@ -110,6 +118,7 @@ In this file, we will write the actions that will call the respective mutations:
 ```
 
 #### Actions Pattern: `request` and `receive` namespaces
+
 When a request is made we often want to show a loading state to the user.
 
 Instead of creating an action to toggle the loading state and dispatch it in the component,
@@ -136,6 +145,7 @@ By following this pattern we guarantee:
 1. Actions are simple and straightforward
 
 #### Dispatching actions
+
 To dispatch an action from a component, use the `mapActions` helper:
 
 ```javascript
@@ -154,6 +164,7 @@ import { mapActions } from 'vuex';
 ```
 
 ### `mutations.js`
+
 The mutations specify how the application state changes in response to actions sent to the store.
 The only way to change state in a Vuex store should be by committing a mutation.
 
@@ -193,6 +204,7 @@ Remember that actions only describe that something happened, they don't describe
 ```
 
 ### `getters.js`
+
 Sometimes we may need to get derived state based on store state, like filtering for a specific prop.
 Using a getter will also cache the result based on dependencies due to [how computed props work](https://vuejs.org/v2/guide/computed.html#Computed-Caching-vs-Methods)
 This can be done through the `getters`:
@@ -219,6 +231,7 @@ import { mapGetters } from 'vuex';
 ```
 
 ### `mutation_types.js`
+
 From [vuex mutations docs][vuex-mutations]:
 > It is a commonly seen pattern to use constants for mutation types in various Flux implementations. This allows the code to take advantage of tooling like linters, and putting all constants in a single file allows your collaborators to get an at-a-glance view of what mutations are possible in the entire application.
 
@@ -227,6 +240,7 @@ export const ADD_USER = 'ADD_USER';
 ```
 
 ### How to include the store in your application
+
 The store should be included in the main component of your application:
 
 ```javascript
@@ -241,6 +255,7 @@ The store should be included in the main component of your application:
 ```
 
 ### Communicating with the Store
+
 ```javascript
 <script>
 import { mapActions, mapState, mapGetters } from 'vuex';
@@ -298,29 +313,33 @@ export default {
 
 1. Do not call a mutation directly. Always use an action to commit a mutation. Doing so will keep consistency throughout the application. From Vuex docs:
 
-    >  why don't we just call store.commit('action') directly? Well, remember that mutations must be synchronous? Actions aren't. We can perform asynchronous operations inside an action.
+   > Why don't we just call store.commit('action') directly? Well, remember that mutations must be synchronous? Actions aren't. We can perform asynchronous operations inside an action.
 
-    ```javascript
-      // component.vue
+   ```javascript
+     // component.vue
 
-      // bad
-      created() {
-        this.$store.commit('mutation');
-      }
+     // bad
+     created() {
+       this.$store.commit('mutation');
+     }
+
+     // good
+     created() {
+       this.$store.dispatch('action');
+     }
+   ```
 
-      // good
-      created() {
-        this.$store.dispatch('action');
-      }
-    ```
 1. Use mutation types instead of hardcoding strings. It will be less error prone.
 1. The State will be accessible in all components descending from the use where the store is instantiated.
 
 ### Testing Vuex
+
 #### Testing Vuex concerns
+
 Refer to [vuex docs][vuex-testing] regarding testing Actions, Getters and Mutations.
 
 #### Testing components that need a store
+
 Smaller components might use `store` properties to access the data.
 In order to write unit tests for those components, we need to include the store and provide the correct state:
 
@@ -363,6 +382,7 @@ describe('component', () => {
 ```
 
 #### Testing Vuex actions and getters
+
 Because we're currently using [`babel-plugin-rewire`](https://github.com/speedskater/babel-plugin-rewire), you may encounter the following error when testing your Vuex actions and getters:
 `[vuex] actions should be function or object with "handler" function`