## Get started with nextload
### Prerequisites: 
**node**
Using a version manager for installing node is recommended, see [nvm](https://github.com/nvm-sh/nvm) or [fnm](https://github.com/Schniz/fnm)

**pnpm**
`corepack enable pnpm`

**docker**
[get docker script](https://get.docker.com/):
```
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`

2. **Install dependencies**

`pnpm install`

3. **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](https://github.com/payloadcms/payload-3.0-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?