SIGN IN SIGN UP
payloadcms / payload UNCLAIMED

Payload is the open-source, fullstack Next.js framework, giving you instant backend superpowers. Get a full TypeScript backend and admin panel instantly. Use Payload as a headless CMS or for building powerful applications.

41461 0 1 TypeScript
{
"compilerOptions": {
/* Strictness */
"strict": true,
"noUncheckedIndexedAccess": true,
"noImplicitOverride": true,
"composite": true,
"declaration": true,
"declarationMap": true,
"target": "ES2022",
"rootDir": "${configDir}/src",
"module": "NodeNext",
"moduleResolution": "NodeNext",
"allowJs": true,
"checkJs": false,
"esModuleInterop": true,
"forceConsistentCasingInFileNames": true,
"jsx": "preserve",
"outDir": "${configDir}/dist",
"resolveJsonModule": true,
"skipLibCheck": true,
"emitDeclarationOnly": true,
"sourceMap": true,
fix: isValidID validation (#15217) ## Scripts ### `script:setup-figma` Sets up the local development environment for testing with content-api: - Clones `enterprise-plugins` repo if not present (sibling directory) - Runs `pnpm install` in enterprise-plugins - Removes `@payloadcms/figma` from `test/package.json` to rely on vitest alias instead ### `test:int:summary` Shows less noisy output for integration tests - reports how many tests failed without detailed error messages. The test suites to run can be easily modified via a hardcoded array. This script is particularly useful when many tests fail (e.g., when starting to develop a new db-adapter). To run it for a specific adapter, prefix with `PAYLOAD_DATABASE` env var. Can be removed once content-api is complete if desired. ## Bug Fixes ### Fixed `isValidID` validation - Now properly checks that value type matches the expected ID type - Rejects numbers when `type === 'text'` (fixes content-api adapter validation) - Only accepts numbers when `type === 'number'` - Added explicit `return false` for invalid cases ## Test Improvements ### Refactored "Schema generation" tests Moved conditional logic inside `it()` blocks instead of wrapping them, preventing "no tests found" errors with new db-adapters. ### Added type casting tests Tests for automatic type coercion in database adapters: - String-to-number conversion in `hasMany` number fields - Date field storage and retrieval as ISO strings - Unix timestamp to ISO string conversion See rationale in the comments of [this PR](https://github.com/payloadcms/enterprise-plugins/pull/300). ### Configured Vitest to run tests from `src/` instead of `dist/` This was very difficult with Jest and eliminates the need to build in watch mode during development. --- **Note:** Current setup is designed for local content-api and db-adapter development. Small modifications will be made in the future to run these tests in CI against a deployed staging content-api URL.
2026-01-16 20:19:25 +00:00
"lib": ["DOM", "DOM.Iterable", "ES2022"],
"types": ["node"],
"incremental": true,
"isolatedModules": true,
"plugins": [
{
"name": "next"
}
],
"paths": {
fix: isValidID validation (#15217) ## Scripts ### `script:setup-figma` Sets up the local development environment for testing with content-api: - Clones `enterprise-plugins` repo if not present (sibling directory) - Runs `pnpm install` in enterprise-plugins - Removes `@payloadcms/figma` from `test/package.json` to rely on vitest alias instead ### `test:int:summary` Shows less noisy output for integration tests - reports how many tests failed without detailed error messages. The test suites to run can be easily modified via a hardcoded array. This script is particularly useful when many tests fail (e.g., when starting to develop a new db-adapter). To run it for a specific adapter, prefix with `PAYLOAD_DATABASE` env var. Can be removed once content-api is complete if desired. ## Bug Fixes ### Fixed `isValidID` validation - Now properly checks that value type matches the expected ID type - Rejects numbers when `type === 'text'` (fixes content-api adapter validation) - Only accepts numbers when `type === 'number'` - Added explicit `return false` for invalid cases ## Test Improvements ### Refactored "Schema generation" tests Moved conditional logic inside `it()` blocks instead of wrapping them, preventing "no tests found" errors with new db-adapters. ### Added type casting tests Tests for automatic type coercion in database adapters: - String-to-number conversion in `hasMany` number fields - Date field storage and retrieval as ISO strings - Unix timestamp to ISO string conversion See rationale in the comments of [this PR](https://github.com/payloadcms/enterprise-plugins/pull/300). ### Configured Vitest to run tests from `src/` instead of `dist/` This was very difficult with Jest and eliminates the need to build in watch mode during development. --- **Note:** Current setup is designed for local content-api and db-adapter development. Small modifications will be made in the future to run these tests in CI against a deployed staging content-api URL.
2026-01-16 20:19:25 +00:00
"@payloadcms/figma": ["../enterprise-plugins/packages/figma/src/index.ts"],
"@payload-config": ["./test/_community/config.ts"],
fix: isValidID validation (#15217) ## Scripts ### `script:setup-figma` Sets up the local development environment for testing with content-api: - Clones `enterprise-plugins` repo if not present (sibling directory) - Runs `pnpm install` in enterprise-plugins - Removes `@payloadcms/figma` from `test/package.json` to rely on vitest alias instead ### `test:int:summary` Shows less noisy output for integration tests - reports how many tests failed without detailed error messages. The test suites to run can be easily modified via a hardcoded array. This script is particularly useful when many tests fail (e.g., when starting to develop a new db-adapter). To run it for a specific adapter, prefix with `PAYLOAD_DATABASE` env var. Can be removed once content-api is complete if desired. ## Bug Fixes ### Fixed `isValidID` validation - Now properly checks that value type matches the expected ID type - Rejects numbers when `type === 'text'` (fixes content-api adapter validation) - Only accepts numbers when `type === 'number'` - Added explicit `return false` for invalid cases ## Test Improvements ### Refactored "Schema generation" tests Moved conditional logic inside `it()` blocks instead of wrapping them, preventing "no tests found" errors with new db-adapters. ### Added type casting tests Tests for automatic type coercion in database adapters: - String-to-number conversion in `hasMany` number fields - Date field storage and retrieval as ISO strings - Unix timestamp to ISO string conversion See rationale in the comments of [this PR](https://github.com/payloadcms/enterprise-plugins/pull/300). ### Configured Vitest to run tests from `src/` instead of `dist/` This was very difficult with Jest and eliminates the need to build in watch mode during development. --- **Note:** Current setup is designed for local content-api and db-adapter development. Small modifications will be made in the future to run these tests in CI against a deployed staging content-api URL.
2026-01-16 20:19:25 +00:00
"@payloadcms/admin-bar": ["./packages/admin-bar/src"],
"@payloadcms/live-preview": ["./packages/live-preview/src"],
"@payloadcms/live-preview-react": ["./packages/live-preview-react/src/index.ts"],
"@payloadcms/live-preview-vue": ["./packages/live-preview-vue/src/index.ts"],
"@payloadcms/ui": ["./packages/ui/src/exports/client/index.ts"],
"@payloadcms/ui/shared": ["./packages/ui/src/exports/shared/index.ts"],
"@payloadcms/ui/rsc": ["./packages/ui/src/exports/rsc/index.ts"],
"@payloadcms/ui/scss": ["./packages/ui/src/scss.scss"],
"@payloadcms/ui/scss/app.scss": ["./packages/ui/src/scss/app.scss"],
"@payloadcms/next/*": ["./packages/next/src/exports/*.ts"],
"@payloadcms/richtext-lexical/client": [
"./packages/richtext-lexical/src/exports/client/index.ts"
],
fix: isValidID validation (#15217) ## Scripts ### `script:setup-figma` Sets up the local development environment for testing with content-api: - Clones `enterprise-plugins` repo if not present (sibling directory) - Runs `pnpm install` in enterprise-plugins - Removes `@payloadcms/figma` from `test/package.json` to rely on vitest alias instead ### `test:int:summary` Shows less noisy output for integration tests - reports how many tests failed without detailed error messages. The test suites to run can be easily modified via a hardcoded array. This script is particularly useful when many tests fail (e.g., when starting to develop a new db-adapter). To run it for a specific adapter, prefix with `PAYLOAD_DATABASE` env var. Can be removed once content-api is complete if desired. ## Bug Fixes ### Fixed `isValidID` validation - Now properly checks that value type matches the expected ID type - Rejects numbers when `type === 'text'` (fixes content-api adapter validation) - Only accepts numbers when `type === 'number'` - Added explicit `return false` for invalid cases ## Test Improvements ### Refactored "Schema generation" tests Moved conditional logic inside `it()` blocks instead of wrapping them, preventing "no tests found" errors with new db-adapters. ### Added type casting tests Tests for automatic type coercion in database adapters: - String-to-number conversion in `hasMany` number fields - Date field storage and retrieval as ISO strings - Unix timestamp to ISO string conversion See rationale in the comments of [this PR](https://github.com/payloadcms/enterprise-plugins/pull/300). ### Configured Vitest to run tests from `src/` instead of `dist/` This was very difficult with Jest and eliminates the need to build in watch mode during development. --- **Note:** Current setup is designed for local content-api and db-adapter development. Small modifications will be made in the future to run these tests in CI against a deployed staging content-api URL.
2026-01-16 20:19:25 +00:00
"@payloadcms/richtext-lexical/rsc": ["./packages/richtext-lexical/src/exports/server/rsc.ts"],
"@payloadcms/richtext-slate/rsc": ["./packages/richtext-slate/src/exports/server/rsc.ts"],
"@payloadcms/plugin-ecommerce/ui": ["./packages/plugin-ecommerce/src/exports/ui.ts"],
"@payloadcms/plugin-ecommerce/react": ["./packages/plugin-ecommerce/src/exports/react.ts"],
"@payloadcms/plugin-ecommerce/types": ["./packages/plugin-ecommerce/src/exports/types.ts"],
"@payloadcms/richtext-slate/client": [
"./packages/richtext-slate/src/exports/client/index.ts"
],
fix: isValidID validation (#15217) ## Scripts ### `script:setup-figma` Sets up the local development environment for testing with content-api: - Clones `enterprise-plugins` repo if not present (sibling directory) - Runs `pnpm install` in enterprise-plugins - Removes `@payloadcms/figma` from `test/package.json` to rely on vitest alias instead ### `test:int:summary` Shows less noisy output for integration tests - reports how many tests failed without detailed error messages. The test suites to run can be easily modified via a hardcoded array. This script is particularly useful when many tests fail (e.g., when starting to develop a new db-adapter). To run it for a specific adapter, prefix with `PAYLOAD_DATABASE` env var. Can be removed once content-api is complete if desired. ## Bug Fixes ### Fixed `isValidID` validation - Now properly checks that value type matches the expected ID type - Rejects numbers when `type === 'text'` (fixes content-api adapter validation) - Only accepts numbers when `type === 'number'` - Added explicit `return false` for invalid cases ## Test Improvements ### Refactored "Schema generation" tests Moved conditional logic inside `it()` blocks instead of wrapping them, preventing "no tests found" errors with new db-adapters. ### Added type casting tests Tests for automatic type coercion in database adapters: - String-to-number conversion in `hasMany` number fields - Date field storage and retrieval as ISO strings - Unix timestamp to ISO string conversion See rationale in the comments of [this PR](https://github.com/payloadcms/enterprise-plugins/pull/300). ### Configured Vitest to run tests from `src/` instead of `dist/` This was very difficult with Jest and eliminates the need to build in watch mode during development. --- **Note:** Current setup is designed for local content-api and db-adapter development. Small modifications will be made in the future to run these tests in CI against a deployed staging content-api URL.
2026-01-16 20:19:25 +00:00
"@payloadcms/plugin-seo/client": ["./packages/plugin-seo/src/exports/client.ts"],
"@payloadcms/plugin-sentry/client": ["./packages/plugin-sentry/src/exports/client.ts"],
"@payloadcms/plugin-stripe/client": ["./packages/plugin-stripe/src/exports/client.ts"],
"@payloadcms/plugin-search/client": ["./packages/plugin-search/src/exports/client.ts"],
"@payloadcms/plugin-form-builder/client": [
"./packages/plugin-form-builder/src/exports/client.ts"
],
"@payloadcms/plugin-import-export/rsc": [
"./packages/plugin-import-export/src/exports/rsc.ts"
],
fix: isValidID validation (#15217) ## Scripts ### `script:setup-figma` Sets up the local development environment for testing with content-api: - Clones `enterprise-plugins` repo if not present (sibling directory) - Runs `pnpm install` in enterprise-plugins - Removes `@payloadcms/figma` from `test/package.json` to rely on vitest alias instead ### `test:int:summary` Shows less noisy output for integration tests - reports how many tests failed without detailed error messages. The test suites to run can be easily modified via a hardcoded array. This script is particularly useful when many tests fail (e.g., when starting to develop a new db-adapter). To run it for a specific adapter, prefix with `PAYLOAD_DATABASE` env var. Can be removed once content-api is complete if desired. ## Bug Fixes ### Fixed `isValidID` validation - Now properly checks that value type matches the expected ID type - Rejects numbers when `type === 'text'` (fixes content-api adapter validation) - Only accepts numbers when `type === 'number'` - Added explicit `return false` for invalid cases ## Test Improvements ### Refactored "Schema generation" tests Moved conditional logic inside `it()` blocks instead of wrapping them, preventing "no tests found" errors with new db-adapters. ### Added type casting tests Tests for automatic type coercion in database adapters: - String-to-number conversion in `hasMany` number fields - Date field storage and retrieval as ISO strings - Unix timestamp to ISO string conversion See rationale in the comments of [this PR](https://github.com/payloadcms/enterprise-plugins/pull/300). ### Configured Vitest to run tests from `src/` instead of `dist/` This was very difficult with Jest and eliminates the need to build in watch mode during development. --- **Note:** Current setup is designed for local content-api and db-adapter development. Small modifications will be made in the future to run these tests in CI against a deployed staging content-api URL.
2026-01-16 20:19:25 +00:00
"@payloadcms/plugin-mcp": ["./packages/plugin-mcp/src/index.ts"],
"@payloadcms/plugin-multi-tenant/rsc": ["./packages/plugin-multi-tenant/src/exports/rsc.ts"],
feat: adds multi-tenant plugin (#10447) ### Multi Tenant Plugin This PR adds a `@payloadcms/plugin-multi-tenant` package. The goal is to consolidate a source of truth for multi-tenancy. Currently we are maintaining different implementations for clients, users in discord and our examples repo. When updates or new paradigms arise we need to communicate this with everyone and update code examples which is hard to maintain. ### What does it do? - adds a tenant selector to the sidebar, above the nav links - adds a hidden tenant field to every collection that you specify - adds an array field to your users collection, allowing you to assign users to tenants - by default combines the access control (to enabled collections) that you define, with access control based on the tenants assigned to user on the request - by default adds a baseListFilter that filters the documents shown in the list view with the selected tenant in the admin panel ### What does it not do? - it does not implement multi-tenancy for your frontend. You will need to query data for specific tenants to build your website/application - it does not add a tenants collection, you **NEED** to add a tenants collection, where you can define what types of fields you would like on it ### The plugin config Most of the options listed below are _optional_, but it is easier to just lay out all of the configuration options. **TS Type** ```ts type MultiTenantPluginConfig<ConfigTypes = unknown> = { /** * After a tenant is deleted, the plugin will attempt to clean up related documents * - removing documents with the tenant ID * - removing the tenant from users * * @default true */ cleanupAfterTenantDelete?: boolean /** * Automatically */ collections: { [key in CollectionSlug]?: { /** * Set to `true` if you want the collection to behave as a global * * @default false */ isGlobal?: boolean /** * Set to `false` if you want to manually apply the baseListFilter * * @default true */ useBaseListFilter?: boolean /** * Set to `false` if you want to handle collection access manually without the multi-tenant constraints applied * * @default true */ useTenantAccess?: boolean } } /** * Enables debug mode * - Makes the tenant field visible in the admin UI within applicable collections * * @default false */ debug?: boolean /** * Enables the multi-tenant plugin * * @default true */ enabled?: boolean /** * Field configuration for the field added to all tenant enabled collections */ tenantField?: { access?: RelationshipField['access'] /** * The name of the field added to all tenant enabled collections * * @default 'tenant' */ name?: string } /** * Field configuration for the field added to the users collection * * If `includeDefaultField` is `false`, you must include the field on your users collection manually * This is useful if you want to customize the field or place the field in a specific location */ tenantsArrayField?: | { /** * Access configuration for the array field */ arrayFieldAccess?: ArrayField['access'] /** * When `includeDefaultField` is `true`, the field will be added to the users collection automatically */ includeDefaultField?: true /** * Additional fields to include on the tenants array field */ rowFields?: Field[] /** * Access configuration for the tenant field */ tenantFieldAccess?: RelationshipField['access'] } | { arrayFieldAccess?: never /** * When `includeDefaultField` is `false`, you must include the field on your users collection manually */ includeDefaultField?: false rowFields?: never tenantFieldAccess?: never } /** * The slug for the tenant collection * * @default 'tenants' */ tenantsSlug?: string /** * Function that determines if a user has access to _all_ tenants * * Useful for super-admin type users */ userHasAccessToAllTenants?: ( user: ConfigTypes extends { user: User } ? ConfigTypes['user'] : User, ) => boolean } ``` **Example usage** ```ts import type { Config } from './payload-types' import { buildConfig } from 'payload' export default buildConfig({ plugins: [ multiTenantPlugin<Config>({ collections: { pages: {}, }, userHasAccessToAllTenants: (user) => isSuperAdmin(user), }), ], }) ``` ### How to configure Collections as Globals for multi-tenant When using multi-tenant, globals need to actually be configured as collections so the content can be specific per tenant. To do that, you can mark a collection with `isGlobal` and it will behave like a global and users will not see the list view. ```ts multiTenantPlugin({ collections: { navigation: { isGlobal: true, }, }, }) ```
2025-01-15 14:47:46 -05:00
"@payloadcms/plugin-multi-tenant/utilities": [
"./packages/plugin-multi-tenant/src/exports/utilities.ts"
],
"@payloadcms/plugin-multi-tenant/fields": [
"./packages/plugin-multi-tenant/src/exports/fields.ts"
],
"@payloadcms/plugin-multi-tenant/client": [
"./packages/plugin-multi-tenant/src/exports/client.ts"
],
fix: isValidID validation (#15217) ## Scripts ### `script:setup-figma` Sets up the local development environment for testing with content-api: - Clones `enterprise-plugins` repo if not present (sibling directory) - Runs `pnpm install` in enterprise-plugins - Removes `@payloadcms/figma` from `test/package.json` to rely on vitest alias instead ### `test:int:summary` Shows less noisy output for integration tests - reports how many tests failed without detailed error messages. The test suites to run can be easily modified via a hardcoded array. This script is particularly useful when many tests fail (e.g., when starting to develop a new db-adapter). To run it for a specific adapter, prefix with `PAYLOAD_DATABASE` env var. Can be removed once content-api is complete if desired. ## Bug Fixes ### Fixed `isValidID` validation - Now properly checks that value type matches the expected ID type - Rejects numbers when `type === 'text'` (fixes content-api adapter validation) - Only accepts numbers when `type === 'number'` - Added explicit `return false` for invalid cases ## Test Improvements ### Refactored "Schema generation" tests Moved conditional logic inside `it()` blocks instead of wrapping them, preventing "no tests found" errors with new db-adapters. ### Added type casting tests Tests for automatic type coercion in database adapters: - String-to-number conversion in `hasMany` number fields - Date field storage and retrieval as ISO strings - Unix timestamp to ISO string conversion See rationale in the comments of [this PR](https://github.com/payloadcms/enterprise-plugins/pull/300). ### Configured Vitest to run tests from `src/` instead of `dist/` This was very difficult with Jest and eliminates the need to build in watch mode during development. --- **Note:** Current setup is designed for local content-api and db-adapter development. Small modifications will be made in the future to run these tests in CI against a deployed staging content-api URL.
2026-01-16 20:19:25 +00:00
"@payloadcms/plugin-multi-tenant": ["./packages/plugin-multi-tenant/src/index.ts"],
"@payloadcms/plugin-multi-tenant/translations/languages/all": [
"./packages/plugin-multi-tenant/src/translations/index.ts"
],
"@payloadcms/plugin-multi-tenant/translations/languages/*": [
"./packages/plugin-multi-tenant/src/translations/languages/*.ts"
],
fix: isValidID validation (#15217) ## Scripts ### `script:setup-figma` Sets up the local development environment for testing with content-api: - Clones `enterprise-plugins` repo if not present (sibling directory) - Runs `pnpm install` in enterprise-plugins - Removes `@payloadcms/figma` from `test/package.json` to rely on vitest alias instead ### `test:int:summary` Shows less noisy output for integration tests - reports how many tests failed without detailed error messages. The test suites to run can be easily modified via a hardcoded array. This script is particularly useful when many tests fail (e.g., when starting to develop a new db-adapter). To run it for a specific adapter, prefix with `PAYLOAD_DATABASE` env var. Can be removed once content-api is complete if desired. ## Bug Fixes ### Fixed `isValidID` validation - Now properly checks that value type matches the expected ID type - Rejects numbers when `type === 'text'` (fixes content-api adapter validation) - Only accepts numbers when `type === 'number'` - Added explicit `return false` for invalid cases ## Test Improvements ### Refactored "Schema generation" tests Moved conditional logic inside `it()` blocks instead of wrapping them, preventing "no tests found" errors with new db-adapters. ### Added type casting tests Tests for automatic type coercion in database adapters: - String-to-number conversion in `hasMany` number fields - Date field storage and retrieval as ISO strings - Unix timestamp to ISO string conversion See rationale in the comments of [this PR](https://github.com/payloadcms/enterprise-plugins/pull/300). ### Configured Vitest to run tests from `src/` instead of `dist/` This was very difficult with Jest and eliminates the need to build in watch mode during development. --- **Note:** Current setup is designed for local content-api and db-adapter development. Small modifications will be made in the future to run these tests in CI against a deployed staging content-api URL.
2026-01-16 20:19:25 +00:00
"@payloadcms/next": ["./packages/next/src/exports/*"],
"@payloadcms/storage-azure/client": ["./packages/storage-azure/src/exports/client.ts"],
"@payloadcms/storage-s3/client": ["./packages/storage-s3/src/exports/client.ts"],
"@payloadcms/storage-vercel-blob/client": [
"./packages/storage-vercel-blob/src/exports/client.ts"
],
fix: isValidID validation (#15217) ## Scripts ### `script:setup-figma` Sets up the local development environment for testing with content-api: - Clones `enterprise-plugins` repo if not present (sibling directory) - Runs `pnpm install` in enterprise-plugins - Removes `@payloadcms/figma` from `test/package.json` to rely on vitest alias instead ### `test:int:summary` Shows less noisy output for integration tests - reports how many tests failed without detailed error messages. The test suites to run can be easily modified via a hardcoded array. This script is particularly useful when many tests fail (e.g., when starting to develop a new db-adapter). To run it for a specific adapter, prefix with `PAYLOAD_DATABASE` env var. Can be removed once content-api is complete if desired. ## Bug Fixes ### Fixed `isValidID` validation - Now properly checks that value type matches the expected ID type - Rejects numbers when `type === 'text'` (fixes content-api adapter validation) - Only accepts numbers when `type === 'number'` - Added explicit `return false` for invalid cases ## Test Improvements ### Refactored "Schema generation" tests Moved conditional logic inside `it()` blocks instead of wrapping them, preventing "no tests found" errors with new db-adapters. ### Added type casting tests Tests for automatic type coercion in database adapters: - String-to-number conversion in `hasMany` number fields - Date field storage and retrieval as ISO strings - Unix timestamp to ISO string conversion See rationale in the comments of [this PR](https://github.com/payloadcms/enterprise-plugins/pull/300). ### Configured Vitest to run tests from `src/` instead of `dist/` This was very difficult with Jest and eliminates the need to build in watch mode during development. --- **Note:** Current setup is designed for local content-api and db-adapter development. Small modifications will be made in the future to run these tests in CI against a deployed staging content-api URL.
2026-01-16 20:19:25 +00:00
"@payloadcms/storage-gcs/client": ["./packages/storage-gcs/src/exports/client.ts"],
"@payloadcms/storage-uploadthing/client": [
"./packages/storage-uploadthing/src/exports/client.ts"
],
"@payloadcms/storage-r2/client": ["./packages/storage-r2/src/exports/client.ts"]
}
},
fix: isValidID validation (#15217) ## Scripts ### `script:setup-figma` Sets up the local development environment for testing with content-api: - Clones `enterprise-plugins` repo if not present (sibling directory) - Runs `pnpm install` in enterprise-plugins - Removes `@payloadcms/figma` from `test/package.json` to rely on vitest alias instead ### `test:int:summary` Shows less noisy output for integration tests - reports how many tests failed without detailed error messages. The test suites to run can be easily modified via a hardcoded array. This script is particularly useful when many tests fail (e.g., when starting to develop a new db-adapter). To run it for a specific adapter, prefix with `PAYLOAD_DATABASE` env var. Can be removed once content-api is complete if desired. ## Bug Fixes ### Fixed `isValidID` validation - Now properly checks that value type matches the expected ID type - Rejects numbers when `type === 'text'` (fixes content-api adapter validation) - Only accepts numbers when `type === 'number'` - Added explicit `return false` for invalid cases ## Test Improvements ### Refactored "Schema generation" tests Moved conditional logic inside `it()` blocks instead of wrapping them, preventing "no tests found" errors with new db-adapters. ### Added type casting tests Tests for automatic type coercion in database adapters: - String-to-number conversion in `hasMany` number fields - Date field storage and retrieval as ISO strings - Unix timestamp to ISO string conversion See rationale in the comments of [this PR](https://github.com/payloadcms/enterprise-plugins/pull/300). ### Configured Vitest to run tests from `src/` instead of `dist/` This was very difficult with Jest and eliminates the need to build in watch mode during development. --- **Note:** Current setup is designed for local content-api and db-adapter development. Small modifications will be made in the future to run these tests in CI against a deployed staging content-api URL.
2026-01-16 20:19:25 +00:00
"include": ["${configDir}/src"],
"exclude": ["${configDir}/dist", "${configDir}/build", "${configDir}/temp", "**/*.spec.ts"]
fix: field schema map paths (#10852) Continuation of #10638. Field paths within the schema map are not correct. For example, an unnamed tab containing a text field should have the schema path: - `_index-0.fieldWithinUnnamedTab` However, within the schema map that path is formatted as: - `fieldWithinUnnamedTab` The leading index in the first example _should_ exist, as this field is nested within another field, regardless of this field being unnamed. Otherwise, it would be impossible to traverse the schema and lookup this field. This discrepancy is not an issue in the admin panel because fields are _also_ provided the wrong schema paths. They can properly locate their schema within the schema map because they match despite being incorrect. Both are wrong and that's why it works. Here's comprehensive example of how field paths _should_ be formatted: ```ts { // ... fields: [ { // path: 'topLevelNamedField' // schemaPath: 'topLevelNamedField' // indexPath: '' name: 'topLevelNamedField', type: 'text', }, { // path: 'array' // schemaPath: 'array' // indexPath: '' name: 'array', type: 'array', fields: [ { // path: 'array.[n].fieldWithinArray' // schemaPath: 'array.fieldWithinArray' // indexPath: '' name: 'fieldWithinArray', type: 'text', }, { // path: 'array.[n].nestedArray' // schemaPath: 'array.nestedArray' // indexPath: '' name: 'nestedArray', type: 'array', fields: [ { // path: 'array.[n].nestedArray.[n].fieldWithinNestedArray' // schemaPath: 'array.nestedArray.fieldWithinNestedArray' // indexPath: '' name: 'fieldWithinNestedArray', type: 'text', }, ], }, { // path: 'array.[n]._index-2' // schemaPath: 'array._index-2' // indexPath: '2' type: 'row', fields: [ { // path: 'array.[n].fieldWithinRowWithinArray' // schemaPath: 'array._index-2.fieldWithinRowWithinArray' // indexPath: '' name: 'fieldWithinRowWithinArray', type: 'text', }, ], }, ], }, { // path: '_index-2' // schemaPath: '_index-2' // indexPath: '2' type: 'row', fields: [ { // path: 'fieldWithinRow' // schemaPath: '_index-2.fieldWithinRow' // indexPath: '' name: 'fieldWithinRow', type: 'text', }, ], }, { // path: '_index-3' // schemaPath: '_index-3' // indexPath: '3' type: 'tabs', tabs: [ { // path: '_index-3-0' // schemaPath: '_index-3-0' // indexPath: '3-0' label: 'Unnamed Tab', fields: [ { // path: 'fieldWithinUnnamedTab' // schemaPath: '_index-3-0.fieldWithinUnnamedTab' // indexPath: '' name: 'fieldWithinUnnamedTab', type: 'text', }, { // path: '_index-3-0-1' // schemaPath: '_index-3-0-1' // indexPath: '3-0-1' type: 'tabs', tabs: [ { // path: '_index-3-0-1-0' // schemaPath: '_index-3-0-1-0' // indexPath: '3-0-1-0' label: 'Nested Unnamed Tab', fields: [ { // path: 'fieldWithinNestedUnnamedTab' // schemaPath: '_index-3-0-1-0.fieldWithinNestedUnnamedTab' // indexPath: '' name: 'fieldWithinNestedUnnamedTab', type: 'text', }, ], }, ], }, ], }, { // path: 'namedTab' // schemaPath: '_index-3.namedTab' // indexPath: '' label: 'Named Tab', name: 'namedTab', fields: [ { // path: 'namedTab.fieldWithinNamedTab' // schemaPath: '_index-3.namedTab.fieldWithinNamedTab' // indexPath: '' name: 'fieldWithinNamedTab', type: 'text', }, ], }, ], }, ] } ```
2026-01-09 17:21:17 -05:00
}