nextload/README.md
tobias ec284177ee
Some checks failed
continuous-integration/drone/push Build is failing
Update readme
2024-06-23 10:32:36 +02:00

2.3 KiB

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

  1. Copy the environment variables

cp .env.local.example .env.example

  1. Install dependencies

pnpm install

  1. 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 run pmpm install prior to pnpm 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?