| .idea | ||
| .vscode | ||
| public | ||
| src | ||
| types | ||
| .dockerignore | ||
| .drone.yml | ||
| .env.local.example | ||
| .eslintrc.json | ||
| .gitignore | ||
| .prettierrc.json | ||
| CHANGELOG.md | ||
| docker-compose.prod.yml | ||
| docker-compose.yml | ||
| docker-entrypoint.sh | ||
| Dockerfile | ||
| next.config.mjs | ||
| package.json | ||
| payload.config.ts | ||
| pnpm-lock.yaml | ||
| README.md | ||
| start-database.sh | ||
| tsconfig.json | ||
Get started with nextload
Prerequisites:
node Using a version manager for installing node is recommended, see nvm or fnm
pnpm
corepack enable pnpm
docker get docker script:
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
Start developing
- Copy the environment variables
cp .env.local.example .env.example
- Install dependencies
pnpm install
- Run dev container
pnpm dev or docker compose up
Notes
- payload-types.ts file will be generated when starting the dev container, but can also be generated manually with
pnpm generate:types - Dev container will use
node_modules, so make sure to runpmpm installprior topnpm dev
Technical details
Nextload is a fork of payload 3 demo
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?