2024-03-06 11:38:26 -05:00
import bundleAnalyzer from '@next/bundle-analyzer'
feat(plugin-sentry): update plugin to 3.0 (#8613)
Updates the plugin to 3.0
Test:
```sh
NEXT_PUBLIC_SENTRY_DSN=<DSN here> pnpm dev plugin-sentry
```
Example:
```ts
sentryPlugin({
options: {
captureErrors: [400, 403],
context: ({ defaultContext, req }) => {
return {
...defaultContext,
tags: {
locale: req.locale,
},
}
},
debug: true,
},
Sentry,
})
```
2024-10-09 21:26:58 +03:00
import { withSentryConfig } from '@sentry/nextjs'
2025-12-09 10:59:20 -08:00
import { withPayload } from './packages/next/src/withPayload/withPayload.js'
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
import path from 'path'
import { fileURLToPath } from 'url'
const _ _filename = fileURLToPath ( import . meta . url )
const dirname = path . dirname ( _ _filename )
2024-03-08 10:56:13 -05:00
2024-03-06 11:38:26 -05:00
const withBundleAnalyzer = bundleAnalyzer ( {
2024-02-16 11:27:23 -05:00
enabled : process . env . ANALYZE === 'true' ,
} )
feat(plugin-sentry): update plugin to 3.0 (#8613)
Updates the plugin to 3.0
Test:
```sh
NEXT_PUBLIC_SENTRY_DSN=<DSN here> pnpm dev plugin-sentry
```
Example:
```ts
sentryPlugin({
options: {
captureErrors: [400, 403],
context: ({ defaultContext, req }) => {
return {
...defaultContext,
tags: {
locale: req.locale,
},
}
},
debug: true,
},
Sentry,
})
```
2024-10-09 21:26:58 +03:00
const config = withBundleAnalyzer (
2025-03-11 09:45:13 -06:00
withPayload (
{
feat(next): prevent admin panel errors when cacheComponents is enabled (#16020)
Fixes https://github.com/payloadcms/payload/issues/8897, addresses
https://github.com/payloadcms/payload/discussions/14460
Adds initial support for Next.js `cacheComponents` so users who enable
it for their frontend don't get errors from the Payload admin panel.
This PR addresses the obvious breakage but does not guarantee full
compatibility - see the "Known Limitations" section below.
When `cacheComponents` is enabled in `next.config`, Next.js throws "Data
that blocks navigation was accessed outside of `<Suspense>`" errors
because the admin layout reads cookies, headers, and does auth queries
at the top level. This prevents users from enabling `cacheComponents` at
all if Payload is in the same Next.js app.
The fix has two parts. First, `withPayload` now detects
`cacheComponents` in the Next.js config and sets a
`PAYLOAD_CACHE_COMPONENTS_ENABLED` env var. Second, `RootLayout` reads
that env var and conditionally wraps its content in `<Suspense
fallback={null}>` above the `<html>` tag, which suppresses the errors.
When `cacheComponents` is not enabled, the Suspense is not used at all
and behavior is identical to before.
## Known Limitations
These are all caused by Next.js's `cacheComponents` and likely cannot be
fixed from our side.
### Page flash on hard refresh
When `cacheComponents` is enabled, hard refresh shows a brief gray flash
before the admin panel appears. Without `cacheComponents` there is no
flash. There is no per-route opt-out for this behavior. Related issue:
https://github.com/vercel/next.js/issues/86739
### HTTP status codes (404 returns 200)
With `cacheComponents`, `notFound()` returns HTTP 200 instead of 404.
This happens because the Suspense boundary above `<html>` causes Next.js
to commit response headers (with status 200) before `notFound()` runs
inside the suspended content. The not-found UI still renders correctly -
only the HTTP status code is wrong. This is a [documented Next.js
streaming
limitation](https://nextjs.org/docs/app/api-reference/file-conventions/loading#status-codes).
### DOM accumulation breaks Playwright selectors
When `cacheComponents` is enabled, Next.js wraps route segments in
React's `<Activity>` component, keeping up to 3 previously visited pages
in the DOM with `display: none !important` instead of unmounting them.
This means Playwright selectors like `page.locator('#field-title')`
resolve to multiple elements (the visible one and hidden copies from
cached pages), causing strict mode violations. This is a [known
issue](https://github.com/vercel/next.js/issues/86577) affecting all
Next.js apps using `cacheComponents` with Playwright.
Because of this, we cannot reliably run our e2e test suite with
`cacheComponents` enabled. Adapting the test suite would require
rewriting a large number of selectors across hundreds of tests - most of
our e2e tests use `page.locator()` with ID selectors, which would all
break when Activity duplicates the DOM. Until the Next.js team provides
a per-route opt-out for Activity (which they are [actively
exploring](https://github.com/vercel/next.js/issues/86577#issuecomment-3801284197)),
we cannot _guarantee_ full admin panel compatibility beyond the initial
error suppression this PR provides.
2026-03-26 10:17:41 -07:00
cacheComponents : process . env . PAYLOAD _CACHE _COMPONENTS === 'true' ,
fix: basePath not working properly with admin routes (#14967)
This PR adds a base-path test suite, updates the formatAdminURL helper
function.
The helper function allows you to create routes inside the admin panel
that take `basePath` into account when set.
There are a lot of touched files here, most have the same treatment.
## API URL construction changes
Previously we were appending the basePath in the default api
configuration. That is no longer the case and is more predictable to use
the helper function that will generate a correct path/url.
## Admin URL construction changes
The default admin route differed from the default api route, the default
admin route did not prepend the basePath. The reason it did not/should
not, is because `usePathname` from NextJS excludes basePath.
So if we were to prepend it to `routes.admin` and then for example use
`pathname.startsWith(config.routes.admin)` it would always return false
when using a basePath, since `/route` will never start with
`/basePath/route`.
Also, when you do something like `router.push(/adminRoute)` NextJS will
prepend the basePath and push you to `/basePath/adminRoute`. If we
prepended it in the config it would push you to
`/basePath/basePath/adminRoute`.
## Helper function usage
The helper is especially useful for plugin work, this way your plugin
will generate correct urls for users using basePath.
Before we were doing:
```ts
// worked because we prepended basePath to apiRoute
const apiURL = `${serverURL}${apiRoute}/collections/${slug}/${id}`
// never worked since basePath was never prepended to adminRoute
const adminURL = `${serverURL}${adminRoute}/collections/${slug}/${id}`
```
Now we can do:
```ts
import { formatAdminURL } from 'payload/shared'
// Admin url example
const adminURL = formatAdminURL({
adminRoute: config.routes.admin,
path: `/collections/${slug}/${id}`,
})
// API url example
const apiURL = formatAdminURL({
apiRoute: config.routes.api,
path: `/collections/${slug}/${id}`,
// serverURL, when supplied returns a full url
})
```
If you pass `serverURL` the result will be a full URL. If excluded the
result will be a relative path.
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2025-12-19 11:13:21 -05:00
basePath : process . env ? . NEXT _BASE _PATH || undefined ,
2025-03-11 09:45:13 -06:00
typescript : {
ignoreBuildErrors : true ,
} ,
experimental : {
fullySpecified : true ,
serverActions : {
bodySizeLimit : '5mb' ,
2024-03-04 11:58:23 -05:00
} ,
2025-03-11 09:45:13 -06:00
} ,
env : {
PAYLOAD _CORE _DEV : 'true' ,
ROOT _DIR : path . resolve ( dirname ) ,
// @todo remove in 4.0 - will behave like this by default in 4.0
PAYLOAD _DO _NOT _SANITIZE _LOCALIZED _PROPERTY : 'true' ,
} ,
async redirects ( ) {
return [
{
destination : '/admin' ,
permanent : false ,
source : '/' ,
} ,
]
} ,
images : {
2026-01-20 13:58:30 -08:00
remotePatterns : [
{
hostname : 'localhost' ,
} ,
] ,
feat(next): prevent admin panel errors when cacheComponents is enabled (#16020)
Fixes https://github.com/payloadcms/payload/issues/8897, addresses
https://github.com/payloadcms/payload/discussions/14460
Adds initial support for Next.js `cacheComponents` so users who enable
it for their frontend don't get errors from the Payload admin panel.
This PR addresses the obvious breakage but does not guarantee full
compatibility - see the "Known Limitations" section below.
When `cacheComponents` is enabled in `next.config`, Next.js throws "Data
that blocks navigation was accessed outside of `<Suspense>`" errors
because the admin layout reads cookies, headers, and does auth queries
at the top level. This prevents users from enabling `cacheComponents` at
all if Payload is in the same Next.js app.
The fix has two parts. First, `withPayload` now detects
`cacheComponents` in the Next.js config and sets a
`PAYLOAD_CACHE_COMPONENTS_ENABLED` env var. Second, `RootLayout` reads
that env var and conditionally wraps its content in `<Suspense
fallback={null}>` above the `<html>` tag, which suppresses the errors.
When `cacheComponents` is not enabled, the Suspense is not used at all
and behavior is identical to before.
## Known Limitations
These are all caused by Next.js's `cacheComponents` and likely cannot be
fixed from our side.
### Page flash on hard refresh
When `cacheComponents` is enabled, hard refresh shows a brief gray flash
before the admin panel appears. Without `cacheComponents` there is no
flash. There is no per-route opt-out for this behavior. Related issue:
https://github.com/vercel/next.js/issues/86739
### HTTP status codes (404 returns 200)
With `cacheComponents`, `notFound()` returns HTTP 200 instead of 404.
This happens because the Suspense boundary above `<html>` causes Next.js
to commit response headers (with status 200) before `notFound()` runs
inside the suspended content. The not-found UI still renders correctly -
only the HTTP status code is wrong. This is a [documented Next.js
streaming
limitation](https://nextjs.org/docs/app/api-reference/file-conventions/loading#status-codes).
### DOM accumulation breaks Playwright selectors
When `cacheComponents` is enabled, Next.js wraps route segments in
React's `<Activity>` component, keeping up to 3 previously visited pages
in the DOM with `display: none !important` instead of unmounting them.
This means Playwright selectors like `page.locator('#field-title')`
resolve to multiple elements (the visible one and hidden copies from
cached pages), causing strict mode violations. This is a [known
issue](https://github.com/vercel/next.js/issues/86577) affecting all
Next.js apps using `cacheComponents` with Playwright.
Because of this, we cannot reliably run our e2e test suite with
`cacheComponents` enabled. Adapting the test suite would require
rewriting a large number of selectors across hundreds of tests - most of
our e2e tests use `page.locator()` with ID selectors, which would all
break when Activity duplicates the DOM. Until the Next.js team provides
a per-route opt-out for Activity (which they are [actively
exploring](https://github.com/vercel/next.js/issues/86577#issuecomment-3801284197)),
we cannot _guarantee_ full admin panel compatibility beyond the initial
error suppression this PR provides.
2026-03-26 10:17:41 -07:00
qualities : [ 5 , 50 , 75 , 100 ] ,
2025-03-11 09:45:13 -06:00
} ,
webpack : ( webpackConfig ) => {
webpackConfig . resolve . extensionAlias = {
'.cjs' : [ '.cts' , '.cjs' ] ,
'.js' : [ '.ts' , '.tsx' , '.js' , '.jsx' ] ,
'.mjs' : [ '.mts' , '.mjs' ] ,
}
2024-06-10 13:42:44 -04:00
2025-03-11 09:45:13 -06:00
// Ignore sentry warnings when not wrapped with withSentryConfig
webpackConfig . ignoreWarnings = [
... ( webpackConfig . ignoreWarnings ? ? [ ] ) ,
{ file : /esm\/platform\/node\/instrumentation.js/ } ,
{ module : /esm\/platform\/node\/instrumentation.js/ } ,
]
2024-10-10 16:10:11 +03:00
2025-03-11 09:45:13 -06:00
return webpackConfig
} ,
2024-03-08 10:56:13 -05:00
} ,
2025-03-11 09:45:13 -06:00
{ devBundleServerPackages : false } ,
) ,
2024-02-29 12:15:51 -05:00
)
feat(plugin-sentry): update plugin to 3.0 (#8613)
Updates the plugin to 3.0
Test:
```sh
NEXT_PUBLIC_SENTRY_DSN=<DSN here> pnpm dev plugin-sentry
```
Example:
```ts
sentryPlugin({
options: {
captureErrors: [400, 403],
context: ({ defaultContext, req }) => {
return {
...defaultContext,
tags: {
locale: req.locale,
},
}
},
debug: true,
},
Sentry,
})
```
2024-10-09 21:26:58 +03:00
2024-10-10 16:10:11 +03:00
export default process . env . NEXT _PUBLIC _SENTRY _DSN
? withSentryConfig ( config , {
telemetry : false ,
tunnelRoute : '/monitoring-tunnel' ,
} )
: config
