18 Commits

Author	SHA1	Message	Date
T. R. Bernstein	4a5f01a78f	chore: Update code to new repo	2025-10-08 23:27:45 +02:00
Paul	cb6a73e1b4	feat(storage-*): include modified headers into the response headers of files when using adapters (#12096) ... This PR makes it so that `modifyResponseHeaders` is supported in our adapters when set on the collection config. Previously it would be ignored. This means that users can now modify or append new headers to what's returned by each service. ```ts import type { CollectionConfig } from 'payload' export const Media: CollectionConfig = { slug: 'media', upload: { modifyResponseHeaders: ({ headers }) => { const newHeaders = new Headers(headers) // Copy existing headers newHeaders.set('X-Frame-Options', 'DENY') // Set new header return newHeaders }, }, } ``` Also adds support for `void` return on the `modifyResponseHeaders` function in the case where the user just wants to use existing headers and doesn't need more control. eg: ```ts import type { CollectionConfig } from 'payload' export const Media: CollectionConfig = { slug: 'media', upload: { modifyResponseHeaders: ({ headers }) => { headers.set('X-Frame-Options', 'DENY') // You can directly set headers without returning }, }, } ``` Manual testing checklist (no CI e2es setup for these envs yet): - [x] GCS - [x] S3 - [x] Azure - [x] UploadThing - [x] Vercel Blob --------- Co-authored-by: James <james@trbl.design>	2025-07-10 08:00:26 -07: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
Germán Jabloñski	97e2e77ff4	chore: run dev:generate-types (#11994)	2025-04-08 17:25:29 -03:00
Sasha	b540da53ec	feat(storage-*): large file uploads on Vercel (#11382) ... Currently, usage of Payload on Vercel has a limitation - uploads are limited by 4.5MB file size. This PR allows you to pass `clientUploads: true` to all existing storage adapters * Storage S3 * Vercel Blob * Google Cloud Storage * Uploadthing * Azure Blob And then, Payload will do uploads on the client instead. With the S3 Adapter it uses signed URLs and with Vercel Blob it does this - https://vercel.com/guides/how-to-bypass-vercel-body-size-limit-serverless-functions#step-2:-create-a-client-upload-route. Note that it doesn't mean that anyone can now upload files to your storage, it still does auth checks and you can customize that with `clientUploads.access` https://github.com/user-attachments/assets/5083c76c-8f5a-43dc-a88c-9ddc4527d91c Implements https://github.com/payloadcms/payload/discussions/7569 feature request.	2025-02-26 21:59:34 +02: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
Alessio Gravili	c7138b9aab	chore: update generated types for all test suites (#9577)	2024-11-27 20:36:37 +00:00
Elliot DeNolf	4690cd819a	feat(storage-uploadthing)!: upgrade to v7 (#8346) ... Upgrade uploadthing to v7 The `options` that can be passed to the plugin now mirror the `UTApiOptions` of v7. The most notable change is to pass `token` with `process.env.UPLOADTHING_TOKEN` instead of `apiKey` with `process.env.UPLOADTHING_SECRET`. ```diff options: { - apiKey: process.env.UPLOADTHING_SECRET, + token: process.env.UPLOADTHING_TOKEN, acl: 'public-read', },	2024-11-13 21:27:02 +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	90b7b20699	feat!: beta-next (#7620) ... This PR makes three major changes to the codebase: 1. [Component Paths](#component-paths) Instead of importing custom components into your config directly, they are now defined as file paths and rendered only when needed. That way the Payload config will be significantly more lightweight, and ensures that the Payload config is 100% server-only and Node-safe. Related discussion: https://github.com/payloadcms/payload/discussions/6938 2. [Client Config](#client-config) Deprecates the component map by merging its logic into the client config. The main goal of this change is for performance and simplification. There was no need to deeply iterate over the Payload config twice, once for the component map, and another for the client config. Instead, we can do everything in the client config one time. This has also dramatically simplified the client side prop drilling through the UI library. Now, all components can share the same client config which matches the exact shape of their Payload config (with the exception of non-serializable props and mapped custom components). 3. [Custom client component are no longer server-rendered](#custom-client-components-are-no-longer-server-rendered) Previously, custom components would be server-rendered, no matter if they are server or client components. Now, only server components are rendered on the server. Client components are automatically detected, and simply get passed through as `MappedComponent` to be rendered fully client-side. ## Component Paths Instead of importing custom components into your config directly, they are now defined as file paths and rendered only when needed. That way the Payload config will be significantly more lightweight, and ensures that the Payload config is 100% server-only and Node-safe. Related discussion: https://github.com/payloadcms/payload/discussions/6938 In order to reference any custom components in the Payload config, you now have to specify a string path to the component instead of importing it. Old: ```ts import { MyComponent2} from './MyComponent2.js' admin: { components: { Label: MyComponent2 }, }, ``` New: ```ts admin: { components: { Label: '/collections/Posts/MyComponent2.js#MyComponent2', // <= has to be a relative path based on a baseDir configured in the Payload config - NOT relative based on the importing file }, }, ``` ### Local API within Next.js routes Previously, if you used the Payload Local API within Next.js pages, all the client-side modules are being added to the bundle for that specific page, even if you only need server-side functionality. This `/test` route, which uses the Payload local API, was previously 460 kb. It is now down to 91 kb and does not bundle the Payload client-side admin panel anymore. All tests done [here](https://github.com/payloadcms/payload-3.0-demo/tree/feat/path-test) with beta.67/PR, db-mongodb and default richtext-lexical: **dev /admin before:**  **dev /admin after:**  --- **dev /test before:**  **dev /test after:**  --- **build before:**  **build after::**  ### Usage of the Payload Local API / config outside of Next.js This will make it a lot easier to use the Payload config / local API in other, server-side contexts. Previously, you might encounter errors due to client files (like .scss files) not being allowed to be imported. ## Client Config Deprecates the component map by merging its logic into the client config. The main goal of this change is for performance and simplification. There was no need to deeply iterate over the Payload config twice, once for the component map, and another for the client config. Instead, we can do everything in the client config one time. This has also dramatically simplified the client side prop drilling through the UI library. Now, all components can share the same client config which matches the exact shape of their Payload config (with the exception of non-serializable props and mapped custom components). This is breaking change. The `useComponentMap` hook no longer exists, and most component props have changed (for the better): ```ts const { componentMap } = useComponentMap() // old const { config } = useConfig() // new ``` The `useConfig` hook has also changed in shape, `config` is now a property _within_ the context obj: ```ts const config = useConfig() // old const { config } = useConfig() // new ``` ## Custom Client Components are no longer server rendered Previously, custom components would be server-rendered, no matter if they are server or client components. Now, only server components are rendered on the server. Client components are automatically detected, and simply get passed through as `MappedComponent` to be rendered fully client-side. The benefit of this change: Custom client components can now receive props. Previously, the only way for them to receive dynamic props from a parent client component was to use hooks, e.g. `useFieldProps()`. Now, we do have the option of passing in props to the custom components directly, if they are client components. This will be simpler than having to look for the correct hook. This makes rendering them on the client a little bit more complex, as you now have to check if that component is a server component (=> already has been rendered) or a client component (=> not rendered yet, has to be rendered here). However, this added complexity has been alleviated through the easy-to-use `<RenderMappedComponent />` helper. This helper now also handles rendering arrays of custom components (e.g. beforeList, beforeLogin ...), which actually makes rendering custom components easier in some cases. ## Misc improvements This PR includes misc, breaking changes. For example, we previously allowed unions between components and config object for the same property. E.g. for the custom view property, you were allowed to pass in a custom component or an object with other properties, alongside a custom component. Those union types are now gone. You can now either pass an object, or a component. The previous `{ View: MyViewComponent}` is now `{ View: { Component: MyViewComponent} }` or `{ View: { Default: { Component: MyViewComponent} } }`. This dramatically simplifies the way we read & process those properties, especially in buildComponentMap. We can now simply check for the existence of one specific property, which always has to be a component, instead of running cursed runtime checks on a shared union property which could contain a component, but could also contain functions or objects.   - [x] I have read and understand the [CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md) document in this repository. --------- Co-authored-by: PatrikKozak <patrik@payloadcms.com> Co-authored-by: Paul <paul@payloadcms.com> Co-authored-by: Paul Popus <paul@nouance.io> Co-authored-by: Jacob Fletcher <jacobsfletch@gmail.com> Co-authored-by: James <james@trbl.design>	2024-08-13 12:54:33 -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
Jacob Fletcher	9e76c8f4e3	feat!: prebundle payload, ui, richtext-lexical (#6579) ... # Breaking Changes ### New file import locations Exports from the `payload` package have been _significantly_ cleaned up. Now, just about everything is able to be imported from `payload` directly, rather than an assortment of subpath exports. This means that things like `import { buildConfig } from 'payload/config'` are now just imported via `import { buildConfig } from 'payload'`. The mental model is significantly simpler for developers, but you might need to update some of your imports. Payload now exposes only three exports: 1. `payload` - all types and server-only Payload code 2. `payload/shared` - utilities that can be used in either the browser or in Node environments 3. `payload/node` - heavy utilities that should only be imported in Node scripts and never be imported into bundled code like Next.js ### UI library pre-bundling With this release, we've dramatically sped up the compile time for Payload by pre-bundling our entire UI package for use inside of the Payload admin itself. There are new exports that should be used within Payload custom components: 1. `@payloadcms/ui/client` - all client components 2. `@payloadcms/ui/server` - all server components For all of your custom Payload admin UI components, you should be importing from one of these two pre-compiled barrel files rather than importing from the more deeply nested exports directly. That will keep compile times nice and speedy, and will also make sure that the bundled JS for your admin UI is kept small. For example, whereas before, if you imported the Payload `Button`, you would have imported it like this: ```ts import { Button } from '@payloadcms/ui/elements/Button' ``` Now, you would import it like this: ```ts import { Button } from '@payloadcms/ui/client' ``` This is a significant DX / performance optimization that we're pretty pumped about. However, if you are importing or re-using Payload UI components _outside_ of the Payload admin UI, for example in your own frontend apps, you can import from the individual component exports which will make sure that the bundled JS is kept to a minimum in your frontend apps. So in your own frontend, you can continue to import directly to the components that you want to consume rather than importing from the pre-compiled barrel files. Individual component exports will now come with their corresponding CSS and everything will work perfectly as-expected. ### Specific exports have changed - `'@payloadcms/ui/templates/Default'` and `'@payloadcms/ui/templates/Minimal`' are now exported from `'@payloadcms/next/templates'` - Old: `import { LogOut } from '@payloadcms/ui/icons/LogOut'` new: `import { LogOutIcon } from '@payloadcms/ui/icons/LogOut'` ## Background info In effort to make local dev as fast as possible, we need to import as few files as possible so that the compiler has less to process. One way we've achieved this in the Admin Panel was to _remove_ all .scss imports from all components in the `@payloadcms/ui` module using a build process. This stripped all `import './index.scss'` statements out of each component before injecting them into `dist`. Instead, it bundles all of the CSS into a single `main.css` file, and we import _that_ at the root of the app. While this concept is _still_ the right solution to the problem, this particular approach is not viable when using these components outside the Admin Panel, where not only does this root stylesheet not exist, but where it would also bloat your app with unused styles. Instead, we need to _keep_ these .scss imports in place so they are imported directly alongside your components, as expected. Then, we need create a _new_ build step that _separately_ compiles the components _without_ their stylesheets—this way your app can consume either as needed from the new `client` and `server` barrel files within `@payloadcms/ui`, i.e. from within `@payloadcms/next` and all other admin-specific packages and plugins. This way, all other applications will simply import using the direct file paths, just as they did before. Except now they come with stylesheets. And we've gotten a pretty awesome initial compilation performance boost. --------- Co-authored-by: James <james@trbl.design> Co-authored-by: Alessio Gravili <alessio@gravili.de>	2024-06-17 14:25:36 -04:00
Elliot DeNolf	7309d474ee	feat!: type auto-generation (#6657) ... Types are now auto-generated by default. You can opt-out of this behavior by setting: ```ts buildConfig({ // Rest of config typescript: { autoGenerate: false }, }) ```	2024-06-10 13:42:44 -04:00
Elliot DeNolf	ed880d5018	feat: storage-uploadthing package (#6316) ... Co-authored-by: James <james@trbl.design>	2024-05-10 17:05:35 -04:00
Alessio Gravili	f7a2cf96b9	chore: properly working generated types within tests (#6288)	2024-05-09 17:12:51 -04:00