# 2. Getting Started

This guide takes you from a fresh machine to running the site locally, then to deploying changes.

## Prerequisites

| Tool        | Version           | How to check    | Where to get it                          |
| ----------- | ----------------- | --------------- | ---------------------------------------- |
| **Node.js** | v18.17 or higher  | `node -v`       | <https://nodejs.org/> (LTS is fine)      |
| **npm**     | Comes with Node   | `npm -v`        | Installed with Node.js                   |
| **Git**     | Any recent        | `git --version` | <https://git-scm.com/>                   |

A code editor with TypeScript support is strongly recommended — [VS Code](https://code.visualstudio.com/) is the standard choice and understands this project out of the box.

> The project has been run on Node 18+ through Node 25. If you hit an odd install or build error, the first thing to try is matching a current Node LTS version.

## 1. Get the code

```bash
git clone <your-repo-url>
cd DCPH-Website-Main/dcph_website
```

> ⚠️ The actual Next.js app is in the **`dcph_website/`** subfolder, not the repository root. All `npm` commands must be run from inside `dcph_website/` (the folder that contains `package.json`).

## 2. Install dependencies

```bash
npm install
```

This reads `package.json` / `package-lock.json` and downloads everything into a `node_modules/` folder (which is git-ignored — never commit it). Run this again any time `package.json` changes (e.g., after pulling new code that adds a library).

## 3. Run the development server

```bash
npm run dev
```

Open <http://localhost:3000>. The dev server **hot-reloads**: save a file and the browser updates automatically. Most editing work happens here.

To stop the server, press `Ctrl + C` in the terminal.

## 4. Build for production (and catch errors)

```bash
npm run build
```

This compiles an optimized production bundle into a `.next/` folder. **It also type-checks and lints the whole project**, so it's the best way to confirm your changes won't break the deployed site. Always run `npm run build` before pushing significant changes — if it fails locally, it will fail in deployment too.

To preview the production build locally:

```bash
npm run start
```

(Run `npm run build` first.)

## 5. Lint

```bash
npm run lint
```

Runs ESLint using `eslint.config.mjs`. Fix or review anything it flags before deploying.

## Script reference

From `package.json`:

| Command         | Underlying      | Purpose                                              |
| --------------- | --------------- | ---------------------------------------------------- |
| `npm run dev`   | `next dev`      | Local development with hot reload.                   |
| `npm run build` | `next build`    | Production build + type-check + lint.                |
| `npm run start` | `next start`    | Serve the built site locally.                        |
| `npm run lint`  | `eslint`        | Static code analysis.                                |

## Environment variables

The project currently uses **no environment variables** — there are no `.env` files and nothing reads `process.env`. The `.gitignore` is set up to ignore `.env*` files if you ever add them (e.g., an analytics key or a form-handling API key). If you do, document each variable here.

## Deployment

> **Confirm the live hosting setup with whoever currently administers the site** — the notes below are the most likely configuration based on the repository, but they are an inference, not a verified fact.

Signals in the repo strongly suggest the site is (or was) deployed on **[Vercel](https://vercel.com/)**, the platform built by the makers of Next.js:

- `.gitignore` ignores a `.vercel` folder (created by the Vercel CLI).
- `public/vercel.svg` ships with the default Next.js template.
- The git history contains commits like `deploy` and `Force redeploy`.

### The typical Vercel workflow

On Vercel, deployment is **automatic and git-driven**:

1. The Vercel project is connected to the GitHub repository.
2. **Every push to the `main` branch triggers a production deploy.** Pushes to other branches create preview deployments with their own URLs.
3. Vercel runs `npm install` and `npm run build` for you, then publishes the result.

So in practice, **deploying = merging your change to `main` and pushing**:

```bash
git add .
git commit -m "Describe your change"
git push origin main
```

Then watch the deployment status in the [Vercel dashboard](https://vercel.com/dashboard).

### Things to verify with the site admin

- Which Vercel account/team owns the project, and who has access.
- The connected Git repository and production branch (currently `main`).
- The custom domain (the code references `https://dcph.ph` as the canonical URL in `app/news/[slug]/page.tsx`).
- Whether there are any Vercel environment variables or build settings configured in the dashboard.

If the site is **not** on Vercel, the same `npm run build` output (`.next/`) can be deployed to any Node-capable host (Netlify, AWS Amplify, a self-managed Node server via `npm run start`, etc.). Ask the admin which one is in use.

## A safe editing workflow

1. Pull the latest code: `git pull`.
2. Create a branch for your change: `git checkout -b my-change`.
3. Run `npm run dev` and make your edits, checking the browser as you go.
4. Run `npm run build` to confirm there are no errors.
5. Commit, push, and open a pull request (or merge to `main` to deploy, per your team's process).

Next: [Project Structure →](03-project-structure.md)