Throw exception for common field type misconfiguration

docs/en/configuration.md

@@ -18,6 +18,11 @@ SilverStripe\Forager\Service\IndexConfiguration:
             title:
               property: Title
             content: true
+            term_ids:
+              property: Terms.ID
+              options:
+                type: number
+
 ```
 
 Let's look at each relevant node:
@@ -45,6 +50,14 @@ resolver within `DataObjectDocument` is smart enough to resolve inconsistencies
 so when it finds that the property `$content` doesn't exist on the `SiteTree` instance, it
 will use a case matching strategy as a fallback.
 
+* `term_ids`:
+
+  * `property: Terms.ID`: This shorthand only works for DataObjects. Where `Terms` is a `has_many` (or `many_many`)
+  relationship, using `Terms.ID` will result in your receiving an array of IDs from each related DataObject (in this
+  example, that would be the ID of each related `TaxonomyTerm`)
+  * `options.type: number`: This is how you can define the field type for your field. Note: What field types are valid
+  will depend on what service you are integrating with
+
 It is important to note that the keys of `fields` can be named anything you like, so long
 as it is valid in your search service provider (for EnterpriseSearch, that's all lowercase and 
 underscores). There is no reason why `title` cannot be `document_title` for instance,

src/Service/IndexConfiguration.php

@@ -7,6 +7,7 @@
 use SilverStripe\Core\Extensible;
 use SilverStripe\Core\Injector\Injectable;
 use SilverStripe\Forager\DataObject\DataObjectDocument;
+use SilverStripe\Forager\Exception\IndexConfigurationException;
 use SilverStripe\Forager\Interfaces\DocumentInterface;
 use SilverStripe\Forager\Schema\Field;
 
@@ -247,11 +248,22 @@ public function getFieldsForClass(string $class): ?array
                         continue;
                     }
 
-                    $config = (array)$data;
+                    $fieldConfig = (array) $data;
+                    // This is a callout to a common misconfiguration that will result in developers receiving an
+                    // unexpected field type. The correct yaml format is for this to be part of the "options" object
+                    $invalidTypeField = $fieldConfig['type'] ?? null;
+
+                    if ($invalidTypeField) {
+                        throw new IndexConfigurationException(
+                            'Field configuration for "type" should be defined under the "options" object.'
+                            . ' Please see configuration.md#basic-configuration for an example.'
+                        );
+                    }
+
                     $fieldObjs[$searchName] = new Field(
                         $searchName,
-                        $config['property'] ?? null,
-                        $config['options'] ?? []
+                        $fieldConfig['property'] ?? null,
+                        $fieldConfig['options'] ?? []
                     );
                 }
             }