From 79bd348585f3abf9d814dccb0dbfed94044293f9 Mon Sep 17 00:00:00 2001
From: Ford <153042616+guerrierindien@users.noreply.github.com>
Date: Wed, 13 Dec 2023 17:33:20 +0100
Subject: [PATCH] chore(docs): typo fixes (#3051)

---
 .../infra/src/infrastructure/external-secrets/helm/README.md    | 2 +-
 typescript/infra/src/utils/gcloud.ts                            | 2 +-
 typescript/infra/src/utils/utils.ts                             | 2 +-
 typescript/sdk/src/ism/types.ts                                 | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/typescript/infra/src/infrastructure/external-secrets/helm/README.md b/typescript/infra/src/infrastructure/external-secrets/helm/README.md
index b407dc84ec..4e6670b84d 100644
--- a/typescript/infra/src/infrastructure/external-secrets/helm/README.md
+++ b/typescript/infra/src/infrastructure/external-secrets/helm/README.md
@@ -19,7 +19,7 @@ As of now, the GCP service account that's used by the ClusterSecretStore to acce
 
 GCP service account credentials are static and long-living, which is really unattractive. The leading alternative is workload identity, which doesn't require static and long-living credentials. For now, the GCP service account approach was used for the following reasons:
 
-1. The existing mainnet cluster does not support workload identity. It doesn't seem like a big lift to change the cluster to support workload identity, but it was desireable to avoid a disruption by making large changes to the infrastructure.
+1. The existing mainnet cluster does not support workload identity. It doesn't seem like a big lift to change the cluster to support workload identity, but it was desirable to avoid a disruption by making large changes to the infrastructure.
 2. Workload identity has some less-than-attractive features, like [identity sameness](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity), which essentially requires putting sensitive workloads in their own GCP project.
 
 Regardless, workload identities are a more attractive long-term option, and moving to them should be relatively easy.
diff --git a/typescript/infra/src/utils/gcloud.ts b/typescript/infra/src/utils/gcloud.ts
index c5354875aa..ef2650d357 100644
--- a/typescript/infra/src/utils/gcloud.ts
+++ b/typescript/infra/src/utils/gcloud.ts
@@ -164,7 +164,7 @@ async function createServiceAccount(serviceAccountName: string) {
 
 async function getServiceAccountInfo(serviceAccountName: string) {
   // By filtering, we get an array with one element upon a match and an empty
-  // array if there is not a match, which is desireable because it never errors.
+  // array if there is not a match, which is desirable because it never errors.
   const matches = await execCmdAndParseJson(
     `gcloud iam service-accounts list --format json --filter displayName="${serviceAccountName}"`,
   );
diff --git a/typescript/infra/src/utils/utils.ts b/typescript/infra/src/utils/utils.ts
index 1145086e97..003cfed145 100644
--- a/typescript/infra/src/utils/utils.ts
+++ b/typescript/infra/src/utils/utils.ts
@@ -69,7 +69,7 @@ export function getEthereumAddress(publicKey: Buffer): string {
   pubKeyBuffer = pubKeyBuffer.slice(1, pubKeyBuffer.length);
 
   const address = ethers.utils.keccak256(pubKeyBuffer); // keccak256 hash of publicKey
-  const EthAddr = `0x${address.slice(-40)}`; // take last 20 bytes as ethereum adress
+  const EthAddr = `0x${address.slice(-40)}`; // take last 20 bytes as ethereum address
   return EthAddr;
 }
 
diff --git a/typescript/sdk/src/ism/types.ts b/typescript/sdk/src/ism/types.ts
index e9d222bfc1..86023080c3 100644
--- a/typescript/sdk/src/ism/types.ts
+++ b/typescript/sdk/src/ism/types.ts
@@ -33,7 +33,7 @@ export enum IsmType {
   TEST_ISM = 'testIsm',
 }
 
-// mapping betweent the two enums
+// mapping between the two enums
 export function ismTypeToModuleType(ismType: IsmType): ModuleType {
   switch (ismType) {
     case IsmType.OP_STACK: