Consider dropping zod for Epic Games Launcher client data parsing

[toebeann]

zod definitely has it's uses, but for data where keys may have inconsistent casing, it's quite tedious to work with.

Also, zod's errors are rather horrible for end users to look at.

As of gib v0.7.12, zod parsing has been ditched when working with Steam client data, as Steam's local data format uses very inconsitent casing for object keys - sometimes PascalCase, sometimes lowercase, sometimes something else altogether. I have found that simply chucking the object in a proxy which allows for case insensitive key access to be the most convenient way to get around this. One of the benefits of this approach is that if we ever intend to write data back to the file (e.g. as we do with Steam shortcuts and Steam app launch options), then we don't run the risk of accidentally adding a new key with a different casing than what was already there to the file - the proxy will ensure whatever casing is already present on the key while reading is not changed while writing.

gib is however still using zod parsing when working with Epic Games Launcher client data, with a custom zod transformation to treat all keys as camelCase. because again there is inconsistent casing between PascalCase, camelCase and possibly even snake_case going on. It may be wise to handle Epic Games Launcher client data in a similar manner to how we now handle Steam client data - forego zod parsing, and instead make use of a proxy to handle the casing inconsistencies, which should make gib more reliable when handling Epic client data, as it has done with Steam.