payload 1.0.27 → 1.0.28

package/docs/admin/webpack.mdx

@@ -10,8 +10,8 @@ Payload uses Webpack 5 to build the Admin panel. It comes with support for many
 
 To extend the Webpack config, add the `webpack` key to your base Payload config, and provide a function that accepts the default Webpack config as its only argument:
 
-`payload.config.js`
-```js
+`payload.config.ts`
+```ts
 import { buildConfig } from 'payload/config';
 
 export default buildConfig({
@@ -24,7 +24,7 @@ export default buildConfig({
 		}
 		// highlight-end
 	}
-})
+});
 ```
 
 ### Aliasing server-only modules
@@ -52,16 +52,17 @@ You may rely on server-only packages such as the above to perform logic in acces
 <br/><br/>
 
 `collections/Subscriptions/index.js`
-```js
+```ts
+import { CollectionConfig } from 'payload/types';
 import createStripeSubscription from './hooks/createStripeSubscription';
 
-const Subscription = {
+const Subscription: CollectionConfig = {
 	slug: 'subscriptions',
 	hooks: {
 		beforeChange: [
 			createStripeSubscription,
 		]
-	}
+	},
 	fields: [
 		{
 			name: 'stripeSubscriptionID',
@@ -69,7 +70,7 @@ const Subscription = {
 			required: true,
 		}
 	]
-}
+};
 
 export default Subscription;
 ```

package/docs/authentication/config.mdx

@@ -49,7 +49,7 @@ To utilize your API key while interacting with the REST or GraphQL API, add the
 
 **For example, using Fetch:**
 
-```js
+```ts
 const response = await fetch("http://localhost:3000/api/pages", {
   headers: {
     Authorization: `${collection.labels.singular} API-Key ${YOUR_API_KEY}`,
@@ -77,8 +77,10 @@ Function that accepts one argument, containing `{ req, token, user }`, that allo
 
 Example:
 
-```js
-{
+```ts
+import { CollectionConfig } from 'payload/types';
+
+const Customers: CollectionConfig = {
   slug: 'customers',
   auth: {
     forgotPassword: {
@@ -104,7 +106,7 @@ Example:
       // highlight-end
     }
   }
-}
+};
 ```
 
 <Banner type="warning">
@@ -123,7 +125,7 @@ Similarly to the above `generateEmailHTML`, you can also customize the subject o
 
 Example:
 
-```js
+```ts
 {
   slug: 'customers',
   auth: {
@@ -148,8 +150,11 @@ Function that accepts one argument, containing `{ req, token, user }`, that allo
 
 Example:
 
-```js
-{
+```ts
+import { CollectionConfig } from 'payload/types';
+
+
+const Customers: CollectionConfig = {
   slug: 'customers',
   auth: {
     verify: {
@@ -163,7 +168,7 @@ Example:
       // highlight-end
     }
   }
-}
+};
 ```
 
 <Banner type="warning">
@@ -182,7 +187,7 @@ Similarly to the above `generateEmailHTML`, you can also customize the subject o
 
 Example:
 
-```js
+```ts
 {
   slug: 'customers',
   auth: {

package/docs/authentication/operations.mdx

@@ -17,7 +17,7 @@ The Access operation returns what a logged in user can and can't do with the col
 `GET http://localhost:3000/api/access`
 
 Example response:
-```js
+```ts
 {
   canAccessAdmin: true,
   collections: {
@@ -54,7 +54,7 @@ Example response:
 
 **Example GraphQL Query**:
 
-```
+```graphql
 query {
   Access {
     pages {
@@ -75,7 +75,7 @@ Returns either a logged in user with token or null when there is no logged in us
 `GET http://localhost:3000/api/[collection-slug]/me`
 
 Example response:
-```js
+```ts
 {
   user: { // The JWT "payload" ;) from the logged in user
     email: 'dev@payloadcms.com',
@@ -90,7 +90,7 @@ Example response:
 
 **Example GraphQL Query**:
 
-```
+```graphql
 query {
   Me[collection-singular-label] {
     user {
@@ -106,7 +106,7 @@ query {
 Accepts an `email` and `password`. On success, it will return the logged in user as well as a token that can be used to authenticate. In the GraphQL and REST APIs, this operation also automatically sets an HTTP-only cookie including the user's token. If you pass an Express `res` to the Local API operation, Payload will set a cookie there as well.
 
 **Example REST API login**:
-```js
+```ts
 const res = await fetch('http://localhost:3000/api/[collection-slug]/login', {
   method: 'POST',
   headers: {
@@ -137,7 +137,7 @@ const json = await res.json();
 
 **Example GraphQL Mutation**:
 
-```
+```graphql
 mutation {
   login[collection-singular-label](email: "dev@payloadcms.com", password: "yikes") {
     user {
@@ -151,7 +151,7 @@ mutation {
 
 **Example Local API login**:
 
-```js
+```ts
 const result = await payload.login({
   collection: '[collection-slug]',
   data: {
@@ -166,7 +166,7 @@ const result = await payload.login({
 As Payload sets HTTP-only cookies, logging out cannot be done by just removing a cookie in JavaScript, as HTTP-only cookies are inaccessible by JS within the browser. So, Payload exposes a `logout` operation to delete the token in a safe way.
 
 **Example REST API logout**:
-```js
+```ts
 const res = await fetch('http://localhost:3000/api/[collection-slug]/logout', {
   method: 'POST',
   headers: {
@@ -192,7 +192,7 @@ This operation requires a non-expired token to send back a new one. If the user'
 If successful, this operation will automatically renew the user's HTTP-only cookie and will send back the updated token in JSON.
 
 **Example REST API token refresh**:
-```js
+```ts
 const res = await fetch('http://localhost:3000/api/[collection-slug]/refresh-token', {
   method: 'POST',
   headers: {
@@ -239,18 +239,18 @@ mutation {
 If your collection supports email verification, the Verify operation will be exposed which accepts a verification token and sets the user's `_verified` property to `true`, thereby allowing the user to authenticate with the Payload API.
 
 **Example REST API user verification**:
-```js
+```ts
 const res = await fetch(`http://localhost:3000/api/[collection-slug]/verify/${TOKEN_HERE}`, {
   method: 'POST',
   headers: {
     'Content-Type': 'application/json',
   },
-})
+});
 ```
 
 **Example GraphQL Mutation**:
 
-```
+```graphql
 mutation {
   verifyEmail[collection-singular-label](token: "TOKEN_HERE")
 }
@@ -258,7 +258,7 @@ mutation {
 
 **Example Local API verification**:
 
-```js
+```ts
 const result = await payload.verifyEmail({
   collection: '[collection-slug]',
   token: 'TOKEN_HERE',
@@ -272,7 +272,7 @@ If a user locks themselves out and you wish to deliberately unlock them, you can
 To restrict who is allowed to unlock users, you can utilize the [`unlock`](/docs/access-control/overview#unlock) access control function.
 
 **Example REST API unlock**:
-```js
+```ts
 const res = await fetch(`http://localhost:3000/api/[collection-slug]/unlock`, {
   method: 'POST',
   headers: {
@@ -291,7 +291,7 @@ mutation {
 
 **Example Local API unlock**:
 
-```js
+```ts
 const result = await payload.unlock({
   collection: '[collection-slug]',
 })
@@ -306,7 +306,7 @@ The link to reset the user's password contains a token which is what allows the
 By default, the Forgot Password operations send users to the Payload Admin panel to reset their password, but you can customize the generated email to send users to the frontend of your app instead by [overriding the email HTML](/docs/authentication/config#forgot-password).
 
 **Example REST API Forgot Password**:
-```js
+```ts
 const res = await fetch(`http://localhost:3000/api/[collection-slug]/forgot-password`, {
   method: 'POST',
   headers: {
@@ -315,7 +315,7 @@ const res = await fetch(`http://localhost:3000/api/[collection-slug]/forgot-pass
   body: JSON.stringify({
     email: 'dev@payloadcms.com',
   }),
-})
+});
 ```
 
 **Example GraphQL Mutation**:
@@ -328,14 +328,14 @@ mutation {
 
 **Example Local API forgot password**:
 
-```js
+```ts
 const token = await payload.forgotPassword({
   collection: '[collection-slug]',
   data: {
     email: 'dev@payloadcms.com',
   },
   disableEmail: false // you can disable the auto-generation of email via local API
-})
+});
 ```
 
 <Banner type="success">
@@ -348,7 +348,7 @@ const token = await payload.forgotPassword({
 After a user has "forgotten" their password and a token is generated, that token can be used to send to the reset password operation along with a new password which will allow the user to reset their password securely.
 
 **Example REST API Reset Password**:
-```js
+```ts
 const res = await fetch(`http://localhost:3000/api/[collection-slug]/reset-password`, {
   method: 'POST',
   headers: {
@@ -358,7 +358,7 @@ const res = await fetch(`http://localhost:3000/api/[collection-slug]/reset-passw
     token: 'TOKEN_GOES_HERE'
     password: 'not-today',
   }),
-})
+});
 
 const json = await res.json();
 
@@ -379,7 +379,7 @@ const json = await res.json();
 
 **Example GraphQL Mutation**:
 
-```
+```graphql
 mutation {
   resetPassword[collection-singular-label](token: "TOKEN_GOES_HERE", password: "not-today")
 }

package/docs/authentication/overview.mdx

@@ -32,8 +32,10 @@ Every Payload Collection can opt-in to supporting Authentication by specifying t
 
 Simple example collection:
 
-```js
-const Admins = {
+```ts
+import { CollectionConfig } from 'payload/types';
+
+const Admins: CollectionConfig = {
   slug:
   // highlight-start
   auth: {
@@ -95,7 +97,7 @@ However, if you use `fetch` or similar APIs to retrieve Payload resources from i
 
 Fetch example, including credentials:
 
-```js
+```ts
 const response = await fetch('http://localhost:3000/api/pages', {
   credentials: 'include',
 });
@@ -124,8 +126,8 @@ So, if a user of coolsite.com is logged in and just browsing around on the inter
 
 To define domains that should allow users to identify themselves via the Payload HTTP-only cookie, use the `csrf` option on the base Payload config to whitelist domains that you trust.
 
-`payload.config.js`:
-```js
+`payload.config.ts`:
+```ts
 import { buildConfig } from 'payload/config';
 
 const config = buildConfig({
@@ -148,7 +150,7 @@ export default config;
 In addition to authenticating via an HTTP-only cookie, you can also identify users via the `Authorization` header on an HTTP request.
 
 Example:
-```js
+```ts
 const request = await fetch('http://localhost:3000', {
   headers: {
     Authorization: `JWT ${token}`

package/docs/authentication/using-middleware.mdx

@@ -15,7 +15,7 @@ This approach has a ton of benefits - it's great for isolation of concerns and l
 </Banner>
 
 Example in `server.js`:
-```js
+```ts
 import express from 'express';
 import payload from 'payload';
 

package/docs/configuration/collections.mdx

@@ -31,8 +31,10 @@ It's often best practice to write your Collections in separate files and then im
 
 #### Simple collection example
 
-```js
-const Orders = {
+```ts
+import { CollectionConfig } from 'payload/types';
+
+const Orders: CollectionConfig = {
 	slug: 'orders',
 	fields: [
 		{
@@ -47,7 +49,7 @@ const Orders = {
 			required: true,
 		}
 	]
-}
+};
 ```
 
 #### More collection config examples
@@ -80,8 +82,10 @@ If the function is specified, a Preview button will automatically appear in the
 
 **Example collection with preview function:**
 
-```js
-const Posts = {
+```ts
+import { CollectionConfig } from 'payload/types';
+
+const Posts: CollectionConfig = {
 	slug: 'posts',
 	fields: [
 		{
@@ -118,14 +122,14 @@ Collections support all field types that Payload has to offer—including simple
 
 You can import collection types as follows:
 
-```js
+```ts
 import { CollectionConfig } from 'payload/types';
 
 // This is the type used for incoming collection configs.
 // Only the bare minimum properties are marked as required.
 ```
 
-```js
+```ts
 import { SanitizedCollectionConfig } from 'payload/types';
 
 // This is the type used after an incoming collection config is fully sanitized.

package/docs/configuration/globals.mdx

@@ -28,8 +28,10 @@ As with Collection configs, it's often best practice to write your Globals in se
 
 #### Simple Global example
 
-```js
-const Nav = {
+```ts
+import { GlobalConfig } from 'payload/types';
+
+const Nav: GlobalConfig = {
 	slug: 'nav',
 	fields: [
 		{
@@ -47,7 +49,9 @@ const Nav = {
 			]
 		},
 	]
-}
+};
+
+export default Nav;
 ```
 
 #### Global config example
@@ -78,14 +82,14 @@ Globals support all field types that Payload has to offer—including simple fie
 
 You can import global types as follows:
 
-```js
+```ts
 import { GlobalConfig } from 'payload/types';
 
 // This is the type used for incoming global configs.
 // Only the bare minimum properties are marked as required.
 ```
 
-```js
+```ts
 import { SanitizedGlobalConfig } from 'payload/types';
 
 // This is the type used after an incoming global config is fully sanitized.

package/docs/configuration/localization.mdx

@@ -14,21 +14,23 @@ Add the `localization` property to your Payload config to enable localization pr
 
 **Example Payload config set up for localization:**
 
-```js
-{
-	collections: [
-		... // collections go here
-	],
-	localization: {
-		locales: [
-			'en',
-			'es',
-			'de',
-		],
-		defaultLocale: 'en',
-		fallback: true,
-	},
-}
+```ts
+import { buildConfig } from 'payload/config'
+
+export default buildConfig({
+  collections: [
+    // collections go here
+  ],
+  localization: {
+    locales: [
+      'en',
+      'es',
+      'de',
+    ],
+    defaultLocale: 'en',
+    fallback: true,
+  },
+});
 ```
 
 **Here is a brief explanation of each of the options available within the `localization` property:**
@@ -53,11 +55,11 @@ Payload localization works on a **field** level—not a document level. In addit
 
 ```js
 {
-	name: 'title',
-	type: 'text',
-	// highlight-start
-	localized: true,
-	// highlight-end
+  name: 'title',
+  type: 'text',
+  // highlight-start
+  localized: true,
+  // highlight-end
 }
 ```
 
@@ -66,8 +68,8 @@ With the above configuration, the `title` field will now be saved in the databas
 All field types with a `name` property support the `localized` property—even the more complex field types like `array`s and `block`s.
 
 <Banner>
-	<strong>Note:</strong><br/>
-	Enabling localization for field types that support nested fields will automatically create localized "sets" of all fields contained within the field. For example, if you have a page layout using a blocks field type, you have the choice of either localizing the full layout, by enabling localization on the top-level blocks field, or only certain fields within the layout.
+  <strong>Note:</strong><br/>
+  Enabling localization for field types that support nested fields will automatically create localized "sets" of all fields contained within the field. For example, if you have a page layout using a blocks field type, you have the choice of either localizing the full layout, by enabling localization on the top-level blocks field, or only certain fields within the layout.
 </Banner>
 
 ### Retrieving localized docs
@@ -104,16 +106,16 @@ The `fallbackLocale` arg will accept valid locales as well as `none` to disable
 
 ```graphql
 query {
-	Posts(locale: de, fallbackLocale: none) {
-		docs {
-			title
-		}
-	}
+  Posts(locale: de, fallbackLocale: none) {
+    docs {
+      title
+    }
+  }
 }
 ```
 
 <Banner>
-	In GraphQL, specifying the locale at the top level of a query will automatically apply it throughout all nested relationship fields. You can override this behavior by re-specifying locale arguments in nested related document queries.
+  In GraphQL, specifying the locale at the top level of a query will automatically apply it throughout all nested relationship fields. You can override this behavior by re-specifying locale arguments in nested related document queries.
 </Banner>
 
 ##### Local API
@@ -124,9 +126,9 @@ You can specify `locale` as well as `fallbackLocale` within the Local API as wel
 
 ```js
 const posts = await payload.find({
-	collection: 'posts',
-	locale: 'es',
-	fallbackLocale: false,
+  collection: 'posts',
+  locale: 'es',
+  fallbackLocale: false,
 })
 ```
 

package/docs/configuration/overview.mdx

@@ -43,10 +43,10 @@ Payload is a *config-based*, code-first CMS and application framework. The Paylo
 
 #### Simple example
 
-```js
+```ts
 import { buildConfig } from 'payload/config';
 
-const config = buildConfig({
+export default buildConfig({
 	collections: [
 		{
 			slug: 'pages',
@@ -83,9 +83,6 @@ const config = buildConfig({
 		}
 	]
 });
-
-export default config;
-
 ```
 
 #### Full example config
@@ -174,14 +171,14 @@ Then, you could import this file into both your Payload config and your server,
 
 You can import config types as follows:
 
-```js
+```ts
 import { Config } from 'payload/config';
 
 // This is the type used for an incoming Payload config.
 // Only the bare minimum properties are marked as required.
 ```
 
-```js
+```ts
 import { SanitizedConfig } from 'payload/config';
 
 // This is the type used after an incoming Payload config is fully sanitized.

package/docs/email/overview.mdx

@@ -40,7 +40,7 @@ The following options are configurable in the `email` property object as part of
 Simple Mail Transfer Protocol, also known as SMTP can be passed in using the `transportOptions` object on the `email` options.
 
 **Example email part using SMTP:**
-```js
+```ts
 payload.init({
   email: {
     transportOptions: {
@@ -60,6 +60,7 @@ payload.init({
     fromAddress: 'hello@example.com'
   }
   // ...
+})
 ```
 
 <Banner type="warning">
@@ -70,9 +71,9 @@ payload.init({
 
 Many third party mail providers are available and offer benefits beyond basic SMTP. As an example your payload init could look this if you wanted to use SendGrid.com though the same approach would work for any other [NodeMailer transports](https://nodemailer.com/transports/) shown here or provided by another third party.
 
-```js
-const nodemailerSendgrid = require('nodemailer-sendgrid');
-const payload = require('payload');
+```ts
+import payload from 'payload'
+import nodemailerSendgrid from 'nodemailer-sendgrid'
 
 const sendGridAPIKey = process.env.SENDGRID_API_KEY;
 
@@ -92,7 +93,10 @@ payload.init({
 ### Use a custom NodeMailer transport
 To take full control of the mail transport you may wish to use `nodemailer.createTransport()` on your server and provide it to Payload init.
 
-```js
+```ts
+import payload from 'payload'
+import nodemailer from 'nodemailer'
+
 const payload = require('payload');
 const nodemailer = require('nodemailer');
 
@@ -112,7 +116,7 @@ payload.init({
     transport
   },
   // ...
-}
+});
 ```
 
 ### Sending Mail
@@ -123,7 +127,7 @@ By default, Payload uses a mock implementation that only sends mail to the [ethe
 
 To see ethereal credentials, add `logMockCredentials: true` to the email options. This will cause them to be logged to console on startup.
 
-```js
+```ts
 payload.init({
   email: {
     fromName: 'Admin',

package/docs/fields/array.mdx

@@ -41,9 +41,11 @@ keywords: array, fields, config, configuration, documentation, Content Managemen
 
 ### Example
 
-`collections/ExampleCollection.js`
-```js
-{
+`collections/ExampleCollection.ts`
+```ts
+import { CollectionConfig } from 'payload/types';
+
+const ExampleCollection: CollectionConfig = {
   slug: 'example-collection',
   fields: [
     {
@@ -70,6 +72,5 @@ keywords: array, fields, config, configuration, documentation, Content Managemen
       ]
     }
   ]
-}
-
+};
 ```