bitwarden · eliykat · Jul 19, 2023 · Apr 20, 2023 · Apr 20, 2023 · Apr 20, 2023
diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml
@@ -27,7 +27,8 @@ jobs:
           cache-dependency-path: "**/package-lock.json"
           node-version: "16"
 
-      - name: Run linter
+      - name: Run linter and spellcheck
         run: |
           npm ci
           npm run lint
+          npm run spellcheck
diff --git a/README.md b/README.md
@@ -47,6 +47,12 @@ Please follow the following (very brief) style guide:
 - Use code blocks for all commands. Don't write them in-line.
 - Avoid long paragraphs - this documentation should be to-the-point and instructional.
 
+### Spellchecker
+
+We use `cspell` for spellchecking. It will run as a pre-commit hook and in the CI pipeline.
+Spellchecking ignores single and multi-line code snippets. If required, you can add custom words
+(e.g. proper nouns and technical terms) to `custom-words.txt`.
+
 ### Conditional Content
 
 The Contributing Docs site is used both for internal and external contributors. To this end we've

diff --git a/cspell.yaml b/cspell.yaml
@@ -0,0 +1,36 @@
+---
+dictionaries:
+  - custom-words
+dictionaryDefinitions:
+  - name: custom-words
+    path: ./custom-words.txt
+    addWords: true
+patterns:
+  # Ignore multi-line code blocks
+  # Ref: https://cspell.org/configuration/patterns/
+  # Modified to avoid matching line breaks before/after which had unexpected results
+  - name: markdown_code_block
+    pattern: |
+      /
+          ^[ \t]*     # match optional whitespace before the ```
+          (`{3}).*    # match the ``` and any optional language specification afterwards
+          [\s\S]*?    # the block of code
+          ^[ \t]*     # match optional whitespace before the ```
+          \1          # end of the block
+      /gmx
+
+  # Ignore inline code blocks
+  - name: markdown_code_inline
+    pattern: |
+      /
+          `           # match the opening `
+          .*?         # match any characters, lazily (so that we stop at the next tilde)
+          `           # match the closing `
+      /gx
+languageSettings:
+  - languageId:
+      - markdown
+      - mdx
+    ignoreRegExpList:
+      - markdown_code_block
+      - markdown_code_inline
diff --git a/custom-words.txt b/custom-words.txt
@@ -0,0 +1,51 @@
+# Custom dictionary for spellchecking
+# Before adding a word here, consider whether you can put it in a single (`) or multiline (```) code snippet instead,
+# as they are automatically ignored by the spellchecker
+
+Bitwarden
+bytemark
+CQRS
+dockerized
+hotfix
+hotfixes
+hotfixed
+inet
+Iterm
+jslib
+jumpcloud
+keychain
+keyserver
+LDIF
+LLDB
+Mailcatcher
+minio
+MVVM
+NGRX
+Omnisharp
+opid
+passcode
+passwordless
+PNSs
+proxied
+roadmap
+roadmaps
+SCIM
+SDET
+signtool
+signup
+sqlcmd
+TOTP
+Yellowpages
+CODEOWNERS
+SDLC
+subprocessor
+Gitter
+IntelliJ
+WCAG
+pinentry
+refactorings
+toolset
+keypair
+onboarded
+OIDCS
+oktapreview
diff --git a/docs/architecture/adr/0003-observable-data-services.md b/docs/architecture/adr/0003-observable-data-services.md
@@ -26,7 +26,7 @@ results in the components re-fetching their state manually.
 
 Chosen option: **Observable data services**, because
 
-- Allows us to quickly interate towards a more reactive data model.
+- Allows us to quickly iterate towards a more reactive data model.
   - Reactive data model lets us get rid of the event messages.
   - Components will always display the latest state.
 - Does not require a significant upfront investment.
@@ -68,7 +68,7 @@ class Component implements OnDestroy {
 ```
 
 In this example we use the `takeUntil` pattern which can be combined with an eslint rule to ensure
-each component clens up after themselves.
+each component cleans up after themselves.
 
 ## Pros and Cons of the Options
 

diff --git a/docs/architecture/adr/0004-refactor-state-service.md b/docs/architecture/adr/0004-refactor-state-service.md
@@ -18,17 +18,17 @@ handled by a single service. This has resulted in everything being tightly coupl
 `StateService` essentially making it a God object.
 
 Additionally any service or component can directly access any state using the state service. Which
-makes it difficult to follow the state lifecycle of each data type, and introduces uncertanty in how
-the data is accessed.
+makes it difficult to follow the state lifecycle of each data type, and introduces uncertainty in
+how the data is accessed.
 
 ## Decision Outcome
 
 We should refactor the state service to be a generic storage container.
 
 - Good: Eliminates the "good" functionality of the state service
 - Good: State is maintained by the service which owns it.
-- Good: No arbitary access of data.
-- Bad: Brings back arbitary keys that must be unique.
+- Good: No arbitrary access of data.
+- Bad: Brings back arbitrary keys that must be unique.
 
 ### Example
 

diff --git a/docs/architecture/adr/0005-refactor-api-service.md b/docs/architecture/adr/0005-refactor-api-service.md
@@ -14,7 +14,7 @@ tags: [clients, angular]
 The `ApiService` currently handles _all_ API requests. This has resulted in the class evolving into
 a Bloater, and as of right now consists of **2021** lines of code, and has **268** methods.
 Additionally, since it knows everything related to the servers it also needs to import every request
-and response which nessesates that the `ApiService` and request/responses are put in the same npm
+and response which necessitates that the `ApiService` and request/responses are put in the same npm
 package.
 
 ## Considered Options

diff --git a/docs/architecture/adr/0012-angular-filename-convention.md b/docs/architecture/adr/0012-angular-filename-convention.md
@@ -12,7 +12,7 @@ tags: [clients, angular]
 
 ## Context and Problem Statement
 
-We currently use a mixed filename convention where some files follows the Angular styleguide, and
+We currently use a mixed filename convention where some files follows the Angular style guide, and
 other files use camelCase. This causes some confusion as to which convention to follow, and we
 should standardize on one convention to avoid confusion.
 

diff --git a/docs/architecture/adr/0017-watchOS-use-swift.md b/docs/architecture/adr/0017-watchOS-use-swift.md
@@ -39,7 +39,7 @@ Chosen option: **Swift using SwiftUI**.
 - New tech stack to learn for the team
 - Even though we can debug the app properly we can't debug the iOS and the watchOS app at the same
   time (when debugging the watchOS app, a stub iOS app is installed on the iPhone so the original
-  one is overriden by the stub one)
+  one is overridden by the stub one)
 - Set up is harder given that we need to bundle the XCode built watchOS app into the Xamarin iOS app
   and update CI accordingly
 

diff --git a/docs/architecture/adr/0018-feature-management.md b/docs/architecture/adr/0018-feature-management.md
@@ -37,7 +37,7 @@ Chosen option: **Adopt a feature management system with local fallback**.
 
 ### Positive Consequences
 
-- Robust featureset for flags and their variations.
+- Robust feature set for flags and their variations.
 - Protection from changes and targeted impact, along with a speed in overall delivery (with managed
   functionality assumed to be turned "off").
 - Context-sensitive application of features.
@@ -50,7 +50,7 @@ Chosen option: **Adopt a feature management system with local fallback**.
 ### Plan
 
 The [server][server] codebase will adopt a .NET SDK for a service provider that offers feature
-management. Only the serverside SDK will be used to manage access and cost and feature states will
+management. Only the server-side SDK will be used to manage access and cost and feature states will
 be communicated down to calling clients where appropriate via API response elements. New features
 will be set up inside the service provider's platform, and changes to them will be streamed to the
 running applications. Access to the provider will be controlled internally.

diff --git a/docs/architecture/deep-dives/autofill/generating-fill-scripts.md b/docs/architecture/deep-dives/autofill/generating-fill-scripts.md
@@ -13,7 +13,7 @@ the next step is to generate what we call a "fill script". A fill script is a se
 instructions that tell the `autofill.js` content script what fields to fill and with what data it
 should fill each field.
 
-The generation of fill scripts is the responsiblity of the
+The generation of fill scripts is the responsibility of the
 [`AutofillService`](https://github.com/bitwarden/clients/blob/master/apps/browser/src/autofill/services/autofill.service.ts).
 There are three method used to perform fill script generation:
 

diff --git a/docs/architecture/deep-dives/autofill/shadow-dom.md b/docs/architecture/deep-dives/autofill/shadow-dom.md
@@ -45,7 +45,8 @@ If the node is a shadow root, we try to recursively descend into it using the br
 - **Firefox: **
   [Element.openOrClosedShadowRoot](https://developer.mozilla.org/en-US/docs/Web/API/Element/openOrClosedShadowRoot) -
   ignores the `mode` property and works for open and closed shadow roots
-- **Safari and others: **
+- **Safari and others:**
+
   [Element.shadowRoot](https://developer.mozilla.org/en-US/docs/Web/API/Element/shadowRoot) -
   respects the `mode` property and will only work for `"open"` shadow roots. We fall back to this
   method if the other APIs are not available
diff --git a/docs/architecture/deep-dives/push-notifications/non-mobile.md b/docs/architecture/deep-dives/push-notifications/non-mobile.md
@@ -7,7 +7,7 @@ for real-time client communication over WebSockets.
 ## Server Implementations
 
 When real-time changes must be communicated to the registered non-mobile clients, it is the
-responsibiity of the Bitwarden API for their configured server instance to distribute the
+responsibility of the Bitwarden API for their configured server instance to distribute the
 information. The server abstracts this with the
 [`IPushNotificationService`](https://github.com/bitwarden/server/blob/master/src/Core/Services/IPushNotificationService.cs)
 interface, which has different implementations based on whether the instance is cloud-hosted or
@@ -85,5 +85,5 @@ Bitwarden API submits the notifications directly to the self-hosted Notification
 
 When a non-mobile client starts and the user is authenticated, it initiates a WebSocket connection
 to the Notification service (`/notifications/hub`) for their configured server instance. This
-request includes their JWT `bearer` token, which is used to retreive the user ID, which in turn
+request includes their JWT `bearer` token, which is used to retrieve the user ID, which in turn
 determines which notifications the user receives.
diff --git a/docs/architecture/mobile-clients/index.mdx b/docs/architecture/mobile-clients/index.mdx
@@ -14,7 +14,7 @@ Principal structure is a follows:
 - `App`: Shared code that focus on the presentation layer of the app and some business logic as
   well.
 - `Android`: All the code specific to the Android platform
-- `iOS`: All the code speicific to the iOS platform
+- `iOS`: All the code specific to the iOS platform
 - `iOS.Core`: Shared code used by the iOS app and its extensions
 - `iOS.Autofill`: iOS extension that handles Autofill
 - `iOS.Extensions`: iOS extension that handles Autofill from the bottom sheet extension

diff --git a/docs/architecture/mobile-clients/watchOS.md b/docs/architecture/mobile-clients/watchOS.md
@@ -12,7 +12,7 @@ The watchOS application is organized as follows:
 So almost all the things related to the watch app will be in the **WatchKit Extension**, the
 WatchKit App one will be only for assets and some configs.
 
-Then in the Extension we have a layered architecure:
+Then in the Extension we have a layered architecture:
 
 - State (it's a really simplified version of the iOS state)
 - Persistence (here we use `CoreData` to interact with the Database)
@@ -86,7 +86,7 @@ is used given that it always have the latest data sent available, it's sent in t
 the counterpart device doesn't necessarily needs to be in range (so it's cached until it can be
 delivered). Additionally,
 [sendMessage](https://developer.apple.com/documentation/watchconnectivity/wcsession/1615687-sendmessage)
-is also used to signal the counterpart of some action to take fastly (like triggering a sync from
+is also used to signal the counterpart of some action to take quickly (like triggering a sync from
 the Watch).
 
 The `WatchDTO` is the object that is sent in the synchronization that has all the information for

diff --git a/docs/contributing/accessibility/accessibility.mdx b/docs/contributing/accessibility/accessibility.mdx
@@ -28,7 +28,7 @@ Additional resources on accessibility at Bitwarden can be found on
 | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | [1.4.3 Contrast minimum](https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html)<br/><br/>[1.4.11 Non-text contrast](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html) | Content should have contrast meeting or exceeding the WCAG AA guidelines:<br/>&nbsp;&nbsp;- For normal text: 4.5:1<br/>&nbsp;&nbsp;- For large text and graphics: 3:1<br/>&nbsp;&nbsp;- Use the [WebAIM contrast checker](https://webaim.org/resources/contrastchecker/) to learn more.<br/>&nbsp;&nbsp;- When using variables from the Component Library, the `text-main` variable is tested on `background` and `background-alt` variables. All other backgrounds generally use `text-contrast`. |
 | [1.4.13 Content on Hover of focus](https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html)                                                                                      | **Bitwarden design best practice:** Interactive elements should always be visible without a user needing to hover or focus that element. This allows content to be more discoverable and thus accessible to users, while also eliminating the complexity necessary to implement such a pattern to meet WCAG criteria.                                                                                                                                                                              |
-| [2.4.7 Focus visible](https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html)                                                                                                               | **Bitwarden design best practice:** All interactive elements should have visible focus, hover states, and the correct cursor stying.                                                                                                                                                                                                                                                                                                                                                               |
+| [2.4.7 Focus visible](https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html)                                                                                                               | **Bitwarden design best practice:** All interactive elements should have visible focus, hover states, and the correct cursor styling.                                                                                                                                                                                                                                                                                                                                                              |
 |                                                                                                                                                                                                     | **Bitwarden design best practice:** Icons and text that is shortened should always have a `title` attribute to provide additional context.                                                                                                                                                                                                                                                                                                                                                         |
 
 ## Keyboard Navigation

diff --git a/docs/contributing/code-style/sql.md b/docs/contributing/code-style/sql.md
@@ -170,7 +170,7 @@ GO
 ### Create or Modify an Index
 
 When creating indexes, especially on heavily used tables, our production database can easily become
-offline, unusuable, hit 100% CPU and many other bad behaviors. It is often best to do this using
+offline, unusable, hit 100% CPU and many other bad behaviors. It is often best to do this using
 online index builds so as not to lock the underlying table. This may cause the index operation to
 take longer, but you will not create an underlying schema table lock which prevents all reads and
 connections to the table and instead only locks the table of updates during the operation.

diff --git a/docs/contributing/database-migrations/edd.mdx b/docs/contributing/database-migrations/edd.mdx
@@ -201,7 +201,7 @@ Create a PR moving the future scripts.
 ## Rollbacks
 
 In the event the server release failed and needs to be rolled back, it should be as simple as just
-re-deploying the previous version again. The database will **stay** in the transition phase untill a
+re-deploying the previous version again. The database will **stay** in the transition phase until a
 hotfix can be released, and the server can be updated.
 
 The goal is to resolve the issue quickly and re-deploy the fixed code to minimize the time the

diff --git a/docs/contributing/database-migrations/index.md b/docs/contributing/database-migrations/index.md
@@ -27,8 +27,8 @@ Style][code-style-sql] first, since they have a major impact in how we write mig
 
 :::
 
-In accordinance with the tenets of [Evolutionary Database Design](./edd.mdx), each change needs to
-be considered to be split into two parts:
+In accordance with the tenets of [Evolutionary Database Design](./edd.mdx), each change needs to be
+considered to be split into two parts:
 
 1. A backwards-compatible transition migration
 2. A non-backwards-compatible final migration

diff --git a/docs/contributing/index.md b/docs/contributing/index.md
@@ -16,11 +16,11 @@ Here is how you can get involved:
 - **Request a new feature:** Go to the
   [Feature Requests category](https://community.bitwarden.com/c/feature-requests/) of the Community
   Forums. Please search existing feature requests before making a new one
-- **Write code for a new feature:** Create a new
-  [Github Discussions](https://github.com/orgs/bitwarden/discussions) post outlining your proposal.
-  Include a description of your proposed contribution, screenshots, and links to any relevant
-  [feature requests](https://community.bitwarden.com/c/feature-requests/5/none). This helps get
-  feedback from the community and Bitwarden team members before you start writing code
+- **Write code for a new feature:** Make a new post in the
+  [Github Contributions category](https://community.bitwarden.com/c/github-contributions/) of the
+  Community Forums. Include a description of your proposed contribution, screenshots, and links to
+  any relevant feature requests. This helps get feedback from the community and Bitwarden team
+  members before you start writing code
 - **Report a bug or submit a bugfix:** Use Github issues and pull requests
 - **Help other users:** Go to the
   [Ask the Bitwarden Community category](https://community.bitwarden.com/c/support/) on the

diff --git a/docs/getting-started/clients/desktop/index.mdx b/docs/getting-started/clients/desktop/index.mdx
@@ -54,7 +54,7 @@ npm run build
 
 In certain environments such as WSL (Windows Subsystem for Linux), it might be necessary to
 cross-compile the native module. To do this, first make sure you have installed the relevant rust
-target. See [rustup documentation](https://rust-lang.github.io/rustup/cross-compilation.html) for
+target. See [`rustup` documentation](https://rust-lang.github.io/rustup/cross-compilation.html) for
 more information.
 
 ```bash

diff --git a/docs/getting-started/clients/desktop/native-messaging-test-runner.md b/docs/getting-started/clients/desktop/native-messaging-test-runner.md
@@ -39,7 +39,7 @@ there. You will need to set up your accounts and vaults beforehand to test these
 
 ### Commands
 
-The commands folder contains the runable node scripts/commands. There is currently one file per
+The commands folder contains the executable node scripts/commands. There is currently one file per
 native messaging command for testing.
 
 1. **`handshake`** Sends a `bw-handshake` command and establishes communication with the native
@@ -86,15 +86,15 @@ socket.
 ### NativeMessageService
 
 This service uses the IPCService to connect to the locally running Bitwarden desktop app's IPC proxy
-service. It uses Bitwarden's crypto service and functions to handle encrytption and decryption of
-the messages. It utilizes a test public/private key pair located in the
+service. It uses Bitwarden's crypto service and functions to handle encryption and decryption of the
+messages. It utilizes a test public/private key pair located in the
 `/native-messaging-test-runner/src/variables.ts` file.
 
 ### Other
 
 #### I thought Node used JavaScript? How are we using TypeScript classes, including the ones from libs?
 
-Great question! With a little magic✨ we are compiling these TypeSript files into the JavaScript
+Great question! With a little magic✨ we are compiling these TypeScript files into the JavaScript
 that Node knows and loves. This is done is with a couple of mechanisms:
 
 - **`tsconfig.json`:** In the `paths` node of this file, the files in the paths provided are