Merge pull request #794 from ccoVeille/typos-suggestion

chore: fix typos and style

Author: LandonTClipp

.github/ISSUE_TEMPLATE.md

@@ -1,7 +1,7 @@
 PLEASE READ
 -------------
 
-DO NOT submit tickets without _first_ using the latest version of Golang, clearing your local golang package cache, and re-building mockery using the _latest_ Golang version and the _latest_ version of mockery. Please provide evidence this has been done in your issue. Failure to provide this evidence will likely result in your issue being closed.
+DO NOT submit tickets without _first_ using the latest version of Go, clearing your local golang package cache, and re-building mockery using the _latest_ Go version and the _latest_ version of mockery. Please provide evidence this has been done in your issue. Failure to provide this evidence will likely result in your issue being closed.
 
 Description
 -------------
@@ -13,7 +13,7 @@ Mockery Version
 
 [version of mockery being used]
 
-Golang Version
+Go Version
 --------------
 
 [version of golang being used]

.github/PULL_REQUEST_TEMPLATE.md

@@ -12,7 +12,7 @@ Please include a summary of the changes and the related issue. Please also inclu
 - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
 - [ ] This change requires a documentation update
 
-Version of Golang used when building/testing:
+Version of Go used when building/testing:
 ---------------------------------------------
 
 - [ ] 1.11

docs/configuration.md

@@ -81,7 +81,7 @@ Parameter Descriptions
 | [`recursive`](features.md#recursive-package-discovery) | :fontawesome-solid-x:     | `#!yaml false`                        | When set to `true` on a particular package, mockery will recursively search for all sub-packages and inject those packages into the config map.                                                                                                      |
 | [`replace-type`](features.md#replace-types)            | :fontawesome-solid-x:     | `#!yaml null`                         | Replaces aliases, packages and/or types during generation.                                                                                                                                                                                           |
 | `tags`                                                 | :fontawesome-solid-x:     | `#!yaml ""`                           | A space-separated list of additional build tags to load packages.                                                                                                                                                                                                                |
-| [`with-expecter`](features.md#expecter-structs)        | :fontawesome-solid-x:     | `#!yaml true`                         | Use `with-expecter: True` to generate `EXPECT()` methods for your mocks. This is the preferred way to setup your mocks.                                                                                                                              |
+| [`with-expecter`](features.md#expecter-structs)        | :fontawesome-solid-x:     | `#!yaml true`                         | Use `with-expecter: True` to generate `EXPECT()` methods for your mocks. This is the preferred way to set up your mocks.                                                                                                                             |
 
 Layouts
 -------

docs/features.md

@@ -90,7 +90,7 @@ func (_m *Handler) HandleMessage(m pubsub.Message) error {
 }
 ```
 
-Generic type constraints can also be replaced by targeting the changed parameter with the square bracket notation on the left hand side.
+Generic type constraints can also be replaced by targeting the changed parameter with the square bracket notation on the left-hand side.
 
 ```shell
 mockery --replace-type github.com/vektra/mockery/v2/baz/internal/foo.InternalBaz[T]=github.com/vektra/mockery/v2/baz.Baz
@@ -233,12 +233,12 @@ packages:
       with-expecter: true
 ```
 
-You can use the `showconfig` command to see the config mockery injects. The output of `showconfig` theoretically could be copy-pasted into your yaml file as it is semantically equivalent.
+You can use the `showconfig` command to see the config mockery injects. The output of `showconfig` theoretically could be copy-pasted into your YAML file as it is semantically equivalent.
 
 mockery will _not_ recurse into submodules, i.e. any subdirectory that contains a go.mod file. You must specify the submodule as a separate line item in the config if you would like mocks generated for it as well.
 
 ??? note "performance characteristics"
-    The performance when using `#!yaml recursive: true` may be worse than manually specifying all packages statically in the yaml file. This is because of the fact that mockery has to recursively walk the filesystem path that contains the package in question. It may unnecessarily walk down unrelated paths (for example, a Python virtual environment that is in the same path as your package). For this reason, it is recommended _not_ to use `#!yaml recursive: true` if it can be avoided.
+    The performance when using `#!yaml recursive: true` may be worse than manually specifying all packages statically in the YAML file. This is because of the fact that mockery has to recursively walk the filesystem path that contains the package in question. It may unnecessarily walk down unrelated paths (for example, a Python virtual environment that is in the same path as your package). For this reason, it is recommended _not_ to use `#!yaml recursive: true` if it can be avoided.
 
 ### Regex matching
 
@@ -334,7 +334,7 @@ Return Value Providers
 
 :octicons-tag-24: v2.20.0
 
-Return Value Providers can be used one of two ways.  You may either define a single function with the exact same signature (number and type of input and return parameters) and pass that as a single value to `Return`, or you may pass multiple values to `Return` (one for each return parameter of the mocked function.)  If you are using the second form, for each of the return values of the mocked function, `Return` needs a function which takes the same arguments as the mocked function, and returns one of the return values. For example, if the return argument signature of `passthrough` in the above example was instead `(string, error)` in the interface, `Return` would also need a second function argument to define the error value:
+Return Value Providers can be used one of two ways. You may either define a single function with the exact same signature (number and type of input and return parameters) and pass that as a single value to `Return`, or you may pass multiple values to `Return` (one for each return parameter of the mocked function.)  If you are using the second form, for each of the return values of the mocked function, `Return` needs a function which takes the same arguments as the mocked function, and returns one of the return values. For example, if the return argument signature of `passthrough` in the above example was instead `(string, error)` in the interface, `Return` would also need a second function argument to define the error value:
 
 ```go
 type Proxy interface {

docs/index.md

@@ -25,7 +25,7 @@ func getFromDB(db DB) string {
 }
 ```
 
-You can test `getFromDB` by either instantiating a testing database, or you can simply create a mock implementation of `DB` using mockery. Mockery can autogenerate a mock implementation that allows us to define assertions on how the mock was used, what to return, and other useful tidbits. We can add a `//go:generate` directive above our interface:
+You can test `getFromDB` by either instantiating a testing database, or you can simply create a mock implementation of `DB` using mockery. Mockery can automatically generate a mock implementation that allows us to define assertions on how the mock was used, what to return, and other useful tidbits. We can add a `//go:generate` directive above our interface:
 
 ```golang title="db.go"
 //go:generate mockery --name DB

docs/migrating_to_packages.md

@@ -2,7 +2,7 @@
 title: Migrating To Packages
 ---
 
-The [packages](features.md#packages-configuration) feature is a new configuration scheme that aims to simplify and improve a lot of legacy behavior. This will be the only way to generate mocks in v3. These docs outline general principals for migrating to the new scheme.
+The [packages](features.md#packages-configuration) feature is a new configuration scheme that aims to simplify and improve a lot of legacy behavior. This will be the only way to generate mocks in v3. These docs outline general principles for migrating to the new scheme.
 
 Background
 ----------
@@ -29,7 +29,7 @@ All of the parameters in the config section can be specified at the top level of
 
 #### Separate `mocks/` directory
 
-Take for example a configuration where you are specifying `all: true` at the top of your repo and you're placing your mocks in a separate `mocks/` directory, mirroring the directory structure of your original repo.
+Take for example a configuration where you are specifying `all: true` at the top of your repo, and you're placing your mocks in a separate `mocks/` directory, mirroring the directory structure of your original repo.
 
 ```yaml
 testonly: False
@@ -53,7 +53,7 @@ packages:
       recursive: True
 ```
 
-1. The use of `replaceAll` is a trick that is done to ensure mocks created for `internal` packages can be imported outside of the mock directory. This retains the behavior of the legacy config.
+1. The use of `replaceAll` is a trick that is done to ensure mocks created for `internal` packages can be imported outside the mock directory. This retains the behavior of the legacy config.
 
 While the example config provided here is more verbose, that is because we're specifying many non-default values in order to retain strict equivalence for this example. It's recommended to refer to the [configuration parameters](configuration.md#parameter-descriptions) to see the defaults provided.
 
@@ -98,7 +98,7 @@ Previously, the recommended way of generating mocks was to call `mockery` once p
 Behavior Changes
 -----------------
 
-The legacy behavior iterated over every `.go` file in your project, called [`packages.Load`](https://pkg.go.dev/golang.org/x/tools/go/packages#Load) to parse the syntax tree, and generated mocks for every interface found in the file. The new behavior instead simply grabs the list of packages to load from the config file, or in the case of `#!yaml recursive: True`, walks the filesystem tree to discover the packages that exist (without actually parsing the files). Using this list, it calls `packages.Load` once with the list of packages that were discovered.
+The legacy behavior iterated over every `.go` file in your project, called [`packages.Load`](https://pkg.go.dev/golang.org/x/tools/go/packages#Load) to parse the syntax tree, and generated mocks for every interface found in the file. The new behavior instead simply grabs the list of packages to load from the config file, or in the case of `#!yaml recursive: True`, walks the file-system tree to discover the packages that exist (without actually parsing the files). Using this list, it calls `packages.Load` once with the list of packages that were discovered.
 
 Filesystem Tree Layouts
 ------------------------

docs/notes.md

@@ -26,7 +26,7 @@ Additionally, this issue only happens when compiling mockery from source, such a
 Multiple Expectations With Identical Arguments
 -----------------------------------------------
 
-There might be instances where you want a mock to return different values on successive calls that provide the same arguments. For example we might want to test this behavior:
+There might be instances where you want a mock to return different values on successive calls that provide the same arguments. For example, we might want to test this behavior:
 
 ```go
 // Return "foo" on the first call
@@ -37,7 +37,7 @@ assert(t, "foo", getter.Get("key"))
 assert(t, "bar", getter.Get("key"))
 ```
 
-This can be done by using the `.Once()`  method on the mock call expectation:
+This can be done by using the `.Once()` method on the mock call expectation:
 
 ```go
 mockGetter := NewMockGetter(t)
@@ -53,7 +53,7 @@ mockGetter.EXPECT().Get(mock.anything).Return("foo").Times(4)
 mockGetter.EXPECT().Get(mock.anything).Return("bar").Times(2)
 ```
 
-Note that with proper Golang support in your IDE, all of the available methods are self-documented in auto-completion help contexts.
+Note that with proper Go support in your IDE, all the available methods are self-documented in autocompletion help contexts.
 
 Variadic Arguments
 ------------------
@@ -113,14 +113,14 @@ Semantic Versioning
 The versioning in this project applies only to the behavior of the mockery binary itself. This project explicitly does not promise a stable internal API, but rather a stable executable. The versioning applies to the following:
 
 1. CLI arguments.
-2. Parsing of Golang code. New features in the Golang language will be supported in a backwards-compatible manner, except during major version bumps.
+2. Parsing of Go code. New features in the Go language will be supported in a backwards-compatible manner, except during major version bumps.
 3. Behavior of mock objects. Mock objects can be considered to be part of the public API.
 4. Behavior of mockery given a set of arguments.
 
 What the version does _not_ track:
 
 1. The interfaces, objects, methods etc. in the vektra/mockery package.
-2. Compatibility of `go get`-ing mockery with new or old versions of Golang.
+2. Compatibility of `go get`-ing mockery with new or old versions of Go.
 
 Mocking interfaces in `main`
 ----------------------------
@@ -135,4 +135,4 @@ This issue was first highlighted [in this GitHub issue](https://github.com/vektr
 
 mockery uses the viper package for configuration mapping and parsing. Viper is set to automatically search for all config variables specified in its config struct. One of the config variables is named `version`, which gets mapped to an environment variable called `MOCKERY_VERSION`. If you set this environment variable, mockery attempts to parse it into the `version` bool config.
 
-This is an unintended side-effect of how our config parsing is set up. The solution is to rename your environment variable to something other than `MOCKERY_VERSION`.
+This is an adverse effect of how our config parsing is set up. The solution is to rename your environment variable to something other than `MOCKERY_VERSION`.

docs/running.md

@@ -18,7 +18,7 @@ packages:
 # Lots more config...
 ```
 
-From anywhere within your repo, you can simply call `mockery` once and it will find your config either by respecting the `#!yaml config` path you gave it, or by searching upwards from the current working directory.
+From anywhere within your repo, you can simply call `mockery` once, and it will find your config either by respecting the `#!yaml config` path you gave it, or by searching upwards from the current working directory.
 
 ```bash
 mockery