Fixed Typos and Corrections

apps/mobile/src/features/deepLinking/README.md

@@ -1,6 +1,6 @@
 # Universal Links
 
-Universal links allow 3rd parties to prompt the app to open to specific screens when it is installed on their device. If the app isn't installed it will open that page in Safari (a 404 on uniswap.org in this case). All universal links must use the the prefix `https://uniswap.org/app`.
+Universal links allow 3rd parties to prompt the app to open to specific screens when it is installed on their device. If the app isn't installed it will open that page in Safari (a 404 on uniswap.org in this case). All universal links must use the prefix `https://uniswap.org/app`.
 
 ## Supported Screens
 

apps/mobile/src/features/forceUpgrade/README.md

@@ -1,7 +1,7 @@
 # Force Upgrade
 
 The ability of having users force upgrading our app allows us to stop critical UX and security bugs from reaching a wide audience.
-By defining a mininum version all users need to be in, this component will block usage of the app and redirect users to the app store for
+By defining a minimum version all users need to be in, this component will block usage of the app and redirect users to the app store for
 upgrading the app.
 
 ## Schema

apps/mobile/src/stories/README.md

@@ -44,7 +44,7 @@ yarn storybook
 
 ## Chromatic
 
-Chromatic is a cloud service build for Storybook. It allows running visual tests with zero-config.
+Chromatic is a cloud service built for Storybook. It allows running visual tests with zero-config.
 
 Chromatic is set up to build and publish our Storybook for each PR. ([example build](https://www.chromatic.com/build?appId=61d89aa649fc7d003ae21c76&number=25)).
 
@@ -61,7 +61,7 @@ Storybook inside `@uniswap/mobile` is still experimental. Feel free to modify th
 
 ### To research
 
-- Accessability tests
+- Accessibility tests
 - Interaction tests
 
 ### Addons

apps/web/functions/README.md

@@ -9,7 +9,7 @@ These functions utilize Cloudflare Functions to dynamically inject meta tags ser
 Currently, there are 2 types of cloudflare functions developed
 
 - Meta Data Injectors - Workers that inject [Open Graph](https://ogp.me/) standardized meta tags into the `header` of specific webpages.
-  - Currently we support this functionaltiy for three separate webpages: NFT Assets, NFT Collections, and Token Detail Pages
+  - Currently we support this functionality for three separate webpages: NFT Assets, NFT Collections, and Token Detail Pages
   - These functions query data from GraphQL and then formats them into HTML `meta` tags to be injected
 - Dynamically Generated Images - Utilizes Vercel's [Open Graph Image Generation Library](https://vercel.com/docs/concepts/functions/edge-functions/og-image-generation) to create custom thumbnails for specific webpages
   - Currently supports NFT Assets, NFT Collections, and Token Detail Pages
@@ -25,7 +25,7 @@ Testing is done utilizing a custom jest environment as well as Cloudflare's loca
 
 ## Deployment
 
-Functions will be deployed to Cloudlfare where they will be ran automatically when the appropriate route is hit.
+Functions will be deployed to Cloudflare where they will be run automatically when the appropriate route is hit.
 
 ## Miscellaneous
 
@@ -39,7 +39,7 @@ Functions will be deployed to Cloudlfare where they will be ran automatically wh
   - `--proxy:3001`: telling the proxy to listen on port 3001
   - `--port=3000`: telling wrangler to run our proxy on port 3000
   - `NODE_OPTIONS=--dns-result-order=ipv4first`: wrangler still serves to IPv4 which isn't compatible with Node 18 which default resolves to IPv6 so we need to specify to serve to IPv4
-  - `PORT-3001 --yarn start`: runs default yarn start on port 3001
+  - `PORT=3001 --yarn start`: runs default yarn start on port 3001
     - when exiting Miniflare, may need to clean up process on port 3001 separately: `kill $(lsof -t -i:3001)`
 - `yarn test:cloud` (NODE_OPTIONS=--experimental-vm-modules yarn jest functions --watch --config=functions/jest.config.json), script to test cloud functions with jest
 

packages/utilities/src/logger/README.md

@@ -5,7 +5,7 @@
 If you're manually logging an error, make sure you log an actual error object and not just a string.
 
 Don't use: `logger.error('Invalid input')`
-Do use: `logger.error(new Error('Invalid input')`
+Do use: `logger.error(new Error('Invalid input'))`
 
 The reason is that new Error() makes it so that Sentry knows exactly where this was called. Otherwise, the stack trace is useless.
 

packages/wallet/src/test/README.md

@@ -15,7 +15,7 @@ This directory contains fixtures, mocks and utilities useful while writing tests
 
 ### 1.2. mocks
 
-- Contains all mocks (i.e. mocked providers, resolvers, default values for non-mocked graphql resolvers, etc.). In short, all mocks that aren't just simple objects with primitive values (or values with nested objects) should be located in this ditectory.
+- Contains all mocks (i.e. mocked providers, resolvers, default values for non-mocked graphql resolvers, etc.). In short, all mocks that aren't just simple objects with primitive values (or values with nested objects) should be located in this directory.
 
 ## 2. Usage
 
@@ -129,7 +129,7 @@ To mock query resolvers in tests we can use the helper function `queryResolvers`
 
 The usage of the `queryResolvers` function is not mandatory, because we can mock resolvers without this function, but it has a few benefits:
 
-1. In cases where queries select only a subset of document fields (e.g. `address` and `id` from the `Token` type without other properties, such as `chain`, etc.), it will automatically filter out unnecessary fields from the query response and we will get the object of shape exactly the same as specified in the query document. Without the usage of the `queryResolvers` function, responses will contain all fields of the fixture we returned from our custom resolvers, which lead to unpredictible results in some tests.
+1. In cases where queries select only a subset of document fields (e.g. `address` and `id` from the `Token` type without other properties, such as `chain`, etc.), it will automatically filter out unnecessary fields from the query response and we will get the object of shape exactly the same as specified in the query document. Without the usage of the `queryResolvers` function, responses will contain all fields of the fixture we returned from our custom resolvers, which lead to unpredictable results in some tests.
 2. It makes it possible to access values returned from resolvers. This is especially useful, when queries select specific fields and we want to expect test result based on what was returned from the resolver (not based on the fixture with all fields, some of which weren't present in the query response),
 3. The writing of custom resolvers in tests is cleaner with `queryResolvers` and requires less code (no need to create `Query` object with resolvers, we can pass just resolvers without the `Query` object)