|
||
---|---|---|
.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 | ||
postcss.config.js | ||
README.md | ||
start-database.sh | ||
tailwind.config.js | ||
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 install
prior 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?