12 Commits

Author	SHA1	Message	Date
T. R. Bernstein	4a5f01a78f	chore: Update code to new repo	2025-10-08 23:27:45 +02:00
Alessio Gravili	1c89291fac	feat(richtext-lexical): utility render lexical field on-demand (#13657) ... ## Why this exists Lexical in Payload is a React Server Component (RSC). Historically that created three headaches: 1. You couldn’t render the editor directly from the client. 2. Features like blocks, tables, upload and link drawers require the server to know the shape of nested sub‑fields at render time. If you tried to render on demand, the server didn’t know those schemas. 3. The rich text field is designed to live inside a Form. For simple use cases, setting up a full form just to manage editor state was cumbersome. ## What’s new We now ship a client component, `<RenderLexical />`, that renders a Lexical editor **on demand** while still covering the full feature set. On mount, it calls a server action to render the editor on the server using the new `render-field` server action. That server render gives Lexical everything it needs (including nested field schemas) and returns a ready‑to‑hydrate editor. ## Example - Rendering in custom component within existing Form ```tsx 'use client' import type { JSONFieldClientComponent } from 'payload' import { buildEditorState, RenderLexical } from '@payloadcms/richtext-lexical/client' import { lexicalFullyFeaturedSlug } from '../../slugs.js' export const Component: JSONFieldClientComponent = (args) => { return ( <div> Fully-Featured Component: <RenderLexical field={{ name: 'json' }} initialValue={buildEditorState({ text: 'defaultValue' })} schemaPath={`collection.${lexicalFullyFeaturedSlug}.richText`} /> </div> ) } ``` ## Example - Rendering outside of Form, manually managing richText values ```ts 'use client' import type { DefaultTypedEditorState } from '@payloadcms/richtext-lexical' import type { JSONFieldClientComponent } from 'payload' import { buildEditorState, RenderLexical } from '@payloadcms/richtext-lexical/client' import React, { useState } from 'react' import { lexicalFullyFeaturedSlug } from '../../slugs.js' export const Component: JSONFieldClientComponent = (args) => { const [value, setValue] = useState<DefaultTypedEditorState | undefined>(() => buildEditorState({ text: 'state default' }), ) const handleReset = React.useCallback(() => { setValue(buildEditorState({ text: 'state default' })) }, []) return ( <div> Default Component: <RenderLexical field={{ name: 'json' }} initialValue={buildEditorState({ text: 'defaultValue' })} schemaPath={`collection.${lexicalFullyFeaturedSlug}.richText`} setValue={setValue as any} value={value} /> <button onClick={handleReset} style={{ marginTop: 8 }} type="button"> Reset Editor State </button> </div> ) } ``` ## How it works (under the hood) - On first render, `<RenderLexical />` calls the server function `render-field` (wired into @payloadcms/next), passing a schemaPath. - The server loads the exact field config and its client schema map for that path, renders the Lexical editor server‑side (so nested features like blocks/tables/relationships are fully known), and returns the component tree. - While waiting, the client shows a small shimmer skeleton. - Inside Forms, RenderLexical plugs into the parent form via useField; outside Forms, you can fully control the value by passing value/setValue. ## Type Improvements While implementing the `buildEditorState` helper function for our test suite, I noticed some issues with our `TypedEditorState` type: - nodes were no longer narrowed by their node.type types - upon fixing this issue, the type was no longer compatible with the generated types. To address this, I had to weaken the generated type a bit. In order to ensure the type will keep functioning as intended from now on, this PR also adds some type tests --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1211110462564644	2025-09-18 15:01:12 -07:00
Jacob Fletcher	cfc7adcbc5	fix: strict custom view paths (#12968)	2025-06-29 14:20:54 -04:00
Jacob Fletcher	f64a0aec5f	fix: remove unsupported path property from default document view configs (#12774) ... Customizing the `path` property on default document views is currently not supported, but the types suggest that it is. You can only provide a path to custom views. This PR ensures that `path` cannot be set on default views as expected. For example: ```ts import type { CollectionConfig } from 'payload' export const MyCollectionConfig: CollectionConfig = { // ... admin: { components: { views: { edit: { default: { path: '/' // THIS IS NOT ALLOWED! }, myCustomView: { path: '/edit', // THIS IS ALLOWED! Component: '/collections/CustomViews3/MyEditView.js#MyEditView', }, }, }, }, }, } ``` For background context, this was deeply explored in #12701. This is not planned, however, due to [performance and maintainability concerns](https://github.com/payloadcms/payload/pull/12701#issuecomment-2963926925), plus [there are alternatives to achieve this](https://github.com/payloadcms/payload/pull/12772). This PR also fixes and improves various jsdocs, and fixes a typo found in the docs.	2025-06-12 09:01:20 -04:00
Germán Jabloñski	2a929cf385	chore: fix all lint errors and add mechanisms to prevent them from appearing again (#12401) ... I think it's easier to review this PR commit by commit, so I'll explain it this way: ## Commits 1. [parallelize eslint script (still showing logs results in serial)](c9ac49c12d): Previously, `--concurrency 1` was added to the script to make the logs more readable. However, turborepo has an option specifically for these use cases: `--log-order=grouped` runs the tasks in parallel but outputs them serially. As a result, the lint script is now significantly faster. 2. [run pnpm lint:fix](9c128c276a) The auto-fix was run, which resolved some eslint errors that were slipped in due to the use of `no-verify`. Most of these were `perfectionist` fixes (property ordering) and the removal of unnecessary assertions. Starting with this PR, this won't happen again in the future, as we'll be verifying the linter in every PR across the entire codebase (see commit 7). 3. [fix eslint non-autofixable errors](700f412a33) All manual errors have been resolved except for the configuration errors addressed in commit 5. Most were React compiler violations, which have been disabled and commented out "TODO" for now. There's also an unused `use no memo` and a couple of `require` errors. 4. [move react-compiler linter to eslint-config package](4f7cb4d63a) To simplify the eslint configuration. My concern was that there would be a performance regression when used in non-react related packages, but none was experienced. This is probably because it only runs on .tsx files. 5. [remove redundant eslint config files and fix allowDefaultProject](a94347995a) The main feature introduced by `typescript-eslint` v8 was `projectService`, which automatically searches each file for the closest `tsconfig`, greatly simplifying configuration in monorepos ([source](https://typescript-eslint.io/blog/announcing-typescript-eslint-v8#project-service)). Once I moved `projectService` to `packages/eslint-config`, all the other configuration files could be easily removed. I confirmed that pnpm lint still works on individual packages. The other important change was that the pending eslint errors from commits 2 and 3 were resolved. That is, some files were giving the error: "[File] was not found by the project service. Consider either including it in the tsconfig.json or including it in allowDefaultProject." Below I copy the explanatory comment I left in the code: ```ts // This is necessary because `tsconfig.base.json` defines `"rootDir": "${configDir}/src"`, // And the following files aren't in src because they aren't transpiled. // This is typescript-eslint's way of adding files that aren't included in tsconfig. // See: https://typescript-eslint.io/troubleshooting/typed-linting/#i-get-errors-telling-me--was-not-found-by-the-project-service-consider-either-including-it-in-the-tsconfigjson-or-including-it-in-allowdefaultproject // The best practice is to have a tsconfig.json that covers ALL files and is used for // typechecking (with noEmit), and a `tsconfig.build.json` that is used for the build // (or alternatively, swc, tsup or tsdown). That's what we should ideally do, in which case // this hardcoded list wouldn't be necessary. Note that these files don't currently go // through ts, only through eslint. ``` 6. [Differentiate errors from warnings in VScode ESLint Rules](5914d2f48d) There's no reason to do that. If an eslint rule isn't an error, it should be disabled or converted to a warning. 7. [Disable skip lint, and lint over the entire repo now that it's faster](e4b28f1360) The GitHub action linted only the files that had changed in the PR. While this seems like a good idea, once exceptions were introduced with [skip lint], they opened the door to propagating more and more errors. Often, the linter was skipped, not because someone introduced new errors, but because they were trying to avoid those that had already crept in, sometimes accidentally introducing new ones. On the other hand, `pnpm lint` now runs in parallel (commit 1), so it's not that slow. Additionally, it runs in parallel with other GitHub actions like e2e tests, which take much longer, so it can't represent a bottleneck in CI. 8. [fix lint in next package](4506595f91) Small fix missing from commit 5 9. [Merge remote-tracking branch 'origin/main' into fix-eslint](563d4909c1) 10. [add again eslint.config.js in payload package](78f6ffcae7) The comment in the code explains it. Basically, after the merge from main, the payload package runs out of memory when linting, probably because it grew in recent PRs. That package will sooner or later collapse for our tooling, so we may have to split it. It's already too big. ## Future Actions - Resolve React compiler violations, as mentioned in commit 3. - Decouple the `tsconfig` used for typechecking and build across the entire monorepo (as explained in point 5) to ensure ts coverage even for files that aren't transpiled (such as scripts). - Remove the few remaining `eslint.config.js`. I had to leave the `richtext-lexical` and `next` ones for now. They could be moved to the root config and scoped to their packages, as we do for example with `templates/vercel-postgres/**`. However, I couldn't get it to work, I don't know why. - Make eslint in the test folder usable. Not only are we not linting `test` in CI, but now the `pnpm eslint .` command is so large that my computer freezes. If each suite were its own package, this would be solved, and dynamic codegen + git hooks to modify tsconfig.base.json wouldn't be necessary ([related](https://github.com/payloadcms/payload/pull/11984)).	2025-05-19 12:36:40 -03:00
Paul	e258cd73ef	feat: allow group fields to have an optional name (#12318) ... Adds the ability to completely omit `name` from group fields now so that they're entirely presentational. New config: ```ts import type { CollectionConfig } from 'payload' export const ExampleCollection: CollectionConfig = { slug: 'posts', fields: [ { label: 'Page header', type: 'group', // required fields: [ { name: 'title', type: 'text', required: true, }, ], }, ], } ``` will create <img width="332" alt="image" src="https://github.com/user-attachments/assets/10b4315e-92d6-439e-82dd-7c815a844035" /> but the data response will still be ``` { "createdAt": "2025-05-05T13:42:20.326Z", "updatedAt": "2025-05-05T13:42:20.326Z", "title": "example post", "id": "6818c03ce92b7f92be1540f0" } ``` Checklist: - [x] Added int tests - [x] Modify mongo, drizzle and graphql packages - [x] Add type tests - [x] Add e2e tests	2025-05-14 23:45:34 +00:00
Germán Jabloñski	97e2e77ff4	chore: run dev:generate-types (#11994)	2025-04-08 17:25:29 -03:00
Paul	acead1083b	feat: add support for interfaceName on radio and select fields to create reusable top level types (#11277) ... Adds support for `interfaceName` on radio and select fields. Adding this property will extract your provided options into a top level type for re-use.  Added types test to make sure assignment is consistent.	2025-02-19 13:51:03 +00:00
Sasha	117949b8d9	test: regenerate payload-types.ts for all test suites (#11238) ... Regenerates `payload-types.ts` for all test suites.	2025-02-18 00:45:59 +02:00
Sasha	4be410cc4f	test: add types testing for select and joins (#11138) ... Adds additional type testing for `select` and `joins` Local API properties to ensure we don't break those between changes	2025-02-13 18:11:31 +02:00
Germán Jabloñski	a304dc4b01	chore: make TypeScript strict in test folder. Simplify tsconfig (#10582) ... This PR makes the "test" folder strict in typescript. `pnpm build:test` before: Found 3275 errors in 174 files. `pnpm build:test` after: Found 4912 errors in 268 files. At some point we should bring that number to 0 and make it a requirement in the CI. Currently `pnpm build:test` is not run anywhere in the CI. Additionally, I took the opportunity to combine the duplicate configurations from `tsconfig.json` and `tsconfig.typecheck.json` using "extend". declaration, declarationMap and sourceMap have been removed as they have no reason to exist in noEmit. The settings I left in `tsconfig.typecheck.json` are ones that I'm not sure why they are there. Perhaps the file could be removed or at least reduced further.	2025-01-14 20:00:00 -03:00
Sasha	f09ee0b84b	ci: add types testing with tstyche (#9803) ... As proposed here https://github.com/payloadcms/payload/pull/9782#issuecomment-2522090135 with additional testing of our types we can be more sure that we don't break them between updates. This PR already adds types testing for most Local API methods 6beb921c2e/test/types/types.spec.ts but new tests for types can be easily added, either to that same file or you can create `types.spec.ts` in any other test folder. The new test folder uses `strict: true` to ensure our types do not break with it. --------- Co-authored-by: Tom Mrazauskas <tom@mrazauskas.de>	2024-12-07 16:38:25 +02:00