18 Commits

Author	SHA1	Message	Date
T. R. Bernstein	4a5f01a78f	chore: Update code to new repo	2025-10-08 23:27:45 +02:00
Jarrod Flesch	dc732b8f52	fix(ui): populate nested fields for enableListViewSelectAPI (#13827) ... Fixes an issue with the new experimental `enableListViewSelectAPI` config option. Group fields were not populating properly in the list view ### Before (incorrect) ```ts { group.field: true } ``` ### After (correct) ```ts { group: { field: true } } ```	2025-09-16 21:23:08 +00:00
Jarrod Flesch	a22f27de1c	test: stabilize frequent fails (#13318) ... Adjusts tests that "flake" frequently.	2025-07-30 05:52:01 -07:00
Jacob Fletcher	d7a3faa4e9	fix(ui): properly sync search params to user preferences (#13200) ... Some search params within the list view do not properly sync to user preferences, and visa versa. For example, when selecting a query preset, the `?preset=123` param is injected into the URL and saved to preferences, but when reloading the page without the param, that preset is not reactivated as expected. ### Problem The reason this wasn't working before is that omitting this param would also reset prefs. It was designed this way in order to support client-side resets, e.g. clicking the query presets "x" button. This pattern would never work, however, because this means that every time the user navigates to the list view directly, their preference is cleared, as no param would exist in the query. Note: this is not an issue with _all_ params, as not all are handled in the same way. ### Solution The fix is to use empty values instead, e.g. `?preset=`. When the server receives this, it knows to clear the pref. If it doesn't exist at all, it knows to load from prefs. And if it has a value, it saves to prefs. On the client, we sanitize those empty values back out so they don't appear in the URL in the end. This PR also refactors much of the list query context and its respective provider to be significantly more predictable and easier to work with, namely: - The `ListQuery` type now fully aligns with what Payload APIs expect, e.g. `page` is a number, not a string - The provider now receives a single `query` prop which matches the underlying context 1:1 - Propagating the query from the server to the URL is significantly more predictable - Any new props that may be supported in the future will automatically work - No more reconciling `columns` and `listPreferences.columns`, its just `query.columns` --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1210827129744922	2025-07-18 09:29:26 -04:00
Paul	9c5adba5c6	chore: add eslint rule to ignore default exports in test suite configs (#12655) ... Adds eslint rule `no-restricted-exports` with value `off` for payload config files inside our `test` suite since we have to export with default from those	2025-06-17 09:10:42 -04:00
Jarrod Flesch	337f6188da	feat: optionally exclude collection documents from appearing in browse-by-folder (#12654) ... Adds configurations for browse-by-folder document results. This PR **does NOT** allow for filtering out folders on a per collection basis. That will be addressed in a future PR 👍 ### Disable browse-by-folder all together ```ts type RootFoldersConfiguration = { /** * If true, the browse by folder view will be enabled * * @default true */ browseByFolder?: boolean // ...rest of type } ``` ### Remove document types from appearing in the browse by folder view ```ts type CollectionFoldersConfiguration = | boolean | { /** * If true, the collection documents will be included in the browse by folder view * * @default true */ browseByFolder?: boolean } ``` ### Misc Fixes https://github.com/payloadcms/payload/issues/12631 where adding folders.collectionOverrides was being set on the client config - it should be omitted. Fixes an issue where `baseListFilters` were not being respected.	2025-06-04 13:22:26 -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
Jacob Fletcher	373f6d1032	fix(ui): nested fields disappear when manipulating rows in form state (#11906) ... Continuation of #11867. When rendering custom fields nested within arrays or blocks, such as the Lexical rich text editor which is treated as a custom field, these fields will sometimes disappear when form state requests are invoked sequentially. This is especially reproducible on slow networks. This is different from the previous PR in that this issue is caused by adding _rows_ back-to-back, whereas the previous issue was caused when adding a single row followed by a change to another field. Here's a screen recording demonstrating the issue: https://github.com/user-attachments/assets/5ecfa9ec-b747-49ed-8618-df282e64519d The problem is that `requiresRender` is never sent in the form state request for row 2. This is because the [task queue](https://github.com/payloadcms/payload/pull/11579) processes tasks within a single `useEffect`. This forces React to batch the results of these tasks into a single rendering cycle. So if request 1 sets state that request 2 relies on, request 2 will never use that state since they'll execute within the same lifecycle. Here's a play-by-play of the current behavior: 1. The "add row" event is dispatched a. This sets `requiresRender: true` in form state 1. A form state request is sent with `requiresRender: true` 1. While that request is processing, another "add row" event is dispatched a. This sets `requiresRender: true` in form state b. This adds a form state request into the queue 1. The initial form state request finishes a. This sets `requiresRender: false` in form state 1. The next form state request that was queued up in 3b is sent with `requiresRender: false` a. THIS IS EXPECTED, BUT SHOULD ACTUALLY BE `true`!! To fix this this, we need to ensure that the `requiresRender` property is persisted into the second request instead of overridden. To do this, we can add a new `serverPropsToIgnore` to form state which is read when the processing results from the server. So if `requiresRender` exists in `serverPropsToIgnore`, we do not merge it. This works because we actually mutate form state in between requests. So request 2 can read the results from request 1 without going through an additional rendering cycle. Here's a play-by-play of the fix: 1. The "add row" event is dispatched a. This sets `requiresRender: true` in form state b. This adds a task in the queue to mutate form state with `requiresRender: true` 1. A form state request is sent with `requiresRender: true` 1. While that request is processing, another "add row" event is dispatched a. This sets `requiresRender: true` in form state AND `serverPropsToIgnore: [ "requiresRender" ]` c. This adds a form state request into the queue 1. The initial form state request finishes a. This returns `requiresRender: false` from the form state endpoint BUT IS IGNORED 1. The next form state request that was queued up in 3c is sent with `requiresRender: true`	2025-04-01 09:54:22 -04:00
Jacob Fletcher	ac1e3cf69e	feat(ui): form state queues (#11579) ... Implements a form state task queue. This will prevent onChange handlers within the form component from processing unnecessarily often, sometimes long after the user has stopped making changes. This leads to a potentially huge number of network requests if those changes were made slower than the debounce rate. This is especially noticeable on slow networks. Does so through a new `useQueue` hook. This hook maintains a stack of events that need processing but only processes the final event to arrive. Every time a new event is pushed to the stack, the currently running process is aborted (if any), and that event becomes the next in the queue. This results in a shocking reduction in the time it takes between final change to form state and the final network response, from ~1.5 minutes to ~3 seconds (depending on the scenario, see below). This likely fixes a number of existing open issues. I will link those issues here once they are identified and verifiably fixed. Before: I'm typing slowly here to ensure my changes aren't debounce by the form. There are a total of 60 characters typed, triggering 58 network requests and taking around 1.5 minutes to complete after the final change was made. https://github.com/user-attachments/assets/49ba0790-a8f8-4390-8421-87453ff8b650 After: Here there are a total of 69 characters typed, triggering 11 network requests and taking only about 3 seconds to complete after the final change was made. https://github.com/user-attachments/assets/447f8303-0957-41bd-bb2d-9e1151ed9ec3	2025-03-10 21:25:14 -04:00
Jarrod Flesch	48115311e7	fix(ui): incorrect error states (#11574) ... Fixes https://github.com/payloadcms/payload/issues/11568 ### What? Out of sync errors states - Collaspibles & Tabs were not reporting accurate child error counts - Arrays could get into a state where they would not update their error states - Slight issue with toasts ### Tabs & Collapsibles The logic for determining matching field paths was not functioning as intended. Fields were attempting to match with paths such as `_index-0` which will not work. ### Arrays The form state was not updating when the server sent back errorPaths. This PR adds `errorPaths` to `serverPropsToAccept`. ### Toasts Some toasts could report errors in the form of `my > > error`. This ensures they will be `my > error` ### Misc Removes 2 files that were not in use: - `getFieldStateFromPaths.ts` - `getNestedFieldState.ts`	2025-03-06 14:02:10 -05:00
Alessio Gravili	e6fea1d132	fix: localized fields within block references were not handled properly if any parent is localized (#11207) ... The `localized` properly was not stripped out of referenced block fields, if any parent was localized. For normal fields, this is done in sanitizeConfig. As the same referenced block config can be used in both a localized and non-localized config, we are not able to strip it out inside sanitizeConfig by modifying the block config. Instead, this PR had to bring back tedious logic to handle it everywhere the `field.localized` property is accessed. For backwards-compatibility, we need to keep the existing sanitizeConfig logic. In 4.0, we should remove it to benefit from better test coverage of runtime field.localized handling - for now, this is done for our test suite using the `PAYLOAD_DO_NOT_SANITIZE_LOCALIZED_PROPERTY` flag.	2025-02-17 19:50:32 +00:00
Alessio Gravili	257cad71ce	chore: fix eslint wasn't running in test dir (#11036) ... This PR fixes 2 eslint config issues that prevented it from running in our test dir - spec files were ignored by the root eslint config. This should have only ignored spec files within our packages, as they are ignored by the respective package tsconfigs - defining the payload plugin crashed eslint in our test dir, as it was already defined in the root eslint config it was inheriting	2025-02-07 03:54:26 +00:00
Elliot DeNolf	040c2a2fbb	chore(eslint): FlatConfig type deprecated, set to Config	2024-09-20 22:46:40 -04:00
Alessio Gravili	86fdad0bb8	chore: significantly improve eslint performance, lint and prettier everything	2024-08-29 21:25:50 -04:00
Alessio Gravili	bc367ab73c	chore(eslint): upgrade to typescript-eslint v8, upgrade all eslint packages (#7082)	2024-08-29 16:27:58 -04:00
Alessio Gravili	e5d5126d14	chore: regenerate all types in test dir, and add to eslint & prettier ignores	2024-07-11 15:59:38 -04:00
Alessio Gravili	83fd4c6622	chore: run lint and prettier on entire codebase	2024-07-11 15:27:01 -04:00
Alessio Gravili	1038e1c228	chore: move to eslint v9 (#7041) ... - Upgrades eslint from v8 to v9 - Upgrades all other eslint packages. We will have to do a new full-project lint, as new rules have been added - Upgrades husky from v8 to v9 - Upgrades lint-staged from v14 to v15 - Moves the old .eslintrc.cjs file format to the new eslint.config.js flat file format. Previously, we were very specific regarding which rules are applied to which files. Now that `extends` is no longer a thing, I have to use deepMerge & imports instead. This is rather uncommon and is not a documented pattern - e.g. typescript-eslint docs want us to add the default typescript-eslint rules to the top-level & then disable it in files using the disable-typechecked config. However, I hate this opt-out approach. The way I did it here adds a lot of clarity as to which rules are applied to which files, and is pretty easy to read. Much less black magic ## .eslintignore These files are no longer supported (see https://eslint.org/docs/latest/use/configure/migration-guide#ignoring-files). I moved the entries to the ignores property in the eslint config. => one less file in each package folder!	2024-07-09 09:50:37 -04:00