Updater

Nutin's source lives in your project, so updating Nutin means updating files you may have edited. nutin-update updates them without overwriting your changes.

Usage

# from your project's root, with the latest CLI installed
npm i -g @nutin/cli
nutin-update

• -y, --yes: apply the updates without the confirmation prompt. Required in a non-interactive shell (e.g. CI); without it, nothing is changed.
• --from <path>: use a local templates/ directory as the old baseline instead of fetching it from npm.
• --allow-dirty: update even when the project has uncommitted changes or untracked files, or isn't in a git repository. The update then can't simply be undone with git.

Undoing an update

Before writing anything, nutin-update checks that the project folder is committed: no changes and no untracked files (files ignored by .gitignore, like node_modules/ and dist/, don't count). Otherwise it lists them and stops; commit or stash them first. So an update can always be undone, e.g. if a merge left conflicts you don't want to resolve now. From the project folder:

git checkout -- . && git clean -fd

Only the project folder is checked, so a project inside a larger repository isn't blocked by changes elsewhere in it.

nutin-update needs git to merge files you edited (it uses git merge-file; the project doesn't have to be a repository). Without git it stops before changing anything.

nutin-update handles minor and patch updates. A major version change has to be migrated by hand: see the changelog.

How it works

Your project's .nutin-meta.json records the Nutin version it was last generated or updated with, its package manager, language and features. nutin-update downloads that version from npm, regenerates the files it produced as a baseline, and compares three versions of each file: the old baseline, your file, and the new version.

A summary is printed before anything is written.

Your edits are kept. When an update touches a file you changed, the new version's changes are merged into it, and only overlapping edits are left for you to resolve. Merged and conflicting files are listed in NUTIN-UPDATE-REPORT.md.

Files that are never updated

• src/app/**: your application.
• src/assets/**.
• config/*.json.
• src/styles/**: existing files are kept; only files new in this version are added.

package.json and tsconfig.json aren't written by nutin-update either. The summary lists each package.json script and devDependencies entry, and each tsconfig.json option, that differs from what this Nutin version generates, so you can apply what you need by hand. engines.node isn't checked: see the changelog.

Resolving conflicts

Where your edit and the new version change the same lines, the file gets conflict markers, and the summary lists it. The project won't build until they're resolved: updated files around it may depend on the new version of those lines.

<<<<<<< yours
    DomHelper.cleanupOptionalContent(); // your edit
||||||| nutin v3.0.0
    DomHelper.cleanupOptionalContent();
=======
    DomHelper.cleanupOptionalContent(this.element);
>>>>>>> nutin v3.0.1

The middle section is the original Nutin version, so you can see what you changed and what Nutin changed. Keep what you need and delete the marker lines, or undo the whole update (see Undoing an update).

Files that still have conflict markers are recorded in .nutin-meta.json. Running nutin-update again checks them: it refuses to update while any are left and lists them, and clears the record once they're resolved.

Merges only happen in files outside of src/app that you edited, for example src/core/, tools/ or nutin.config.js. Binary files (e.g. images) can't be merged: yours is kept and listed in the report.

Missing .nutin-meta.json

Projects generated before .nutin-meta.json existed (or that lost it) can still be updated: nutin-update asks which Nutin version the project was created with and which features it uses, then writes the file. It detects the language (src/app/main.js without main.ts is a JavaScript project) and the package manager, and prints them. A wrong answer gives a wrong baseline, which shows up as false conflicts.

In a non-interactive shell (e.g. CI) it can't ask: it stops with a message showing an example .nutin-meta.json to create by hand.