docs: update docs with component path / client config changes (#7657)

docs/admin/fields.mdx

@@ -214,7 +214,7 @@ The exact shape of this prop is unique to the specific [Field Type](../fields/ov
 import React from 'react'
 import type { TextFieldProps } from 'payload'
 
-export const MyClientFieldComponent: TextFieldProps = ({ field: { name } }) => {
+export const MyClientFieldComponent: React.FC<TextFieldProps> = ({ field: { name } }) => {
   return (
     <p>
       {`This field's name is ${name}`}
@@ -266,6 +266,12 @@ import type {
 } from 'payload'
 ```
 
+When working on the client, you will never have access to objects of type `Field`. This is reserved for the server-side. Instead, you can use `ClientField` which is a union type of all the client fields:
+
+```tsx
+import type { ClientField } from 'payload'
+```
+
 ### The Cell Component
 
 The Cell Component is rendered in the table of the List View. It represents the value of the field when displayed in a table cell.

docs/admin/hooks.mdx

@@ -74,9 +74,9 @@ type FieldType<T> = {
 
 ## useFieldProps
 
-All [Custom Field Components](./fields#the-field-component) are rendered on the server, and as such, only have access to static props at render time. But, some fields can be dynamic, such as when nested in an [`array`](../fields/array) or [`blocks`](../fields/block) field. For example, items can be added, re-ordered, or deleted on-the-fly.
+[Custom Field Components](./fields#the-field-component) can be rendered on the server. When using a server component as a custom field component, you can access dynamic props from within any client component rendered by your custom server component. This is done using the `useFieldProps` hook. This is important because some fields can be dynamic, such as when nested in an [`array`](../fields/array) or [`blocks`](../fields/block) field. For example, items can be added, re-ordered, or deleted on-the-fly.
 
-For this reason, dynamic props like `path` are managed in their own React context, which can be accessed using the `useFieldProps` hook:
+You can use the `useFieldProps` hooks to access dynamic props like `path`:
 
 ```tsx
 'use client'

docs/admin/overview.mdx

@@ -191,6 +191,55 @@ When constructing the `ClientConfig`, Payload uses the component paths as keys t
 
 Import maps are regenerated whenever you modify any element related to component paths. This regeneration occurs at startup and whenever Hot Module Replacement (HMR) runs. If the import maps fail to regenerate during HMR, you can restart your application and execute the `payload generate:importmap` command to manually create a new import map.
 
+### Component paths in external packages
+
+Component paths are resolved relative to your project's base directory, which is either your current working directory or the directory specified in `config.admin.baseDir`. When using custom components from external packages, you can't use relative paths. Instead, use an import path that's accessible as if you were writing an import statement in your project's base directory.
+
+For example, to export a field with a custom component from an external package named `my-external-package`:
+
+```ts
+import type { Field } from 'payload'
+export const MyCustomField: Field = {
+  type: 'text',
+  name: 'MyField',
+  admin: {
+    components: {
+      Field: 'my-external-package/client#MyFieldComponent'
+    }
+  }
+}
+```
+
+Despite `MyFieldComponent` living in `src/components/MyFieldComponent.tsx` in `my-external-package`, this will not be accessible from the consuming project. Instead, we recommend exporting all custom components from one file in the external package. For example, you can define a `src/client.ts file in `my-external-package`:
+
+```ts
+'use client'
+export { MyFieldComponent } from './components/MyFieldComponent'
+```
+
+Then, update the package.json of `my-external-package:
+
+```json
+{
+...
+  "exports": {
+    "./client": {
+        "import": "./dist/client.js",
+        "types": "./dist/client.d.ts",
+        "default": "./dist/client.js"
+    }
+  }
+}
+```
+
+This setup allows you to specify the component path as `my-external-package/client#MyFieldComponent` as seen above. The import map will generate:
+
+```ts
+import { MyFieldComponent } from 'my-external-package/client'
+```
+
+which is a valid way to access MyFieldComponent that can be resolved by the consuming project.
+
 ## Admin Options
 
 All options for the Admin Panel are defined in your [Payload Config](../configuration/overview) under the `admin` property:

docs/local-api/overview.mdx

@@ -62,19 +62,16 @@ If you are accessing Payload via function arguments or `req.payload`, HMR is aut
 
 **Option 2 - outside of Next.js**
 
-If you are using Payload outside of Next.js, for example in standalone scripts or in other frameworks, you can import Payload with no HMR functionality.
+If you are using Payload outside of Next.js, for example in standalone scripts or in other frameworks, you can import Payload with no HMR functionality. Instead of using `getPayloadHMR`, you can use `getPayload`.
 
 ```ts
 import { getPayload } from 'payload'
-import { importConfig } from 'payload/node'
+import config from '@payload-config'
 
-const config = await importConfig('./payload.config.ts')
 const payload = await getPayload({ config })
 ```
 
-Both options function in exactly the same way outside of one having HMR support and the other not. However, when you import your Payload Config, you need to make sure that you can import it safely.
-
-For more information about using Payload outside of Next.js, [click here](/docs/beta/local-api/outside-nextjs).
+Both options function in exactly the same way outside of one having HMR support and the other not. For more information about using Payload outside of Next.js, [click here](/docs/beta/local-api/outside-nextjs).
 
 ## Local options available
 

docs/migration-guide/overview.mdx

@@ -709,7 +709,7 @@ import type { FormState } from 'payload'
 
 This is because the configs themselves are not serializable and so they cannot be thread through to the client, i.e. the `DocumentInfoContext`. Instead, various properties of the config are passed instead, like `collectionSlug` and `globalSlug`.  You can use these to access a client-side config, if needed, through the `useConfig` hook (see next bullet).
 
-17. The `useConfig` hook now returns a `ClientConfig` and not a `SanizitedConfig`.
+17. The `useConfig` hook now returns a `ClientConfig` and not a `SanitizedConfig`.
 
 This is because the config itself is not serializable and so it is not able to be thread through to the client, i.e. the `ConfigContext`.