Clone and install

If the common group from Prerequisites is in place, this step usually runs 5–10 minutes.

1) Pull the base into your own project

There are two ways to get the base. If git is new to you, the GitHub Template route is the friendlier one.

A. GitHub Template — recommended

1. Open the base’s GitHub page (github.com/ddakit/e2e-base).
2. Click the green Use this template button in the top right and pick Create a new repository.
3. Name a new repository under your own GitHub account. For example, my-app-e2e.
4. Click Create repository.

A fresh copy of the base lands under your account. Now pull that copy down to your machine. Open a terminal and run:

cd ~/Desktop                                # or any working folder you like
git clone https://github.com/<your-id>/my-app-e2e.git
cd my-app-e2e

Put your own GitHub username where <your-id> is.

B. Plain git clone — if git already feels familiar

git clone https://github.com/ddakit/e2e-base.git my-app-e2e
cd my-app-e2e
git remote rename origin base               # keep the ddakit update channel under the name "base"
# Create an empty repo on your own GitHub, then point origin at it:
# git remote add origin https://github.com/<your-id>/my-app-e2e.git

Do not drop the base remote — keep it, and the Staying up to date step uses it as is. Your origin repository and the base ddakit update channel live side by side in one spot.

2) Confirm your GitHub repo is wired up

From here, every commit you make flows to your own GitHub repository. Confirm the wiring once.

git remote -v

If you took route A, both origin lines carry your own repo address.

origin  https://github.com/<your-id>/my-app-e2e.git (fetch)
origin  https://github.com/<your-id>/my-app-e2e.git (push)

If you took route B and origin is missing, create an empty repo on your GitHub first, then connect it with these two lines.

git remote add origin https://github.com/<your-id>/my-app-e2e.git
git push -u origin main

The -u flag pins the destination, so from the next push onward a bare git push lands in the same place. You only need it once.

3) Bootstrap the environment

The base ships a script called init.sh. It runs dependency install, typecheck, and — on the web and desktop tracks — the Playwright browser install, all in one pass. Run this single line.

bash init.sh

The healthy shape

The script prints its steps top to bottom as it runs, usually flowing like this.

→ Checking Node version
v20.x.x
→ Package manager: pnpm
→ Installing dependencies
...
✓ Environment ready.

If you see ✓ Environment ready. at the end, with the “next step” guidance and the production-ban warning printed below it, the run finished cleanly.

Where it stalls

• ✗ No package.json found. means the test skeleton has not been generated yet. Right after a first fork, that is expected. In this case, head to First run, run start project setup to lay the skeleton with /2-setup-base, then run init.sh again.
• A (Playwright install failed — check your network) line means the browser download got blocked on the network. Wait a moment, then run pnpm exec playwright install --with-deps chromium by hand once more.
• A line like command not found: pnpm means the package manager install from Prerequisites did not finish.

4) Right after a first fork, an empty skeleton is normal

There is one spot here that trips people up. Right after you get the base, the tests/ folder is empty or missing entirely. Seeing zero test files is normal.

This base holds to a no-contamination principle. It does not ship anyone else’s test output ahead of time. The moment you run start project setup in First run, empty templates get created, and as you work through Choose your target and Your first test, tests shaped for your own app fill in.

So if you run ls tests/ right now and nothing comes back, no need to worry. The next steps are where it fills in.

Next

If bash init.sh ended with ✓ Environment ready., head to First run.