helm/helm #31957 — mustToToml
Диаграмма: от бага до 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"-варианта):
Почему это ценно на собесе
Это ровно то, что проверяет секция код-ревью на техническом интервью — только с настоящими ставками: ревьюер (мейнтейнер Helm) видит код впервые именно в этом PR, свои же правила проекта надо изучить заранее, а не придумать по ходу.