Как я за полдня навайбкодил библиотеку на Go и почему потом всё-таки пришлось вчитываться в код

[Vasilesk]

Для кода ИИ-шки ревью от ИИ-шки

От человека добавлю, что библиотека вроде как строит конфиг "под ключ" и функция Load могла бы быть дженериком.

Но раз она все же принимает на вход указатель, интуитивно ожидаешь поведение, схожее с Unmarshal в стандартном json и популярных yaml.v3, go-toml, то есть дозаполнение структур, ключей мапок и так далее, тем, что есть в данных, относительно того, что было в объекте под указателем. Но у библиотеки на этот счет поведение довольно смешанное, в частности, мапки она замещает, а не дозаполняет ключи.

Если резюмировать, то, разгребая все баги и неявные допущения, можно прийти к аналогу viper. И, как было замечено в начале статьи, для небольшого сервиса это может быть избыточно.

Как будто проще написать функцию, которая по переданным ей опциям-источникам в соответствующем им порядке накатывает на объект данные через пакеты json, yaml.v3, go-toml, в соответствии с тегами на структуре, а если появляется где-то двусмысленность, кидает ошибку и ничего не додумывает.

[Denio0304]

Спасибо за внимание к статье и библиотеке! Ревью от ИИ-шки оказалось действительно полезным, сам бы до этого всего не додумался. Выкатил новую версию, где поправил описанные моменты.
В новой версии также жёстко зафиксировал стратегию замещения слайсов и дозаполнения мап, чтобы у библиотеки было более предсказуемое поведение с точки зрения пользователя.
Load намеренно не стал делать дженериком, потому что хотел, чтобы она выглядела аналогично очень популярной библиотеке joho/godotenv, чтобы при переходе с неё пользователю было достаточно поменять импорт, оставив загрузку конфига без изменений.
Последнее, что вы написали, не до конца понял. Библиотека сейчас и так ведёт себя вполне предсказуемо в этом плане: в каком порядке передаёшь источники, в таком порядке они читаются и перезаписывают предыдущие значения, если попались те же ключи.