MBL
Go / Проекты / Open-Source-PR / helm/helm #31957 — mustToToml
Go средний

helm/helm #31957 — mustToToml

projectsopensourcehelm

Диаграмма: от бага до PR (archify) →

Смердженный PR: helm/helm #31957 — "feat(engine): add mustToToml template function". Мержен 24 марта 2026, +27/-3, два файла: pkg/engine/funcs.go и funcs_test.go.

Суть

В шаблонах Helm уже были mustToYaml/mustToJson — строгие версии, которые паникуют при ошибке сериализации. У toToml такой пары не было: она молча возвращает пустую строку при ошибке маршалинга, и автор шаблона может не заметить, что данные потерялись.

PR добавляет mustToTOML рядом с уже существующей toTOML, ничего не меняя в поведении самой toTOML. Регистрируется новая функция в funcMap() под именем mustToToml.

Почему разделили на два PR

Мейнтейнер @gjenkins8 в обсуждении #31431 предложил разделить работу: этот PR — только добавление mustToTOML, без риска (чисто аддитивное изменение, старое поведение не трогается). Отдельный, более спорный вопрос — стоит ли самой toTOML перестать глотать ошибки — вынесен в другой PR, потому что это уже meняет поведение существующей функции для всех, кто её использует.

Урок для собеса: маленький, обоснованный, аддитивный PR мержится быстрее и спокойнее, чем один большой PR, смешивающий безопасное добавление с потенциально ломающим изменением. Разделение по риску — это то, что реально ждут от контрибьютора мейнтейнеры крупного проекта.

Иллюстрация того же паттерна

Ниже — не код Helm, а независимый пример того же класса решения (обычная функция сериализации против её "must"-варианта):

на play.golang.org

Почему это ценно на собесе

Это ровно то, что проверяет секция код-ревью на техническом интервью — только с настоящими ставками: ревьюер (мейнтейнер Helm) видит код впервые именно в этом PR, свои же правила проекта надо изучить заранее, а не придумать по ходу.

Самопроверка 0 / 1
Понимаю разницу между функцией шаблона, глотающей ошибку, и её строгим "must"-вариантом
Как усвоено?