config-migration-generator
Scannednpx machina-cli add skill a5c-ai/babysitter/config-migration-generator --openclawConfig Migration Generator
Generate config file migration utilities.
Generated Patterns
interface Migration {
version: string;
up: (config: any) => any;
down: (config: any) => any;
}
const migrations: Migration[] = [
{
version: '2.0.0',
up: (config) => ({
...config,
server: { host: config.host, port: config.port },
version: '2.0.0',
}),
down: (config) => ({
host: config.server?.host,
port: config.server?.port,
version: '1.0.0',
}),
},
];
export function migrateConfig(config: any, targetVersion: string): any {
let current = config;
for (const migration of migrations) {
if (semver.gt(migration.version, config.version) && semver.lte(migration.version, targetVersion)) {
current = migration.up(current);
}
}
return current;
}
Target Processes
- configuration-management-system
- cli-update-mechanism
Source
git clone https://github.com/a5c-ai/babysitter/blob/main/plugins/babysitter/skills/babysit/process/specializations/cli-mcp-development/skills/config-migration-generator/SKILL.mdView on GitHub Overview
Config Migration Generator creates utilities to migrate configuration files between versions. It defines a Migration interface, a migrations array, and a migrateConfig function to apply incremental “up” steps up to a targetVersion, with corresponding optional “down” steps for rollback. This helps keep config schemas aligned with newer software expectations and supports safe reversions when needed.
How This Skill Works
The tool emits a Migration[] where each entry has a version, up, and down handlers. migrateConfig walks migrations in order, using semver to check if a migration should run (migration.version > config.version and migration.version <= targetVersion), applying the up function to progressively upgrade the config, and returning the final config.
When to Use It
- When upgrading an application that relies on a config file with evolving schema.
- When moving flat root fields (e.g., host and port) into a nested server object during a version bump.
- When you need safe, testable upgrades across multiple versions with rollback support.
- When integrating with a configuration-management-system to automate migrations.
- When implementing a CLI update mechanism that requires config adaptation during upgrades.
Quick Start
- Step 1: Define a Migration[] with version, up, and down handlers reflecting your config changes.
- Step 2: Implement migrateConfig(config, targetVersion) and ensure it uses semver to select and apply needed migrations.
- Step 3: Validate the migrated config, update version, and run tests to confirm correctness.
Best Practices
- Keep each migration small and purpose-specific, with a clear up and optional down path.
- Test migrations against representative config samples and edge cases (missing fields, extra fields).
- Maintain strictly increasing migration.version values and rely on semver for ordering.
- Validate that config.version exists and is semver-parsable before running migrations.
- Document the intent and data shape changes for every migration to aid maintenance.
Example Use Cases
- Upgrade 1.0.0 configs to 2.0.0 by moving host and port from the root into a server object and setting version to 2.0.0, with a down migration that restores the root fields.
- Add a new enableTelemetry flag in 2.x migrations, ensuring the flag defaults to false when absent and preserving existing behavior.
- Migrate credentials from the main config into a dedicated credentials block during a 3.0.0 upgrade while preserving compatibility for legacy reads.
- Provide a down path from 2.0.0 back to 1.0.0 to rollback a faulty 2.x deployment during a critical incident.
- Chain migrations from 2.0.0 to 3.0.0 and 4.0.0 to support multi-version upgrades via a single migrateConfig call.
