Getting updates

Your project and the starter share a git history, so an update is a normal merge. Nothing of yours is ever overwritten silently.

One-time setup

Your project needs to know where updates come from. Run this once, using the repository URL from your purchase:

git remote add upstream <starter repo url>

If you started by cloning that repository, it may already be set up as origin. Rename it so upstream means "the starter":

git remote rename origin upstream

Check what is available

pnpm update-starter check

This changes nothing. It tells you how many new versions there are, what they touch, and — the useful part — which of those files you have also edited. Those are the only places you will have to make a choice.

Apply an update

pnpm update-starter apply

Commit your own work first; the command will refuse otherwise. Afterwards, check the project still runs:

pnpm install && pnpm typecheck && pnpm test && pnpm dev

When it says there are conflicts

A conflict is not a problem and not a mistake. It means you and we both edited the same file, and git is refusing to guess which version you want.

The fastest way through is to hand it to your assistant:

Walk me through each merge conflict in this project. For each one, tell me in plain language what I changed, what the update changed, and which to keep or how to combine them. Then apply my choice.

To back out completely, at any point before you commit:

git merge --abort

Nothing is lost. You can try again whenever you like.

Fewer conflicts

Conflicts only happen in files both sides changed.

• Add, rather than edit. A new page or component never conflicts. Rewriting a shipped one might.
• Do not hand-edit generated files. They are regenerated, and edits there conflict every time.
• Update often. Ten small updates are far easier than one after a year.