This repo showcases a demo of the Payload 3.0 Beta running completely within Next.js.
[!IMPORTANT] It's extremely important to note that as of now, this demo contains BETA software and you are 100% guaranteed to run into bugs / weird stuff.
We're actively working toward a stable release as fast as we possibly can.
@payloadcms/ui
package, which will be fully documented and exposed for your re-use once we hit stable 3.0 or beforenodemon
or similar. When the Payload config changes, your app will automatically re-initialize Payload seamlessly in the backgroundWe are making this available to our community so that we can gather your feedback and test the new approach that Payload is taking. Don't expect it to be fully functional yet. There are some things that we are aware of that are not yet completed, but we're going to keep blazing through the remaining items as fast as we can to reach stable 3.0 as quickly and efficiently as possible. Here are a few of the items that we are still working on (not a full list):
You can install Payload into your existing Next.js project using this command:
npx create-payload-app@beta
Contents from src/app
will have to be moved into a new directory src/app/(app)
so that Payload's root layout and routes can remain isolated from the rest of your app.
To try out this repo yourself, follow the steps below:
git clone git@github.com:payloadcms/payload-3.0-demo.git
)cd
into the new folder by running cd ./payload-3.0-demo
.env.local.example
by running cp .env.local.example .env.local
in the repo, then fill out the values including the connection string to your DBpnpm i
, npm install
, yarn
, etc.). pnpm
is highly recommended. The usage of yarn v1 is discouraged..\start-database.sh
to start it in docker container.pnpm dev
, npm run dev
, yarn dev
, etc.)onInit
methodThere is a possibility that we will make breaking changes before releasing the full stable version of Payload 3.0.
To follow along with breaking changes in advance of the full, stable release, you can keep an eye on the CHANGELOG.md.
The app folder
You'll see that Payload requires a few files to be present in your /app
folder. There are files for the admin UI as well as files for all route handlers. We've consolidated all admin views into a single page.tsx
and consolidated most of the REST endpoints into a single route.ts
file for simplicity, but also for development performance. With this pattern, you only have to compile the admin UI / REST API / GraphQL API a single time - and from there, it will be lightning-fast.
The next.config.js
withPayload
function
You'll see in the Next.js config that we have a withPayload
function installed. This function is required for Payload to operate, and it ensures compatibility with packages that Payload needs such as drizzle-kit
, sharp
, pino
, and mongodb
.
Using a TypeScript alias to point to your Payload config
In the tsconfig.json
within this repo, you'll see that we have paths
set up to point @payload-config
to the Payload config, which is located in the root. You can put your config wherever you want. By default, the page.tsx
files and route.ts
files within the /app
folder use this alias. In the future, we might make it optional to use paths
- and by default, we might just hard-code relative path imports to the config. We would like to hear your feedback on this part. What do you prefer? Use paths
or just use relative imports?
Open an issue on this repo at https://github.com/payloadcms/payload-3.0-demo
with as much detail as you can provide and we will tackle them as fast as we can. Let's get stable!