Skip to main content
tauri-plugin-configurate ships two utility exports that complement the main Configurate class. configDiff() is a standalone function that computes a structural diff between any two config-shaped objects — useful for logging, auditing, or selectively reacting to changes. MigrationStep is the interface you implement to upgrade stored configs from an older schema version to a newer one.

configDiff(oldData, newData)

Computes a structural diff between two config objects and returns an array of change descriptors. Nested objects are compared recursively, and each change is reported at its deepest differing path using dot-separated notation.
Record<string, unknown>
required
The baseline config object — the “before” state.
Record<string, unknown>
required
The updated config object — the “after” state.
DiffEntry[]
An array of DiffEntry objects, one for each key that was added, removed, or changed. The array is empty when the two objects are deeply equal. Order follows the iteration order of the union of both objects’ keys.
Nested objects are walked recursively and paths are dot-separated:
Recursion depth is capped at 64 levels. If either object contains nesting deeper than 64 levels, configDiff() throws "configDiff: maximum nesting depth exceeded". In practice, config objects are never this deep.

Using configDiff with onChange

A common pattern is to call configDiff inside an onChange listener to react only to specific fields:

DiffEntry

Each element in the array returned by configDiff() conforms to this interface.
string
Dot-separated path to the changed key, relative to the root of the config object. For example, a change to database.host produces "database.host".
"added" | "removed" | "changed"
The kind of change:
  • "added" — the key is present in newData but absent in oldData.
  • "removed" — the key is present in oldData but absent in newData.
  • "changed" — the key is present in both but the values differ.
unknown
The previous value. Present for "removed" and "changed" entries; absent for "added".
unknown
The new value. Present for "added" and "changed" entries; absent for "removed".

MigrationStep

MigrationStep is the interface you implement to define how config data should be transformed when the stored version is older than the current version declared in the Configurate constructor. Migrations are applied automatically during load(); if any step runs, the migrated result is auto-saved back to storage.
number
The schema version this step upgrades from. A step with version: 1 transforms data that was saved at version 1 into version 2.
(data: TData) => TData
A pure transform function. Receives the config data at the declared version and must return the data shaped for the next version. Do not mutate the input object — return a new one.

How versioning works

When you set version: N in the constructor, the plugin stores __configurate_version__: N alongside your data on every write. On load(), it reads the stored version and runs every MigrationStep whose version is less than the stored version, in ascending order, until the data reaches the current version.
Write each up function as a pure transform — copy the input with the spread operator and add or omit fields rather than mutating in place. This makes migration logic easier to unit-test and reason about.
If a migrated config cannot be auto-saved back (for example, because the disk is full), the failure is logged as a warning but does not surface to your code. The migrated data is still returned in memory for the current session.