Update the Template Safely
Integrate a future Nexus release while preserving product-specific pages, branding, data integration, and configuration.
On this page 5
What you will learn
- Prepare for future updates.
- Classify changed files.
- Merge and verify an upstream release.
Prerequisites
- Source control
- A clean baseline of the purchased version
- A backup or rollback point
Keep a baseline
Commit the unmodified delivered package or preserve it as an upstream branch/tag. Commit your customization separately. This makes future differences explainable.
bash
git add .
git commit -m "chore: baseline Nexus release"
# Apply product changes in later commitsClassify the incoming release
Read CHANGELOG.md and compare source directories. Treat each group differently.
- package.json and lockfile: dependency and script changes.
- app/globals.css: shared design-system changes.
- app/template.css: page and template styling.
- components: UI behavior and examples.
- app/app: routes and page composition.
- lib/navigation.ts and catalogs: menus and generated content.
- scripts and tests: build, release, and contract changes.
Recommended merge workflow
Update in a branch and resolve conflicts with product intent visible.
- Back up production and create an update branch.
- Import the new release as a separate commit or upstream reference.
- Review CHANGELOG.md and dependency changes.
- Merge shared foundations before feature pages.
- Reapply intentional branding and product integrations.
- Run pnpm install, pnpm check, and targeted browser regression tests.
- Deploy to staging before production.
Avoid blind replacement
Do not copy a new release over a customized working directory. That makes deletions and conflicts invisible and can silently restore demo data or remove security integration.