Skip to content

Auto-migrate (or clearly reject) the pre-#7 config shape #9

@roziscoding

Description

@roziscoding

Context

#7 changed the config schema:

Before

{
  "indexer": { "priority": 1, "autoRegister": true },
  "servers": {
    "sources": [{ "type": "jellyfin", ... }],
    "peers": [{ ... }],
    "destinations": [{ "type": "radarr", ... }, { "type": "sonarr", ... }]
  }
}

After

{
  "servers": [
    { "type": "radarr", ..., "source": true, "destination": true, "autoregister": { "enable": true, "priority": 1 } }
  ],
  "peers": [{ ... }]
}

AppConfig.parse now throws on an old-shape file (servers is an array, not an object; no indexer block), so anyone upgrading with their existing config gets a hard Zod error at boot with no guidance.

Ask

Detect the legacy shape and migrate it (or, at minimum, fail with a clear, actionable message + a documented mapping). Proposed mapping:

  • servers.destinations[] (radarr/sonarr) → servers[] with destination: true.
  • servers.sources[] of type jellyfindropped, with a warning that Jellyfin sourcing was removed (point at Radarr/Sonarr source: true).
  • servers.peers[] → top-level peers[].
  • indexer.autoRegister / indexer.priority → per-server autoregister: { enable, priority }.

Implementation ideas: a pre-parse migration step in getAppConfig that recognizes the old shape (e.g. servers is a non-array object) and rewrites it in-memory (optionally writing the migrated file back with a .bak of the original), logging what changed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions