Add latest changes from gitlab-org/gitlab@15-3-stable-eev15.3.0-rc42

22 files changed, 603 insertions, 54 deletions

diff --git a/doc/development/fe_guide/accessibility.md b/doc/development/fe_guide/accessibility.md
index 2a1083d031f..bdd6c5d6e84 100644
--- a/doc/development/fe_guide/accessibility.md
+++ b/doc/development/fe_guide/accessibility.md
@@ -13,7 +13,7 @@ This page contains guidelines we should follow.
 
 ## Quick summary
 
-Since [no ARIA is better than bad ARIA](https://www.w3.org/TR/wai-aria-practices/#no_aria_better_bad_aria),
+Since [no ARIA is better than bad ARIA](https://w3c.github.io/aria-practices/#no_aria_better_bad_aria),
 review the following recommendations before using `aria-*`, `role`, and `tabindex`.
 Use semantic HTML, which has accessibility semantics baked in, and ideally test with
 [relevant combinations of screen readers and browsers](https://www.accessibility-developer-guide.com/knowledge/screen-readers/relevant-combinations/).
diff --git a/doc/development/fe_guide/architecture.md b/doc/development/fe_guide/architecture.md
index afaf6df8f8a..1d08296eafc 100644
--- a/doc/development/fe_guide/architecture.md
+++ b/doc/development/fe_guide/architecture.md
@@ -11,7 +11,7 @@ When developing a feature that requires architectural design, or changing the fu
 A Frontend Architect is an expert who makes high-level Frontend design decisions
 and decides on technical standards, including coding standards and frameworks.
 
-Architectural decisions should be accessible to everyone, so please document
+Architectural decisions should be accessible to everyone, so document
 them in the relevant Merge Request discussion or by updating our documentation
 when appropriate.
 
@@ -19,7 +19,7 @@ You can find the Frontend Architecture experts on the [team page](https://about.
 
 ## Widget Architecture
 
-The [Plan stage](https://about.gitlab.com/handbook/engineering/development/dev/fe-plan/)
+The [Plan stage](https://about.gitlab.com/handbook/engineering/development/dev/plan-project-management/)
 is refactoring the right sidebar to consist of **widgets**. They have a specific architecture to be
 reusable and to expose an interface that can be used by external Vue applications on the page.
 Learn more about the [widget architecture](widgets.md).
diff --git a/doc/development/fe_guide/content_editor.md b/doc/development/fe_guide/content_editor.md
index d4c29cb8a24..f262e48b6da 100644
--- a/doc/development/fe_guide/content_editor.md
+++ b/doc/development/fe_guide/content_editor.md
@@ -296,6 +296,7 @@ const builtInContentEditorExtensions = [
   Dropcursor,
   Emoji,
   // Other extensions
+]
 ```
 
 ### The Markdown serializer
diff --git a/doc/development/fe_guide/design_anti_patterns.md b/doc/development/fe_guide/design_anti_patterns.md
index b7238bb2813..580f488bd33 100644
--- a/doc/development/fe_guide/design_anti_patterns.md
+++ b/doc/development/fe_guide/design_anti_patterns.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 Anti-patterns may seem like good approaches at first, but it has been shown that they bring more ills than benefits. These should
 generally be avoided.
 
-Throughout the GitLab codebase, there may be historic uses of these anti-patterns. Please [use discretion](https://about.gitlab.com/handbook/engineering/development/principles/#balance-refactoring-and-velocity)
+Throughout the GitLab codebase, there may be historic uses of these anti-patterns. [Use discretion](https://about.gitlab.com/handbook/engineering/development/principles/#balance-refactoring-and-velocity)
 when figuring out whether or not to refactor, when touching code that uses one of these legacy patterns.
 
 NOTE:
@@ -62,7 +62,7 @@ could be appropriate:
 - When a responsibility is truly global and should be referenced across the application
   (for example, an application-wide Event Bus).
 
-Even in these scenarios, please consider avoiding the Shared Global Object pattern because the
+Even in these scenarios, consider avoiding the Shared Global Object pattern because the
 side-effects can be notoriously difficult to reason with.
 
 ### References
@@ -140,7 +140,7 @@ that a Singleton could be appropriate in the following rare cases:
 - We need to manage some resource that **MUST** have just 1 instance (that is, some hardware restriction).
 - There is a real [cross-cutting concern](https://en.wikipedia.org/wiki/Cross-cutting_concern) (for example, logging) and a Singleton provides the simplest API.
 
-Even in these scenarios, please consider avoiding the Singleton pattern.
+Even in these scenarios, consider avoiding the Singleton pattern.
 
 ### What alternatives are there to the Singleton pattern?
 
diff --git a/doc/development/fe_guide/development_process.md b/doc/development/fe_guide/development_process.md
index b4893fd4ef9..3273263de3b 100644
--- a/doc/development/fe_guide/development_process.md
+++ b/doc/development/fe_guide/development_process.md
@@ -16,7 +16,7 @@ Copy the content over to your issue or merge request and if something doesn't ap
 
 This checklist is intended to help us during development of bigger features/refactorings. It is not a "use it always and every point always matches" list.
 
-Please use your best judgment when to use it and please contribute new points through merge requests if something comes to your mind.
+Use your best judgment when to use it and contribute new points through merge requests if something comes to your mind.
 
 ```markdown
 ### Frontend development
@@ -39,7 +39,7 @@ Please use your best judgment when to use it and please contribute new points th
   - [ ] **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)
+- [ ] **Security** Are there any new security relevant implementations? Then 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)
 
 #### During development
 
@@ -90,7 +90,7 @@ code that is unused:
 
 ### Merge Request Review
 
-With the purpose of being [respectful of others' time](https://about.gitlab.com/handbook/values/#be-respectful-of-others-time) please follow these guidelines when asking for a review:
+With the purpose of being [respectful of others' time](https://about.gitlab.com/handbook/values/#be-respectful-of-others-time), follow these guidelines when asking for a review:
 
 - Make sure your Merge Request:
   - milestone is set
@@ -101,7 +101,7 @@ With the purpose of being [respectful of others' time](https://about.gitlab.com/
   - includes tests
   - includes a changelog entry (when necessary)
 - Before assigning to a maintainer, assign to a reviewer.
-- If you assigned a merge request or pinged someone directly, be patient because we work in different timezones and asynchronously. Unless the merge request is urgent (like fixing a broken default branch), please don't DM or reassign the merge request before waiting for a 24-hour window.
+- If you assigned a merge request or pinged someone directly, be patient because we work in different timezones and asynchronously. Unless the merge request is urgent (like fixing a broken default branch), don't DM or reassign the merge request before waiting for a 24-hour window.
 - If you have a question regarding your merge request/issue, make it on the merge request/issue. When we DM each other, we no longer have a SSOT and [no one else is able to contribute](https://about.gitlab.com/handbook/values/#public-by-default).
 - When you have a big **Draft** merge request with many changes, you're advised to get the review started before adding/removing significant code. Make sure it is assigned well before the release cut-off, as the reviewers/maintainers would always prioritize reviewing finished MRs before the **Draft** ones.
 - Make sure to remove the `Draft:` title before the last round of review.
diff --git a/doc/development/fe_guide/frontend_faq.md b/doc/development/fe_guide/frontend_faq.md
index 39c39894dac..6a645416c0a 100644
--- a/doc/development/fe_guide/frontend_faq.md
+++ b/doc/development/fe_guide/frontend_faq.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 ## Rules of Frontend FAQ
 
 1. **You talk about Frontend FAQ.**
-   Please share links to it whenever applicable, so more eyes catch when content
+   Share links to it whenever applicable, so more eyes catch when content
    gets outdated.
 1. **Keep it short and simple.**
    Whenever an answer needs more than two sentences it does not belong here.
@@ -17,7 +17,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
    Linking to relevant source code, issue / epic, or other documentation helps
    to understand the answer.
 1. **If you see something, do something.**
-   Please remove or update any content that is outdated as soon as you see it.
+   Remove or update any content that is outdated as soon as you see it.
 
 ## FAQ
 
@@ -101,7 +101,7 @@ axios.get(joinPaths(gon.gitlab_url, '-', 'foo'))
 axios.get(joinPaths(gon.relative_url_root, '-', 'foo'))
 ```
 
-Also, please try not to hardcode paths in the Frontend, but instead receive them from the Backend (see next section).
+Also, try not to hardcode paths in the Frontend, but instead receive them from the Backend (see next section).
 When referencing Backend rails paths, avoid using `*_url`, and use `*_path` instead.
 
 Example:
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 10db332d64c..442dda20d23 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -14,7 +14,7 @@ info: "See the Technical Writers assigned to Development Guidelines: https://abo
 **General resources**:
 
 - [📚 Official Introduction to GraphQL](https://graphql.org/learn/)
-- [📚 Official Introduction to Apollo](https://www.apollographql.com/docs/tutorial/introduction/)
+- [📚 Official Introduction to Apollo](https://www.apollographql.com/tutorials/fullstack-quickstart/introduction)
 
 **GraphQL at GitLab**:
 
@@ -109,7 +109,7 @@ Default client accepts two parameters: `resolvers` and `config`.
 
 If you are making multiple queries to the same Apollo client object you might encounter the following error: `Cache data may be lost when replacing the someProperty field of a Query object. To address this problem, either ensure all objects of SomeEntityhave an id or a custom merge function`. We are already checking `ID` presence for every GraphQL type that has an `ID`, so this shouldn't be the case. Most likely, the `SomeEntity` type doesn't have an `ID` property, and to fix this warning we need to define a custom merge function.
 
-We have some client-wide types with `merge: true` defined in the default client as [typePolicies](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/lib/graphql.js) (this means that Apollo will merge existing and incoming responses in the case of subsequent queries). Please consider adding `SomeEntity` there or defining a custom merge function for it.
+We have some client-wide types with `merge: true` defined in the default client as [typePolicies](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/lib/graphql.js) (this means that Apollo will merge existing and incoming responses in the case of subsequent queries). Consider adding `SomeEntity` there or defining a custom merge function for it.
 
 ## GraphQL Queries
 
@@ -212,7 +212,7 @@ with a **new and updated** object.
 
 To facilitate the process of updating the cache and returning the new object we
 use the library [Immer](https://immerjs.github.io/immer/).
-Please, follow these conventions:
+Follow these conventions:
 
 - The updated cache is named `data`.
 - The original cache data is named `sourceData`.
@@ -597,7 +597,7 @@ export default {
 Note that, even if the directive evaluates to `false`, the guarded entity is sent to the backend and
 matched against the GraphQL schema. So this approach requires that the feature-flagged entity
 exists in the schema, even if the feature flag is disabled. When the feature flag is turned off, it
-is recommended that the resolver returns `null` at the very least using the same feature flag as the frontend. See the [API GraphQL guide](../api_graphql_styleguide.md#frontend-and-backend-feature-flag-strategies).
+is recommended that the resolver returns `null` at the very least using the same feature flag as the frontend. See the [API GraphQL guide](../api_graphql_styleguide.md#feature-flags).
 
 ##### Different versions of a query
 
@@ -729,8 +729,9 @@ In this case, we can either:
 - Skip passing a cursor.
 - Pass `null` explicitly to `after`.
 
-After data is fetched, we can use the `update`-hook as an opportunity [to customize
-the data that is set in the Vue component property](https://apollo.vuejs.org/api/smart-query.html#options). This allows us to get a hold of the `pageInfo` object among other data.
+After data is fetched, we can use the `update`-hook as an opportunity 
+[to customize the data that is set in the Vue component property](https://apollo.vuejs.org/api/smart-query.html#options). 
+This allows us to get a hold of the `pageInfo` object among other data.
 
 In the `result`-hook, we can inspect the `pageInfo` object to see if we need to fetch
 the next page. Note that we also keep a `requestCount` to ensure that the application
@@ -895,6 +896,51 @@ export default new VueApollo({
 This is similar to the `DesignCollection` example above as new page results are appended to the
 previous ones.
 
+For some cases, it's hard to define the correct `keyArgs` for the field because all
+the fields are updated. In this case, we can set `keyArgs` to `false`. This instructs
+Apollo Client to not perform any automatic merge, and fully rely on the logic we
+put into the `merge` function.
+
+For example, we have a query like this:
+
+```javascript
+query searchGroupsWhereUserCanTransfer {
+  currentUser {
+    id
+    groups {
+      nodes {
+        id
+        fullName
+      }
+      pageInfo {
+        ...PageInfo
+      }
+    }
+  }
+}
+```
+
+Here, the `groups` field doesn't have a good candidate for `keyArgs`: both
+`nodes` and `pageInfo` will be updated when we're fetching a second page.
+Setting `keyArgs` to `false` makes the update work as intended:
+
+```javascript
+typePolicies: {
+  UserCore: {
+    fields: {
+      groups: {
+        keyArgs: false,
+      },
+    },
+  },
+  GroupConnection: {
+    fields: {
+      nodes: concatPagination(),
+    },
+  },
+}
+```
+
 #### Using a recursive query in components
 
 When it is necessary to fetch all paginated data initially an Apollo query can do the trick for us.
@@ -1444,7 +1490,7 @@ describe('Some component', () => {
 When mocking resolved values, ensure the structure of the response is the same
 as the actual API response. For example, root property should be `data`.
 
-When testing queries, please keep in mind they are promises, so they need to be _resolved_ to render a result. Without resolving, we can check the `loading` state of the query:
+When testing queries, keep in mind they are promises, so they need to be _resolved_ to render a result. Without resolving, we can check the `loading` state of the query:
 
 ```javascript
 it('renders a loading state', () => {
@@ -2001,11 +2047,15 @@ relative to `app/graphql/queries` folder: for example, if we need a
 
 ### Mocked client returns empty objects instead of mock response
 
-If your unit test is failing because response contains empty objects instead of mock data, you would need to add `__typename` field to the mocked response. This happens because mocked client (unlike the real one) does not populate the response with typenames and in some cases we need to do it manually so the client is able to recognize a GraphQL type.
+If your unit test is failing because the response contains empty objects instead of mock data, add
+`__typename` field to the mocked responses.
+
+Alternatively, [GraphQL query fixtures](../testing_guide/frontend_testing.md#graphql-query-fixtures)
+automatically adds the `__typename` for you upon generation.
 
 ### Warning about losing cache data
 
-Sometimes you can see a warning in the console: `Cache data may be lost when replacing the someProperty field of a Query object. To address this problem, either ensure all objects of SomeEntityhave an id or a custom merge function`. Please check section about [multiple queries](#multiple-client-queries-for-the-same-object) to resolve an issue.
+Sometimes you can see a warning in the console: `Cache data may be lost when replacing the someProperty field of a Query object. To address this problem, either ensure all objects of SomeEntityhave an id or a custom merge function`. Check section about [multiple queries](#multiple-client-queries-for-the-same-object) to resolve an issue.
 
   ```yaml
   - current_route_path = request.fullpath.match(/-\/tree\/[^\/]+\/(.+$)/).to_a[1]
diff --git a/doc/development/fe_guide/icons.md b/doc/development/fe_guide/icons.md
index d107af156db..73f196ef51f 100644
--- a/doc/development/fe_guide/icons.md
+++ b/doc/development/fe_guide/icons.md
@@ -81,7 +81,7 @@ export default {
 
 ### Usage in HTML/JS
 
-Please use the following function inside JS to render an icon:
+Use the following function inside JS to render an icon:
 `gl.utils.spriteIcon(iconName)`
 
 ## Loading icon
diff --git a/doc/development/fe_guide/index.md b/doc/development/fe_guide/index.md
index 544985d7edc..02086ec5f1b 100644
--- a/doc/development/fe_guide/index.md
+++ b/doc/development/fe_guide/index.md
@@ -147,7 +147,7 @@ Best practices for [client-side logging](logging.md) for GitLab frontend develop
 
 ## [Internationalization (i18n) and Translations](../i18n/externalization.md)
 
-Frontend internationalization support is described in [this document](../i18n/).
+Frontend internationalization support is described in [this document](../i18n/index.md).
 The [externalization part of the guide](../i18n/externalization.md) explains the helpers/methods available.
 
 ## [Troubleshooting](troubleshooting.md)
diff --git a/doc/development/fe_guide/merge_request_widget_extensions.md b/doc/development/fe_guide/merge_request_widget_extensions.md
new file mode 100644
index 00000000000..a2ff10cc57f
--- /dev/null
+++ b/doc/development/fe_guide/merge_request_widget_extensions.md
@@ -0,0 +1,437 @@
+---
+stage: Create
+group: Code Review
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Merge request widget extensions **(FREE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/44616) in GitLab 13.6.
+
+Extensions in the merge request widget enable you to add new features
+into the merge request widget that match the design framework.
+With extensions we get a lot of benefits out of the box without much effort required, like:
+
+- A consistent look and feel.
+- Tracking when the extension is opened.
+- Virtual scrolling for performance.
+
+## Usage
+
+To use extensions you must first create a new extension object to fetch the
+data to render in the extension. For a working example, refer to the example file in
+`app/assets/javascripts/vue_merge_request_widget/extensions/issues.js`.
+
+The basic object structure:
+
+```javascript
+export default {
+  name: '',       // Required: This helps identify the widget
+  props: [],      // Required: Props passed from the widget state
+  i18n: {         // Required: Object to hold i18n text
+    label: '',    // Required: Used for tooltips and aria-labels
+    loading: '',  // Required: Loading text for when data is loading
+  },
+  expandEvent: '',      // Optional: RedisHLL event name to track expanding content
+  enablePolling: false, // Optional: Tells extension to poll for data
+  modalComponent: null, // Optional: The component to use for the modal
+  telemetry: true,      // Optional: Reports basic telemetry for the extension. Set to false to disable telemetry
+  computed: {
+    summary(data) {},     // Required: Level 1 summary text
+    statusIcon(data) {},  // Required: Level 1 status icon
+    tertiaryButtons() {}, // Optional: Level 1 action buttons
+    shouldCollapse() {}, // Optional: Add logic to determine if the widget can expand or not
+  },
+  methods: {
+    fetchCollapsedData(props) {}, // Required: Fetches data required for collapsed state
+    fetchFullData(props) {},      // Required: Fetches data for the full expanded content
+    fetchMultiData() {},          // Optional: Works in conjunction with `enablePolling` and allows polling multiple endpoints
+  },
+};
+```
+
+By following the same data structure, each extension can follow the same registering structure,
+but each extension can manage its data sources.
+
+After creating this structure, you must register it. You can register the extension at any
+point _after_ the widget has been created. To register a extension:
+
+```javascript
+// Import the register method
+import { registerExtension } from '~/vue_merge_request_widget/components/extensions';
+
+// Import the new extension
+import issueExtension from '~/vue_merge_request_widget/extensions/issues';
+
+// Register the imported extension
+registerExtension(issueExtension);
+```
+
+## Data fetching
+
+Each extension must fetch data. Fetching is handled when registering the extension,
+not by the core component itself. This approach allows for various different
+data fetching methods to be used, such as GraphQL or REST API calls.
+
+### API calls
+
+For performance reasons, it is best if the collapsed state fetches only the data required to
+render the collapsed state. This fetching happens in the `fetchCollapsedData` method.
+This method is called with the props as an argument, so you can easily access
+any paths set in the state.
+
+To allow the extension to set the data, this method **must** return the data. No
+special formatting is required. When the extension receives this data,
+it is set to `collapsedData`. You can access `collapsedData` in any computed property or
+method.
+
+When the user clicks **Expand**, the `fetchFullData` method is called. This method
+also gets called with the props as an argument. This method **must** also return
+the full data. However, this data must be correctly formatted to match the format
+mentioned in the data structure section.
+
+#### Technical debt
+
+For some of the current extensions, there is no split in data fetching. All the data
+is fetched through the `fetchCollapsedData` method. While less performant,
+it allows for faster iteration.
+
+To handle this the `fetchFullData` returns the data set through
+the `fetchCollapsedData` method call. In these cases, the `fetchFullData` must
+return a promise:
+
+```javascript
+fetchCollapsedData() {
+  return ['Some data'];
+},
+fetchFullData() {
+  return Promise.resolve(this.collapsedData)
+},
+```
+
+### Data structure
+
+The data returned from `fetchFullData` must match the format below. This format
+allows the core component to render the data in a way that matches
+the design framework. Any text properties can use the styling placeholders
+mentioned below:
+
+```javascript
+{
+  id: data.id,    // Required: ID used as a key for each row
+  header: 'Header' || ['Header', 'sub-header'], // Required: String or array can be used for the header text
+  text: '',       // Required: Main text for the row
+  subtext: '',    // Optional: Smaller sub-text to be displayed below the main text
+  icon: {         // Optional: Icon object
+    name: EXTENSION_ICONS.success, // Required: The icon name for the row
+  },
+  badge: {        // Optional: Badge displayed after text
+    text: '',     // Required: Text to be displayed inside badge
+    variant: '',  // Optional: GitLab UI badge variant, defaults to info
+  },
+  link: {         // Optional: Link to a URL displayed after text
+    text: '',     // Required: Text of the link
+    href: '',     // Optional: URL for the link
+  },
+  modal: {        // Optional: Link to open a modal displayed after text
+    text: '',     // Required: Text of the link
+    onClick: () => {} // Optional: Function to run when link is clicked, i.e. to set this.modalData
+  }
+  actions: [],    // Optional: Action button for row
+  children: [],   // Optional: Child content to render, structure matches the same structure
+}
+```
+
+### Polling
+
+To enable polling for an extension, an options flag must be present in the extension:
+
+```javascript
+export default {
+  //...
+  enablePolling: true
+};
+```
+
+This flag tells the base component we should poll the `fetchCollapsedData()`
+defined in the extension. Polling stops if the response has data, or if an error is present.
+
+When writing the logic for `fetchCollapsedData()`, a complete Axios response must be returned
+from the method. The polling utility needs data like polling headers to work correctly:
+
+```javascript
+export default {
+  //...
+  enablePolling: true
+  methods: {
+    fetchCollapsedData() {
+      return axios.get(this.reportPath)
+    },
+  },
+};
+```
+
+Most of the time the data returned from the extension's endpoint is not in the format
+the UI needs. We must format the data before setting the collapsed data in the base component.
+
+If the computed property `summary` can rely on `collapsedData`, you can format the data
+when `fetchFullData` is invoked:
+
+```javascript
+export default {
+  //...
+  enablePolling: true
+  methods: {
+    fetchCollapsedData() {
+      return axios.get(this.reportPath)
+    },
+     fetchFullData() {
+      return Promise.resolve(this.prepareReports());
+    },
+    // custom method
+    prepareReports() {
+      // unpack values from collapsedData
+      const { new_errors, existing_errors, resolved_errors } = this.collapsedData;
+
+      // perform data formatting
+
+      return [...newErrors, ...existingErrors, ...resolvedErrors]
+    }
+  },
+};
+```
+
+If the extension relies on `collapsedData` being formatted before invoking `fetchFullData()`,
+then `fetchCollapsedData()` must return the Axios response as well as the formatted data:
+
+```javascript
+export default {
+  //...
+  enablePolling: true
+  methods: {
+    fetchCollapsedData() {
+      return axios.get(this.reportPath).then(res => {
+        const formattedData = this.prepareReports(res.data)
+
+        return {
+          ...res,
+          data: formattedData,
+        }
+      })
+    },
+    // Custom method
+    prepareReports() {
+      // Unpack values from collapsedData
+      const { new_errors, existing_errors, resolved_errors } = this.collapsedData;
+
+      // Perform data formatting
+
+      return [...newErrors, ...existingErrors, ...resolvedErrors]
+    }
+  },
+};
+```
+
+If the extension must poll multiple endpoints at the same time, then `fetchMultiData`
+can be used to return an array of functions. A new `poll` object is created for each
+endpoint and they are polled separately. After all endpoints are resolved, polling is
+stopped and `setCollapsedData` is called with an array of `response.data`.
+
+```javascript
+export default {
+  //...
+  enablePolling: true
+  methods: {
+    fetchMultiData() {
+      return [
+        () => axios.get(this.reportPath1),
+        () => axios.get(this.reportPath2),
+        () => axios.get(this.reportPath3)
+    },
+  },
+};
+```
+
+WARNING:
+The function must return a `Promise` that resolves the `response` object.
+The implementation relies on the `POLL-INTERVAL` header to keep polling, therefore it is
+important not to alter the status code and headers.
+
+### Errors
+
+If `fetchCollapsedData()` or `fetchFullData()` methods throw an error:
+
+- The loading state of the extension is updated to `LOADING_STATES.collapsedError`
+  and `LOADING_STATES.expandedError` respectively.
+- The extensions header displays an error icon and updates the text to be either:
+  - The text defined in `$options.i18n.error`.
+  - "Failed to load" if `$options.i18n.error` is not defined.
+- The error is sent to Sentry to log that it occurred.
+
+To customise the error text, add it to the `i18n` object in your extension:
+
+```javascript
+export default {
+  //...
+  i18n: {
+    //...
+    error: __('Your error text'),
+  },
+};
+```
+
+## Telemetry
+
+The base implementation of the widget extension framework includes some telemetry events.
+Each widget reports:
+
+- `view`: When it is rendered to the screen.
+- `expand`: When it is expanded.
+- `full_report_clicked`: When an (optional) input is clicked to view the full report.
+- Outcome (`expand_success`, `expand_warning`, or `expand_failed`): One of three
+  additional events relating to the status of the widget when it was expanded.
+
+### Add new widgets
+
+When adding new widgets, the above events must be marked as `known`, and have metrics
+created, to be reportable.
+
+NOTE:
+Events that are only for EE should include `--ee` at the end of both shell commands below.
+
+To generate these known events for a single widget:
+
+1. Widgets should be named `Widget${CamelName}`.
+   - For example: a widget for **Test Reports** should be `WidgetTestReports`.
+1. Compute the widget name slug by converting the `${CamelName}` to lower-, snake-case.
+   - The previous example would be `test_reports`.
+1. Add the new widget name slug to `lib/gitlab/usage_data_counters/merge_request_widget_extension_counter.rb`
+   in the `WIDGETS` list.
+1. Ensure the GDK is running (`gdk start`).
+1. Generate known events on the command line with the following command.
+   Replace `test_reports` with your appropriate name slug:
+
+   ```shell
+   bundle exec rails generate gitlab:usage_metric_definition \
+   counts.i_code_review_merge_request_widget_test_reports_count_view \
+   counts.i_code_review_merge_request_widget_test_reports_count_full_report_clicked \
+   counts.i_code_review_merge_request_widget_test_reports_count_expand \
+   counts.i_code_review_merge_request_widget_test_reports_count_expand_success \
+   counts.i_code_review_merge_request_widget_test_reports_count_expand_warning \
+   counts.i_code_review_merge_request_widget_test_reports_count_expand_failed \
+   --dir=all
+   ```
+
+1. Modify each newly generated file to match the existing files for the merge request widget extension telemetry.
+   - Find existing examples by doing a glob search, like: `metrics/**/*_i_code_review_merge_request_widget_*`
+   - Roughly speaking, each file should have these values:
+     1. `description` = A plain English description of this value. Review existing widget extension telemetry files for examples.
+     1. `product_section` = `dev`
+     1. `product_stage` = `create`
+     1. `product_group` = `code_review`
+     1. `product_category` = `code_review`
+     1. `introduced_by_url` = `'[your MR]'`
+     1. `options.events` = (the event in the command from above that generated this file, like `i_code_review_merge_request_widget_test_reports_count_view`)
+         - This value is how the telemetry events are linked to "metrics" so this is probably one of the more important values.
+     1. `data_source` = `redis`
+     1. `data_category` = `optional`
+1. Generate known HLL events on the command line with the following command.
+   Replace `test_reports` with your appropriate name slug.
+
+   ```shell
+   bundle exec rails generate gitlab:usage_metric_definition:redis_hll code_review \
+   i_code_review_merge_request_widget_test_reports_view \
+   i_code_review_merge_request_widget_test_reports_full_report_clicked \
+   i_code_review_merge_request_widget_test_reports_expand \
+   i_code_review_merge_request_widget_test_reports_expand_success \
+   i_code_review_merge_request_widget_test_reports_expand_warning \
+   i_code_review_merge_request_widget_test_reports_expand_failed \
+   --class_name=RedisHLLMetric
+   ```
+
+1. Repeat step 6, but change the `data_source` to `redis_hll`.
+1. Add each of the HLL metrics to `lib/gitlab/usage_data_counters/known_events/code_review_events.yml`:
+    1. `name` = (the event)
+    1. `redis_slot` = `code_review`
+    1. `category` = `code_review`
+    1. `aggregation` = `weekly`
+1. Add each event to the appropriate aggregates in `config/metrics/aggregates/code_review.yml`
+
+### Add new events
+
+If you are adding a new event to our known events, include the new event in the
+`KNOWN_EVENTS` list in `lib/gitlab/usage_data_counters/merge_request_widget_extension_counter.rb`.
+
+## Icons
+
+Level 1 and all subsequent levels can have their own status icons. To keep with
+the design framework, import the `EXTENSION_ICONS` constant
+from the `constants.js` file:
+
+```javascript
+import { EXTENSION_ICONS } from '~/vue_merge_request_widget/constants.js';
+```
+
+This constant has the below icons available for use. Per the design framework,
+only some of these icons should be used on level 1:
+
+- `failed`
+- `warning`
+- `success`
+- `neutral`
+- `error`
+- `notice`
+- `severityCritical`
+- `severityHigh`
+- `severityMedium`
+- `severityLow`
+- `severityInfo`
+- `severityUnknown`
+
+## Text styling
+
+Any area that has text can be styled with the placeholders below. This
+technique follows the same technique as `sprintf`. However, instead of specifying
+these through `sprintf`, the extension does this automatically.
+
+Every placeholder contains starting and ending tags. For example, `success` uses
+`Hello %{success_start}world%{success_end}`. The extension then
+adds the start and end tags with the correct styling classes.
+
+| Placeholder | Style                                   |
+|-------------|-----------------------------------------|
+| success     | `gl-font-weight-bold gl-text-green-500` |
+| danger      | `gl-font-weight-bold gl-text-red-500`   |
+| critical    | `gl-font-weight-bold gl-text-red-800`   |
+| same        | `gl-font-weight-bold gl-text-gray-700`  |
+| strong      | `gl-font-weight-bold`                   |
+| small       | `gl-font-sm`                            |
+
+## Action buttons
+
+You can add action buttons to all level 1 and 2 in each extension. These buttons
+are meant as a way to provide links or actions for each row:
+
+- Action buttons for level 1 can be set through the `tertiaryButtons` computed property.
+  This property should return an array of objects for each action button.
+- Action buttons for level 2 can be set by adding the `actions` key to the level 2 rows object.
+  The value for this key must also be an array of objects for each action button.
+
+Links must follow this structure:
+
+```javascript
+{
+  text: 'Click me',
+  href: this.someLinkHref,
+  target: '_blank', // Optional
+}
+```
+
+For internal action buttons, follow this structure:
+
+```javascript
+{
+  text: 'Click me',
+  onClick() {}
+}
+```
diff --git a/doc/development/fe_guide/performance.md b/doc/development/fe_guide/performance.md
index bcdc49a1070..2e1fabd739c 100644
--- a/doc/development/fe_guide/performance.md
+++ b/doc/development/fe_guide/performance.md
@@ -8,6 +8,21 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Performance is an essential part and one of the main areas of concern for any modern application.
 
+## Monitoring
+
+We have a performance dashboard available in one of our [Grafana instances](https://dashboards.gitlab.net/d/000000043/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 4 hours. These changes are displayed after a set number of pages are aggregated.
+
+These pages can be found inside text files in the [`sitespeed-measurement-setup` repository](https://gitlab.com/gitlab-org/frontend/sitespeed-measurement-setup) called [`gitlab`](https://gitlab.com/gitlab-org/frontend/sitespeed-measurement-setup/-/tree/master/gitlab)
+Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing URLs of pages to the text files. The changes are pushed live on the next scheduled run after the changes are merged into `main`.
+
+There are 3 recommended high impact metrics (core web vitals) to review on each page:
+
+- [Largest Contentful Paint](https://web.dev/lcp/)
+- [First Input Delay](https://web.dev/fid/)
+- [Cumulative Layout Shift](https://web.dev/cls/)
+
+For these metrics, lower numbers are better as it means that the website is more performant.
+
 ## User Timing API
 
 [User Timing API](https://developer.mozilla.org/en-US/docs/Web/API/User_Timing_API) is a web API
@@ -77,9 +92,9 @@ performance.getEntriesByType('mark');
 performance.getEntriesByType('measure');
 ```
 
-Using `getEntriesByName()` or `getEntriesByType()` returns an Array of [the PerformanceMeasure
-objects](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceMeasure) which contain
-information about the measurement's start time and duration.
+Using `getEntriesByName()` or `getEntriesByType()` returns an Array of
+[the PerformanceMeasure objects](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceMeasure)
+which contain information about the measurement's start time and duration.
 
 ### User Timing API utility
 
@@ -220,7 +235,7 @@ Use the following rules when creating real-time solutions.
    A `Poll-Interval: -1` means you should disable polling, and this must be implemented.
 1. A response with HTTP status different from 2XX should disable polling as well.
 1. Use a common library for polling.
-1. Poll on active tabs only. Please use [Visibility](https://github.com/ai/visibilityjs).
+1. Poll on active tabs only. Use [Visibility](https://github.com/ai/visibilityjs).
 1. Use regular polling intervals, do not use backoff polling or jitter, as the interval is
    controlled by the server.
 1. The backend code is likely to be using ETags. You do not and should not check for status
@@ -434,7 +449,7 @@ Use `webpackChunkName` when generating dynamic imports as
 it provides a deterministic filename for the chunk which can then be cached
 in the browser across GitLab versions.
 
-More information is available in [webpack's code splitting documentation](https://webpack.js.org/guides/code-splitting/#dynamic-imports) and [vue's dynamic component documentation](https://vuejs.org/v2/guide/components-dynamic-async.html).
+More information is available in [webpack's code splitting documentation](https://webpack.js.org/guides/code-splitting/#dynamic-imports) and [vue's dynamic component documentation](https://v2.vuejs.org/v2/guide/components-dynamic-async.html).
 
 ### Minimizing page size
 
diff --git a/doc/development/fe_guide/source_editor.md b/doc/development/fe_guide/source_editor.md
index b06e341630f..88508e94380 100644
--- a/doc/development/fe_guide/source_editor.md
+++ b/doc/development/fe_guide/source_editor.md
@@ -129,7 +129,7 @@ with additional functions on the instance level:
 
 Source Editor provides a universal, extensible editing tool to the whole product,
 and doesn't depend on any particular group. Even though the Source Editor's core is owned by
-[Create::Editor FE Team](https://about.gitlab.com/handbook/engineering/development/dev/create-editor/),
+[Create::Editor FE Team](https://about.gitlab.com/handbook/engineering/development/dev/create/editor/),
 any group can own the extensions—the main functional elements. The goal of
 Source Editor extensions is to keep the editor's core slim and stable. Any
 needed features can be added as extensions to this core. Any group can
diff --git a/doc/development/fe_guide/storybook.md b/doc/development/fe_guide/storybook.md
index 4c0e7b2612b..45342eb6d72 100644
--- a/doc/development/fe_guide/storybook.md
+++ b/doc/development/fe_guide/storybook.md
@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Storybook
 
-The Storybook for the `gitlab-org/gitlab` project is available on our [GitLab Pages site](https://gitlab-org.gitlab.io/gitlab/storybook).
+The Storybook for the `gitlab-org/gitlab` project is available on our [GitLab Pages site](https://gitlab-org.gitlab.io/gitlab/storybook/).
 
 ## Storybook in local development
 
diff --git a/doc/development/fe_guide/style/javascript.md b/doc/development/fe_guide/style/javascript.md
index d93dc8292d4..b86bdfafa21 100644
--- a/doc/development/fe_guide/style/javascript.md
+++ b/doc/development/fe_guide/style/javascript.md
@@ -123,7 +123,8 @@ things.map(parseInt);
 things.map(Number);
 ```
 
-**PLEASE NOTE:** If the String could represent a non-integer (i.e., it includes a decimal), **do not** use `parseInt`. Consider `Number` or `parseFloat` instead.
+NOTE:
+If the String could represent a non-integer (i.e., it includes a decimal), **do not** use `parseInt`. Consider `Number` or `parseFloat` instead.
 
 ## CSS Selectors - Use `js-` prefix
 
diff --git a/doc/development/fe_guide/style/scss.md b/doc/development/fe_guide/style/scss.md
index 451b0c8a4c6..17e80762a38 100644
--- a/doc/development/fe_guide/style/scss.md
+++ b/doc/development/fe_guide/style/scss.md
@@ -12,7 +12,7 @@ easy to maintain, and performant for the end-user.
 
 ## Rules
 
-Our CSS is a mixture of current and legacy approaches. That means sometimes it may be difficult to follow this guide to the letter; it means you are likely to run into exceptions, where following the guide is difficult to impossible without major effort. In those cases, you may work with your reviewers and maintainers to identify an approach that does not fit these rules. Please endeavor to limit these cases.
+Our CSS is a mixture of current and legacy approaches. That means sometimes it may be difficult to follow this guide to the letter; it means you are likely to run into exceptions, where following the guide is difficult to impossible without major effort. In those cases, you may work with your reviewers and maintainers to identify an approach that does not fit these rules. Try to limit these cases.
 
 ### Utility Classes
 
diff --git a/doc/development/fe_guide/style/vue.md b/doc/development/fe_guide/style/vue.md
index 5c79d47e7b0..c9bd0e1b35a 100644
--- a/doc/development/fe_guide/style/vue.md
+++ b/doc/development/fe_guide/style/vue.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 ## Linting
 
 We default to [eslint-vue-plugin](https://github.com/vuejs/eslint-plugin-vue), with the `plugin:vue/recommended`.
-Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) for more documentation.
+Check the [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) for more documentation.
 
 ## Basic Rules
 
@@ -448,9 +448,9 @@ Typically, when testing a Vue component, the component should be "re-mounted" in
 To achieve this:
 
 1. Create a mutable `wrapper` variable inside the top-level `describe` block.
-1. Mount the component using [`mount`](https://vue-test-utils.vuejs.org/api/#mount)/
-[`shallowMount`](https://vue-test-utils.vuejs.org/api/#shallowMount).
-1. Reassign the resulting [`Wrapper`](https://vue-test-utils.vuejs.org/api/wrapper/#wrapper)
+1. Mount the component using [`mount`](https://v1.test-utils.vuejs.org/api/#mount)/
+[`shallowMount`](https://v1.test-utils.vuejs.org/api/#shallowMount).
+1. Reassign the resulting [`Wrapper`](https://v1.test-utils.vuejs.org/api/wrapper/#wrapper)
 instance to our `wrapper` variable.
 
 Creating a global, mutable wrapper provides a number of advantages, including the ability to:
@@ -476,8 +476,8 @@ Creating a global, mutable wrapper provides a number of advantages, including th
 
 To avoid duplicating our mounting logic, it's useful to define a `createComponent` factory function
 that we can reuse in each test block. This is a closure which should reassign our `wrapper` variable
-to the result of [`mount`](https://vue-test-utils.vuejs.org/api/#mount) and
-[`shallowMount`](https://vue-test-utils.vuejs.org/api/#shallowMount):
+to the result of [`mount`](https://v1.test-utils.vuejs.org/api/#mount) and
+[`shallowMount`](https://v1.test-utils.vuejs.org/api/#shallowMount):
 
 ```javascript
 import MyComponent from '~/path/to/my_component.vue';
@@ -579,9 +579,9 @@ the mounting function (`mount` or `shallowMount`) to be used to mount the compon
 
 ### Setting component state
 
-1. Avoid using [`setProps`](https://vue-test-utils.vuejs.org/api/wrapper/#setprops) to set
+1. Avoid using [`setProps`](https://v1.test-utils.vuejs.org/api/wrapper/#setprops) to set
 component state wherever possible. Instead, set the component's
-[`propsData`](https://vue-test-utils.vuejs.org/api/options.html#propsdata) when mounting the component:
+[`propsData`](https://v1.test-utils.vuejs.org/api/options.html#propsdata) when mounting the component:
 
     ```javascript
     // bad
@@ -659,7 +659,7 @@ The goal of this accord is to make sure we are all on the same page.
    1. If an outside jQuery Event needs to be listen to inside the Vue application, you may use
    jQuery event listeners.
    1. We avoid adding new jQuery events when they are not required. Instead of adding new jQuery
-   events take a look at [different methods to do the same task](https://vuejs.org/v2/api/#vm-emit).
+   events take a look at [different methods to do the same task](https://v2.vuejs.org/v2/api/#vm-emit).
 1. You may query the `window` object one time, while bootstrapping your application for application
 specific data (for example, `scrollTo` is ok to access anytime). Do this access during the
 bootstrapping of your application.
diff --git a/doc/development/fe_guide/tooling.md b/doc/development/fe_guide/tooling.md
index 1c32647eefd..2bb6cbfaf7a 100644
--- a/doc/development/fe_guide/tooling.md
+++ b/doc/development/fe_guide/tooling.md
@@ -175,7 +175,7 @@ preferred editor (all major editors are supported) accordingly. We suggest
 setting up Prettier to run when each file is saved. For instructions about using
 Prettier in your preferred editor, see the [Prettier documentation](https://prettier.io/docs/en/editors.html).
 
-Please take care that you only let Prettier format the same file types as the global Yarn script does (`.js`, `.vue`, `.graphql`, and `.scss`). For example, you can exclude file formats in your Visual Studio Code settings file:
+Take care that you only let Prettier format the same file types as the global Yarn script does (`.js`, `.vue`, `.graphql`, and `.scss`). For example, you can exclude file formats in your Visual Studio Code settings file:
 
 ```json
   "prettier.disableLanguages": [
diff --git a/doc/development/fe_guide/troubleshooting.md b/doc/development/fe_guide/troubleshooting.md
index 14943cca3ac..c0894621ed1 100644
--- a/doc/development/fe_guide/troubleshooting.md
+++ b/doc/development/fe_guide/troubleshooting.md
@@ -12,7 +12,7 @@ Running into a problem? Maybe this will help ¯\＿(ツ)＿/¯.
 
 ### This guide doesn't contain the issue I ran into
 
-If you run into a Frontend development issue that is not in this guide, please consider updating this guide with your issue and possible remedies. This way future adventurers can face these dragons with more success, being armed with your experience and knowledge.
+If you run into a Frontend development issue that is not in this guide, consider updating this guide with your issue and possible remedies. This way future adventurers can face these dragons with more success, being armed with your experience and knowledge.
 
 ## Testing issues
 
diff --git a/doc/development/fe_guide/view_component.md b/doc/development/fe_guide/view_component.md
index f4bb7ac3a2e..2e373e6933b 100644
--- a/doc/development/fe_guide/view_component.md
+++ b/doc/development/fe_guide/view_component.md
@@ -13,18 +13,24 @@ They are rendered server-side and can be seamlessly used with template languages
 Refer to the official [documentation](https://viewcomponent.org/) to learn more or
 watch this [introduction video](https://youtu.be/akRhUbvtnmo).
 
+## Browse components with Lookbook
+
+We have a [Lookbook](https://github.com/allmarkedup/lookbook) in [http://gdk.test:3000/rails/lookbook](http://gdk.test:3000/rails/lookbook) (only available in development mode) to browse and interact with ViewComponent previews.
+
 ## Pajamas components
 
 Some of the components of our [Pajamas](https://design.gitlab.com) design system are
 available as a ViewComponent in `app/components/pajamas`.
 
 NOTE:
-We have a small but growing number of Pajamas components. Reach out to the
-[Foundations team](https://about.gitlab.com/handbook/engineering/development/dev/ecosystem/foundations/)
+We are still in the process of creating these components, so not every Pajamas component is available as ViewComponent.
+Reach out to the [Foundations team](https://about.gitlab.com/handbook/engineering/development/dev/ecosystem/foundations/)
 if the component you are looking for is not yet available.
 
 ### Available components
 
+Consider this list a best effort. The full list can be found in [`app/components/pajamas`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/app/components/pajamas). Also see [our Lookbook](http://gdk.test:3000/rails/lookbook) for a more interactive way to browse our components.
+
 #### Alert
 
 The `Pajamas::AlertComponent` follows the [Pajamas Alert](https://design.gitlab.com/components/alert) specification.
@@ -147,6 +153,39 @@ If you want to add custom attributes to any of these or the card itself, use the
 For the full list of options, see its
 [source](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/components/pajamas/card_component.rb).
 
+#### Checkbox tag
+
+The `Pajamas::CheckboxTagComponent` follows the [Pajamas Checkbox](https://design.gitlab.com/components/checkbox) specification.
+
+The `name` argument and `label` slot are required.
+
+For example:
+
+```haml
+= render Pajamas::CheckboxTagComponent.new(name: 'project[initialize_with_sast]',
+  checkbox_options: { data: { qa_selector: 'initialize_with_sast_checkbox', track_label: track_label, track_action: 'activate_form_input', track_property: 'init_with_sast' } }) do |c|
+  = c.label do
+    = s_('ProjectsNew|Enable Static Application Security Testing (SAST)')
+  = c.help_text do
+    = s_('ProjectsNew|Analyze your source code for known security vulnerabilities.')
+    = link_to _('Learn more.'), help_page_path('user/application_security/sast/index'), target: '_blank', rel: 'noopener noreferrer', data: { track_action: 'followed' }
+```
+
+For the full list of options, see its
+[source](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/components/pajamas/checkbox_tag_component.rb).
+
+#### Checkbox
+
+The `Pajamas::CheckboxComponent` follows the [Pajamas Checkbox](https://design.gitlab.com/components/checkbox) specification.
+
+NOTE:
+`Pajamas::CheckboxComponent` is used internally by the [GitLab UI form builder](haml.md#use-the-gitlab-ui-form-builder) and requires an instance of [ActionView::Helpers::FormBuilder](https://api.rubyonrails.org/v6.1.0/classes/ActionView/Helpers/FormBuilder.html) to be passed as the `form` argument.
+It is preferred to use the [gitlab_ui_checkbox_component](haml.md#gitlab_ui_checkbox_component) method to render this ViewComponent.
+To use a checkbox without an instance of [ActionView::Helpers::FormBuilder](https://api.rubyonrails.org/v6.1.0/classes/ActionView/Helpers/FormBuilder.html) use [CheckboxTagComponent](#checkbox-tag).
+
+For the full list of options, see its
+[source](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/components/pajamas/checkbox_component.rb).
+
 #### Toggle
 
 The `Pajamas::ToggleComponent` follows the [Pajamas Toggle](https://design.gitlab.com/components/toggle) specification.
@@ -172,3 +211,5 @@ For the full list of options, see its
   over creating plain Haml tags with CSS classes.
 - If you are making changes to an existing Haml view and see, for example, a
   button that is still implemented with plain Haml, consider migrating it to use a ViewComponent.
+- If you decide to create a new component, consider creating [previews](https://viewcomponent.org/guide/previews.html) for it, too.
+  This will help others to discover your component with Lookbook, also it makes it much easier to test its different states.
diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md
index 7943ae119be..27660c0f5f7 100644
--- a/doc/development/fe_guide/vue.md
+++ b/doc/development/fe_guide/vue.md
@@ -71,7 +71,7 @@ component, is that you avoid creating a fixture or an HTML element in the unit t
 
 ##### `provide` and `inject`
 
-Vue supports dependency injection through [`provide` and `inject`](https://vuejs.org/v2/api/#provide-inject).
+Vue supports dependency injection through [`provide` and `inject`](https://v2.vuejs.org/v2/api/#provide-inject).
 In the component the `inject` configuration accesses the values `provide` passes down.
 This example of a Vue app initialization shows how the `provide` configuration passes a value from HAML to the component:
 
@@ -266,7 +266,7 @@ return new Vue({
 
 #### Accessing feature flags
 
-Use the [`provide` and `inject`](https://vuejs.org/v2/api/#provide-inject) mechanisms
+Use the [`provide` and `inject`](https://v2.vuejs.org/v2/api/#provide-inject) mechanisms
 in Vue to make feature flags available to any descendant components in a Vue
 application. The `glFeatures` object is already provided in `commons/vue.js`, so
 only the mixin is required to use the flags:
@@ -339,7 +339,7 @@ Check this [page](vuex.md) for more details.
 
 ### Mixing Vue and JavaScript classes (in the data function)
 
-In the [Vue documentation](https://vuejs.org/v2/api/#Options-Data) the Data function/object is defined as follows:
+In the [Vue documentation](https://v2.vuejs.org/v2/api/#Options-Data) the Data function/object is defined as follows:
 
 > The data object for the Vue instance. Vue recursively converts its properties into getter/setters
 to make it "reactive". The object must be plain: native objects such as browser API objects and
@@ -348,7 +348,7 @@ recommended to observe objects with their own stateful behavior.
 
 Based on the Vue guidance:
 
-- **Do not** use or create a JavaScript class in your [data function](https://vuejs.org/v2/api/#data),
+- **Do not** use or create a JavaScript class in your [data function](https://v2.vuejs.org/v2/api/#data),
 such as `user: new User()`.
 - **Do not** add new JavaScript class implementations.
 - **Do** use [GraphQL](../api_graphql_styleguide.md), [Vuex](vuex.md) or a set of components if
@@ -531,7 +531,7 @@ Each Vue component has a unique output. This output is always present in the ren
 Although each method of a Vue component can be tested individually, our goal is to test the output
 of the render function, which represents the state at all times.
 
-Visit the [Vue testing guide](https://vuejs.org/v2/guide/testing.html#Unit-Testing) for help
+Visit the [Vue testing guide](https://v2.vuejs.org/v2/guide/testing.html#Unit-Testing) for help
 testing the rendered output.
 
 Here's an example of a well structured unit test for [this Vue component](#appendix---vue-component-subject-under-test):
diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md
index 064f01c8195..8bfb912161a 100644
--- a/doc/development/fe_guide/vuex.md
+++ b/doc/development/fe_guide/vuex.md
@@ -165,7 +165,7 @@ Instead of creating an mutation to toggle the loading state, we should:
 
 As a result, we can dispatch the `fetchNamespace` action from the component and it is responsible to commit  `REQUEST_NAMESPACE`, `RECEIVE_NAMESPACE_SUCCESS` and `RECEIVE_NAMESPACE_ERROR` mutations.
 
-> Previously, we were dispatching actions from the `fetchNamespace` action instead of committing mutation, so please don't be confused if you find a different pattern in the older parts of the codebase. However, we encourage leveraging a new pattern whenever you write new Vuex stores.
+> Previously, we were dispatching actions from the `fetchNamespace` action instead of committing mutation, so don't be confused if you find a different pattern in the older parts of the codebase. However, we encourage leveraging a new pattern whenever you write new Vuex stores.
 
 By following this pattern we guarantee:
 
@@ -364,8 +364,8 @@ export default initialState => ({
 
 We made the conscious decision to avoid this pattern to improve the ability to
 discover and search our frontend codebase. The same applies
-when [providing data to a Vue app](vue.md#providing-data-from-haml-to-javascript). The reasoning for this is described in [this
-discussion](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/56#note_302514865):
+when [providing data to a Vue app](vue.md#providing-data-from-haml-to-javascript). The reasoning for this is described in 
+[this discussion](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/56#note_302514865):
 
 > Consider a `someStateKey` is being used in the store state. You _may_ not be
 > able to grep for it directly if it was provided only by `el.dataset`. Instead,
diff --git a/doc/development/fe_guide/widgets.md b/doc/development/fe_guide/widgets.md
index 02876afe597..b54f9add97d 100644
--- a/doc/development/fe_guide/widgets.md
+++ b/doc/development/fe_guide/widgets.md
@@ -141,3 +141,7 @@ methods: {
 ```
 
 [View an example of such a component.](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/notes/components/sidebar_subscription.vue)
+
+## Merge request widgets
+
+Refer to the documentation specific to the [merge request widget extension framework](merge_request_widget_extensions.md).