Add documentation

docs/features.md

@@ -1,9 +1,70 @@
 Features
 ========
 
+`packages` configuration
+------------------------
+:octicons-tag-24: 2.21.0 · :material-test-tube: Alpha Feature
+
+Mockery has a configuration parameter called `packages`. This config represents a huge paradigm shift that is highly recommended for the large amount of flexibility it grants you.
+
+In this config section, you define the packages and the intefaces you want mocks generated for. The packages can be any arbitrary package, either your own project or anything within the Go ecosystem. You may provide package-level or interface-level overrides to the default config you provide.
+
+Usage of the `packages` config section is desirable for mutiple reasons:
+
+1. Up to 5x increase in mock generation speed over the legacy method
+2. Granular control over interface generation, location, and file names
+3. Singular location for all config, instead of spread around by `//go:generate` statements
+4. Clean, easy to understand.
+
+### Examples
+
+Here is an example configuration set:
+
+```yaml
+keeptree: True
+with-expecter: True
+packages:
+  github.com/vektra/mockery/v2/pkg: # (1)!
+    interfaces:
+      TypesPackage:
+  io:
+    config:
+      all: True # (2)!
+    interfaces:
+      Writer:
+        config:
+          with-expecter: False # (3)!
+```
+
+1.  For this package, we provide no package-level config (which means we inherit the deafults at the top-level). Since our default of `all:` is `False`, mockery will only generate the interfaces we specify. We tell it which interface to generate by using the `interfaces` section and specifying an empty map, one for each interface.
+2. This is telling mockery to generate _all_ interfaces in the `io` package.
+3. We can provide interface-specifc overrides to the generation config.
+
+### Templated directory and filenames
+
+Included with this feature is the ability to use templated strings for the destination directory and filenames of the generated mocks.
+
+The default parameters are:
+
+```yaml title="Defaults"
+filename: "mock_{{.InterfaceName}}.go"
+dir: "mocks/{{.PackagePath}}"
+```
+
+The template variables available for your use are:
+
+| name | description |
+|------|-------------|
+| InterfaceName | The name of the original interface being mocked |
+| PackageName | The name of the package from the original interface |
+| Package Path | The fully qualified package path of the original interface |
+| MockName | The name of the generated mock |
+
 Mock Constructors
 -----------------
 
+:octicons-tag-24: 2.11.0
+
 All mock objects have constructor functions. These constructors do basic test setup so that the expectations you set in the code are asserted before the test exist.
 
 Previously something like this would need to be done:
@@ -26,8 +87,7 @@ The constructor sets up common functionalities automatically
 Expecter Structs
 ----------------
 
-|config|`with-expecter: True`|
-|-|-|
+:octicons-tag-24: 2.10.0 · `with-expecter: True`
 
 Mockery now supports an "expecter" struct, which allows your tests to use type-safe methods to generate call expectations. When enabled through the `with-expecter: True` mockery configuration, you can enter into the expecter interface by simply calling `.EXPECT()` on your mock object.
 
@@ -63,6 +123,8 @@ requesterMock.EXPECT().
 Return Value Providers
 ----------------------
 
+:octicons-tag-24: 2.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:
 
 ```go

mkdocs.yml

@@ -22,6 +22,7 @@ theme:
         icon: material/brightness-4
         name: Switch to light mode
   features:
+    - content.code.annotate
     - content.code.copy
     - content.action.edit
     - content.action.view
@@ -35,6 +36,9 @@ markdown_extensions:
   - admonition
   - attr_list
   - md_in_html
+  - pymdownx.emoji:
+      emoji_index: !!python/name:materialx.emoji.twemoji
+      emoji_generator: !!python/name:materialx.emoji.to_svg
   - pymdownx.highlight:
       anchor_linenums: true
       auto_title: true
@@ -52,10 +56,10 @@ nav:
     - Running: running.md
     - Using Mocks:
       - Examples: examples.md
-  - Features:
-    - Changelog: changelog.md
-    - Features: features.md
+  - Features: features.md
+  - Notes: 
     - Additional Notes: notes.md
+    - Changelog: changelog.md
 
 extra_css:
   - stylesheets/extra.css