Handle more spelling exceptions

Tackle another round of exceptions to the spelling rule. Most of
these needed one-off exclusions.

Author: amyq

doc/.vale/gitlab/spelling-exceptions.txt

@@ -16,6 +16,7 @@ Anthos
 approvers
 architected
 architecting
+archiver
 Arel
 Artifactory
 Asana
@@ -183,6 +184,7 @@ failsafe
 Falco
 falsy
 fastlane
+Fastzip
 favicon
 favorited
 Figma
@@ -200,6 +202,8 @@ fuzzer
 Gantt
 Gemnasium
 Gemojione
+Getter
+Getters
 gettext
 Git
 Gitaly

doc/architecture/blueprints/graphql_api/index.md

@@ -113,7 +113,7 @@ this knowledge onto GraphQL and make it performant and secure by default.
 - Design direct uploads for GraphQL
 - Build GraphQL query depth and complexity histograms
 - Visualize the amount of GraphQL queries reaching limits
-- Add support for GraphQL etags for existing features
+- Add support for GraphQL ETags for existing features
 
 ### Design GraphQL interoperability with REST API
 
@@ -138,7 +138,7 @@ state synchronization mechanisms and hooking into existing ones.
 
 - Design a scalable state synchronization mechanism
 - Evaluate state synchronization through pub/sub and websockets
-- Build a generic support for GraphQL feature correlation and feature etags
+- Build a generic support for GraphQL feature correlation and feature ETags
 - Redesign frontend code responsible for managing shared global state
 
 ## Iterations

doc/ci/runners/README.md

@@ -280,7 +280,7 @@ On GitLab.com, you cannot override the job timeout for shared runners and must u
 To set the maximum job timeout:
 
 1. In a project, go to **Settings > CI/CD > Runners**.
-1. Select your specific runner to edit the settings. 
+1. Select your specific runner to edit the settings.
 1. Enter a value under **Maximum job timeout**.
 1. Select **Save changes**.
 
@@ -844,5 +844,5 @@ variables:
 | Variable                        | Description                                            |
 |---------------------------------|--------------------------------------------------------|
 | `TRANSFER_METER_FREQUENCY`      | Specify how often to print the meter's transfer rate. It can be set to a duration (for example, `1s` or `1m30s`). A duration of `0` disables the meter (default). When a value is set, the pipeline shows a progress meter for artifact and cache uploads and downloads. |
-| `ARTIFACT_COMPRESSION_LEVEL`    | To adjust compression ratio, set to `fastest`, `fast`, `default`, `slow`, or `slowest`. This setting works with the fastzip archiver only, so the GitLab Runner feature flag [`FF_USE_FASTZIP`](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) must also be enabled. |
-| `CACHE_COMPRESSION_LEVEL`       | To adjust compression ratio, set to `fastest`, `fast`, `default`, `slow`, or `slowest`. This setting works with the fastzip archiver only, so the GitLab Runner feature flag [`FF_USE_FASTZIP`](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) must also be enabled. |
+| `ARTIFACT_COMPRESSION_LEVEL`    | To adjust compression ratio, set to `fastest`, `fast`, `default`, `slow`, or `slowest`. This setting works with the Fastzip archiver only, so the GitLab Runner feature flag [`FF_USE_FASTZIP`](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) must also be enabled. |
+| `CACHE_COMPRESSION_LEVEL`       | To adjust compression ratio, set to `fastest`, `fast`, `default`, `slow`, or `slowest`. This setting works with the Fastzip archiver only, so the GitLab Runner feature flag [`FF_USE_FASTZIP`](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) must also be enabled. |

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 descretion](https://about.gitlab.com/handbook/engineering/#balance-refactoring-and-velocity)
+Throughout the GitLab codebase, there may be historic uses of these anti-patterns. Please [use discretion](https://about.gitlab.com/handbook/engineering/#balance-refactoring-and-velocity)
 when figuring out whether or not to refactor, when touching code that uses one of these legacy patterns.
 
 **Please note:** For new features, anti-patterns are not necessarily prohibited, but it is **strongly suggested** to find another approach.
@@ -45,7 +45,7 @@ the convenience does not always outweigh their heavy cost:
 - **No access control.** When Shared Global Objects manage some state, this can create some very buggy and difficult
   coupling situations because there is no access control to this object.
 - **Possible circular references.** Shared Global Objects can also create some circular referencing situations since submodules
-  of the Shared Global Object can reference modules that reference itself (see 
+  of the Shared Global Object can reference modules that reference itself (see
   [this MR for an example](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33366)).
 
 Here are some historic examples where this pattern was identified to be problematic:
@@ -72,7 +72,7 @@ To read more on this topic, check out the following references:
 
 ## Singleton (Anti-pattern)
 
-The classic [Singleton pattern](https://en.wikipedia.org/wiki/Singleton_pattern) is an approach to ensure that only one 
+The classic [Singleton pattern](https://en.wikipedia.org/wiki/Singleton_pattern) is an approach to ensure that only one
 instance of a thing exists.
 
 Here's an example of this pattern:
@@ -114,7 +114,7 @@ Here are some ills that Singletons often produce:
 
 1. **Non-deterministic tests.** Singletons encourage non-deterministic tests because the single instance is shared across
    individual tests, often causing the state of one test to bleed into another.
-1. **High coupling.** Under the hood, clients of a singleton class all share a single specific 
+1. **High coupling.** Under the hood, clients of a singleton class all share a single specific
    instance of an object, which means this pattern inherits all the [problems of Shared Global Object](#what-problems-do-shared-global-objects-cause)
    such as no clear ownership and no access control. These leads to high coupling situations that can
    be buggy and difficult to untangle.
@@ -174,13 +174,13 @@ export const fuzzify = (id) => { /* ... */ };
 #### Dependency Injection
 
 [Dependency Injection](https://en.wikipedia.org/wiki/Dependency_injection) is an approach which breaks
-coupling by declaring a module's dependencies to be injected from outside the module (e.g., through constructor parameters, a bon-a-fide Dependency Injection framework, and even Vue's `provide/inject`).
+coupling by declaring a module's dependencies to be injected from outside the module (e.g., through constructor parameters, a bona-fide Dependency Injection framework, and even Vue's `provide/inject`).
 
 ```javascript
 // bad - Vue component coupled to Singleton
 export default {
   created() {
-    this.mediator = MyFooMediator.getInstance();    
+    this.mediator = MyFooMediator.getInstance();
   },
 };
 
@@ -194,7 +194,7 @@ export default {
 // bad - We're not sure where the singleton is in it's lifecycle so we init it here.
 export class Foo {
   constructor() {
-    Bar.getInstance().init();    
+    Bar.getInstance().init();
   }
 
   stuff() {

doc/development/fe_guide/index.md

@@ -12,7 +12,10 @@ across the GitLab frontend team.
 ## Overview
 
 GitLab is built on top of [Ruby on Rails](https://rubyonrails.org). It uses [Haml](https://haml.info/) and a JavaScript0based frontend with [Vue.js](https://vuejs.org).
-Be wary of [the limitations that come with using Hamlit](https://github.com/k0kubun/hamlit/blob/master/REFERENCE.md#limitations). We also use [SCSS](https://sass-lang.com) and plain JavaScript with
+<!-- vale gitlab.Spelling = NO -->
+Be wary of [the limitations that come with using Hamlit](https://github.com/k0kubun/hamlit/blob/master/REFERENCE.md#limitations).
+<!-- vale gitlab.Spelling = YES -->
+We also use [SCSS](https://sass-lang.com) and plain JavaScript with
 modern ECMAScript standards supported through [Babel](https://babeljs.io/) and ES module support through [webpack](https://webpack.js.org/).
 
 Working with our frontend assets requires Node (v10.13.0 or greater) and Yarn

doc/development/fe_guide/performance.md

@@ -219,7 +219,7 @@ Use the following rules when creating real-time solutions.
 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. Use regular polling intervals, do not use backoff polling, or jitter, as the interval is
+1. Use regular polling intervals, do not use <!-- vale gitlab.Spelling = NO --> backoff polling <!-- vale gitlab.Spelling = YES --> 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
    `304 Not Modified`. The browser transforms it for you.

doc/development/fe_guide/style/javascript.md

@@ -14,7 +14,7 @@ In addition to the style guidelines set by Airbnb, we also have a few specific r
 listed below.
 
 NOTE:
-You can run eslint locally by running `yarn eslint`
+You can run ESLint locally by running `yarn eslint`
 
 ## Avoid forEach
 

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 outsized 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. Please endeavor to limit these cases.
 
 ### Utility Classes
 
@@ -21,10 +21,12 @@ In order to reduce the generation of more CSS as our site grows, prefer the use
 #### Where are utility classes defined?
 
 Prefer the use of [utility classes defined in GitLab UI](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/main/doc/css.md#utilities).
+<!-- vale gitlab.Spelling = NO -->
 An easy list of classes can also be [seen on Unpkg](https://unpkg.com/browse/@gitlab/ui/src/scss/utilities.scss).
+<!-- vale gitlab.Spelling = YES -->
 
 Classes in [`utilities.scss`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/stylesheets/utilities.scss) and [`common.scss`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/stylesheets/framework/common.scss) are being deprecated.
-Classes in [`common.scss`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/stylesheets/framework/common.scss) that use non-design system values should be avoided in favor of conformant values.
+Classes in [`common.scss`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/stylesheets/framework/common.scss) that use non-design-system values should be avoided. Use classes with conforming values instead.
 
 Avoid [Bootstrap's Utility Classes](https://getbootstrap.com/docs/4.3/utilities/).
 
@@ -49,7 +51,7 @@ We recommend a "utility-first" approach.
 1. Start with utility classes.
 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 non-reusable 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`).
 
 Inspiration:
 

doc/development/fe_guide/vue.md

@@ -20,7 +20,7 @@ What is described in the following sections can be found in these examples:
 
 All new features built with Vue.js must follow a [Flux architecture](https://facebook.github.io/flux/).
 The main goal we are trying to achieve is to have only one data flow and only one data entry.
-In order to achieve this goal we use [vuex](#vuex).
+In order to achieve this goal we use [Vuex](#vuex).
 
 You can also read about this architecture in Vue documentation about
 [state management](https://vuejs.org/v2/guide/state-management.html#Simple-State-Management-from-Scratch)
@@ -345,12 +345,12 @@ component under test, with the `computed` property, for example). Remember to us
 
   ```javascript
   const checkbox = wrapper.findByTestId('checkboxTestId');
-  
+
   expect(checkbox.attributes('disabled')).not.toBeDefined();
-  
+
   findChildComponent().vm.$emit('primary');
   await nextTick();
-  
+
   expect(checkbox.attributes('disabled')).toBeDefined();
   ```
 
@@ -359,7 +359,7 @@ component under test, with the `computed` property, for example). Remember to us
   ```javascript
   // bad
   expect(findChildComponent().find('.error-alert').exists()).toBe(false);
-  
+
   // good
   expect(findChildComponent().props('withAlertContainer')).toBe(false);
   ```

doc/development/fe_guide/vue3_migration.md

@@ -26,7 +26,7 @@ Component's computed properties / methods or external helpers.
 
 **What to use instead**
 
-Vue documentation recommends using the [mitt](https://github.com/developit/mitt) library. It's relatively small (200 bytes gzipped) and has a clear API:
+Vue documentation recommends using the [mitt](https://github.com/developit/mitt) library. It's relatively small (200 bytes, compressed) and has a clear API:
 
 ```javascript
 import mitt from 'mitt'
@@ -51,7 +51,7 @@ emitter.off('foo', onFoo)  // unlisten
 
 **Event hub factory**
 
-We have created a factory that you can use to instantiate a new mitt-based event hub. 
+We have created a factory that you can use to instantiate a new mitt-based event hub.
 This makes it easier to migrate existing event hubs to the new recommended approach, or
 to create new ones.