navidrome/conf/testdata/cfg_unknown_casing.yaml

MusicFolder: /yaml/music
NotAnOption: true
feat(config): warn about unrecognized options in the config file (#5870) * feat(config): warn about unrecognized options in the config file Options that don't match any known name were silently discarded, so a typo or an option written outside its section looked like it was applied. In #5869 the user set `ArtistSplitExceptions` at the root level instead of under `Scanner`, and got no feedback that the option was being ignored. The known names are derived by reflection over configOptions, so the check stays in sync with the struct. Free-form maps (Tags, DevLogLevels) accept any subkey. When an unknown key matches the last segment of a known one, the warning suggests it. Keys are reported as spelled in the config file, recovered by scanning it, since viper lowercases every key it loads. Also fixes two gaps this surfaced: - remapEnvVarKeysFromConfig accepted any ND_-prefixed key and advised a canonical name built by string substitution, so `ND_SCANNER_WATCHERENABLED` (not an option) suggested `Scanner.Watcherenabled` (not an option either). It now only advises names that exist, with their documented spelling, and leaves the rest to the unrecognized-option warning. - The deprecated option list drove only the warnings, while the value migration kept a second hardcoded list. They had drifted: SearchFullString warned about `Search.FullString` but never migrated to it. Both now come from deprecatedOptions. * fix(config): address Codex review on the unrecognized-option warning - Values computed during Load (ConfigFile, LastFM.Languages, Deezer.Languages) were accepted as valid keys, so setting them in the config file stayed silent even though Load overwrites them. They are now marked `conf:"-"` at the declaration, so the exclusion can't drift from the struct. - Removed options are in the known-key set only so they get their own warning, but suggestOptions drew from the same set, so an unknown `ID` advised `Spotify.ID`, a key Navidrome explicitly ignores. They are now filtered out of suggestions. - mapDeprecatedOption uses viper.Set, which outranks the config file, so a deprecated value overrode an explicitly configured replacement. It now skips the migration when the replacement was provided. viper.IsSet counts defaults as set, so the check is InConfig plus the env var. envVarName also returns "" for an empty option, so a deprecated option with no replacement no longer advises "Please use the new 'ND_'". * fix(config): cover the ND_ spelling of a replacement, and the warning output - explicitlySet missed the case where the replacement is given in the config file under its ND_ spelling: remapEnvVarKeysFromConfig moves it to the override layer, out of InConfig's reach, so the deprecated value still won. It now also checks the ND_-prefixed config key. - The tests asserted only the helpers' return values, so removing the logUnknownOptions call from Load left them green. Added a spec that captures the logger and checks the emitted warning and suggestion text; verified it fails when the call is removed. 2026-07-29 13:44:42 -04:00			`MusicFolder: /yaml/music`
			`NotAnOption: true`