We are suspecting that operations within those esbuild scripts are not
awaited properly - potentially causing issues in the publish script,
publishing the next package without any built .js files
## Description
Currently, the Payload doesn't support to extend the Allowed Headers in
CORS context. With this PR, `cors` property can be an object with
`origins` and `headers`.
- [x] I have read and understand the
[CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md)
document in this repository.
## Type of change
- [ ] Chore (non-breaking change which does not add functionality)
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [ ] Change to the
[templates](https://github.com/payloadcms/payload/tree/main/templates)
directory (does not affect core functionality)
- [ ] Change to the
[examples](https://github.com/payloadcms/payload/tree/main/examples)
directory (does not affect core functionality)
- [x] This change requires a documentation update
## Checklist:
- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] Existing test suite passes locally with my changes
- [x] I have made corresponding changes to the documentation
Co-authored-by: Alessio Gravili <alessio@gravili.de>
- Improves color contrast of various components in the admin panel.
- Adjusts placement of field error tooltips for consistency.
- Corrects misaligned modals.
- Fixes issue where `admin.layout: vertical` was not being applied to
`radio` fields.
## Description
Improves the status pill in the version archive and version comparison
views.
- [X] I have read and understand the
[CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md)
document in this repository.
## Type of change
- [X] New feature (non-breaking change which adds functionality)
## Checklist:
- [X] Existing test suite passes locally with my changes
**BREAKING:**
- Upgrades minimum supported @types/react version from
npm:types-react@19.0.0-beta.2 to npm:types-react@19.0.0-rc.0
- Upgrades minimum supported @types/react-dom version from
npm:types-react-dom@19.0.0-beta.2 to npm:types-react-dom@19.0.0-rc.0
- Upgrades minimum supported react and react-dom version from
19.0.0-rc-f994737d14-20240522 to 19.0.0-rc-6230622a1a-20240610
- 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!
## Description
Exports `getSiblingData`, `getDataByPath`, `reduceFieldsToValues`, and
`unflatten` from `payload`. These utilities were previously accessible
using direct import paths from `@payloadcms/ui`—but this is no longer
advised since moving to a pre-bundled UI library pattern. Instead of
simply exporting these from the `@payloadcms/ui` package, these exports
have been moved to Payload itself to provision for use outside of React
environments.
This is considered a breaking change. If you were previously importing
any of these utilities, the imports paths have changed as follows:
Old:
```ts
import { getSiblingData, getDataByPath, reduceFieldsToValues } from '@payloadcms/ui/forms/Form'
import { unflatten } from '@payloadcms/ui/utilities'
```
New:
```ts
import { getSiblingData, getDataByPath, reduceFieldsToValues, unflatten } from 'payload/shared'
```
The `is-buffer` dependency was also removed in this PR.
- [x] I have read and understand the
[CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md)
document in this repository.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## Checklist:
- [x] Existing test suite passes locally with my changes
## Description
BREAKING CHANGE: Color values have changed and will have different
contrasts. If you use any of Payload's colors in your apps, you may need
to adjust your use of them to maintain proper styling/accessibility.
Colors palettes changed:
- `--theme-success-*`
- `--theme-error-*`
- `--theme-warning-*`
- `--color-success-*`
- `--color-error-*`
- `--color-warning-*`
- `--color-blue-*`
Updates the color palette used throughout Payload to be more consistent
between dark and light values. Contrast values are now more in line with
the `theme-elevation` contrasts. Some adjustments to the Toast
components as well to match light/dark mode better.
- [x] I have read and understand the
[CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md)
document in this repository.
## Type of change
<!-- Please delete options that are not relevant. -->
- [x] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [x] Change to the
[templates](https://github.com/payloadcms/payload/tree/main/templates)
directory (does not affect core functionality)
- [x] Change to the
[examples](https://github.com/payloadcms/payload/tree/main/examples)
directory (does not affect core functionality)
## Checklist:
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [ ] Existing test suite passes locally with my changes
- [ ] I have made corresponding changes to the documentation
**BREAKING:** The minimum required Next.js version has been bumped from
`15.0.0-rc.0` to `15.0.0-canary.53`. This is because the way client
components are represented changed somewhere between those versions, and
it is not feasible to support both versions in our RSC detection logic.
## Description
Adds `loginWithUsername` option to auth config. When set to true, it
will inject an `username` field into the collection config which
replaces the `email` field in the UI. The `email` field is still
required but not unique.
The `username` field can be extended by passing a field named `username`
to your auth collection. Anything added to this field will be combined
with the initial field.
- [X] I have read and understand the
[CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md)
document in this repository.
## Type of change
- [X] New feature (non-breaking change which adds functionality)
## Checklist:
- [X] Existing test suite passes locally with my changes
---------
Co-authored-by: Jarrod Flesch <jarrodmflesch@gmail.com>
Removes PayloadRequestWithData in favour of just PayloadRequest with
optional types for `data` and `locale`
`addDataAndFileToRequest` and `addLocalesToRequestFromData` now takes in
a single argument instead of an object
```ts
// before
await addDataAndFileToRequest({ request: req })
addLocalesToRequestFromData({ request: req })
// current
await addDataAndFileToRequest(req)
addLocalesToRequestFromData(req)
```
---------
Co-authored-by: Paul Popus <paul@nouance.io>
## Description
Some authentication strategies may need to set headers for responses,
such as updating cookies via a refresh token, and similar. This PR
extends Payload's auth strategy capabilities with a manner of
accomplishing this.
This is a breaking change if you have custom authentication strategies
in Payload's 3.0 beta. But it's a simple one to update.
Instead of your custom auth strategy returning the `user`, now you must
return an object with a `user` property.
This is because you can now also optionally return `responseHeaders`,
which will be returned by Payload API responses if you define them in
your auth strategies. This can be helpful for cases where you need to
set cookies and similar, directly within your auth strategies.
Before:
```ts
return user
```
After:
```ts
return { user }
```
Adds the ability to set response headers by using a new
`uploads.modifyResponseHeaders` property. You could previously do this
in Express in Payload v2.
You can do this like so:
```ts
upload: {
modifyResponseHeaders: ({ headers }) => {
headers.set('Cache-Control', 'public, max-age=86400')
return headers
}
},
```
**BREAKING:**
- Type narrowing for `relationTo` props on filterOptions, relationship
fields and upload fields
- Type narrowing for arguments of lexical relationship, link and upload
features
Allows `upload.handlers` to mutate the request. This can be useful when
you want to adjust headers on the request but do not want to return a
new response.
**BREAKING:** All `@payloadcms/ui/client` exports have been renamed to
`@payloadcms/ui`. A simple find & replace across your entire project
will be enough to migrate. This change greatly improves import
auto-completions in IDEs which lack proper support for package.json
exports, like Webstorm.
# 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>
