25 февраля 2026 года вышел Hugo v0.157.0. На первый взгляд релиз выглядит как «ещё один минорный апдейт», но внутри есть сразу несколько изменений, которые заметно улучшают работу реальных проектов: особенно если у вас модульная архитектура, контент из нескольких репозиториев и внешние запросы в шаблонах.

В этой статье разберём, что именно изменилось, где может быть практический эффект, и как пройти обновление без сюрпризов. 🚀

Кому это релевантно сразу: командам, ведущим контент через Hugo Modules; авторам тем, использующим внешние API в шаблонах; всем, у кого билд иногда «висит» из-за медленного источника. Кому можно отложить: одиночный блог без модулей и без внешних запросов получит апгрейд почти прозрачно — обновляйтесь как часть обычной уборки технического долга.

Почему релиз 0.157.0 важен #

Главная идея релиза: Hugo становится устойчивее в «боевых» сценариях, где проект не ограничивается одной папкой content и парой шаблонов.

Ключевые точки:

  1. Page.GitInfo теперь полноценно поддерживает контент из Git-модулей (через mounts).
  2. В resources.GetRemote появился перезапросный timeout, который можно задавать прямо в шаблоне.
  3. Добавлена частичная поддержка AVIF/HEIF/HEIC (пока только метаданные).
  4. Улучшены дефолты обработки WebP.
  5. Исправлены ошибки, влияющие на меню, section pages и стабильность сборок.

Если коротко: меньше «магии», больше управляемости. 🎯

GitInfo для Hugo Modules: что реально изменилось 🧩 #

Проблема до 0.157.0 #

Если вы подключали контент через module.imports.mounts (например, общий набор статей или документацию из отдельного репозитория), GitInfo мог работать неполно или нестабильно для таких страниц.

Это мешало:

  • корректно выводить «последнее обновление» для импортированного контента;
  • строить списки изменений по коммитам;
  • делать единый шаблон мета-блока для локального и модульного контента.

Что даёт 0.157.0 #

В релизе добавлена и доработана поддержка Page.GitInfo для контента из Git-модулей. То есть страницы, примонтированные из модулей, теперь могут корректно отдавать данные о коммите: автора, дату, хеш, subject и т.д.

Это особенно полезно для:

  • docs-порталов из нескольких репозиториев;
  • мультисайтов, где контентные команды работают независимо;
  • архитектуры «ядро темы + контент как модуль».

Практический шаблон #

{{ with .GitInfo }}
  <p class="meta">
    Обновлено: {{ .AuthorDate.Format "2006-01-02 15:04" }} ·
    Автор: {{ .AuthorName }} ·
    Коммит: <code>{{ .AbbreviatedHash }}</code>
  </p>
{{ end }}

Важный operational-момент: в CI должен быть не shallow clone, иначе Git-данные могут быть неточными.

resources.GetRemote получил timeout: контроль вместо зависаний ⏱️ #

Что болело раньше #

Когда вы тянете внешние данные (RSS/JSON/изображения), один медленный источник мог подвесить сборку. На небольшом сайте это раздражает, а на большом CI-пайплайне превращается в регулярную проблему.

Что появилось в 0.157.0 #

Теперь в resources.GetRemote есть опция timeout (строка длительности, например "10s"). Её можно задавать для каждого запроса отдельно.

{{ $url := "https://example.org/feed.rss" }}
{{ $opts := dict "timeout" "10s" }}

{{ with try (resources.GetRemote $url $opts) }}
  {{ with .Err }}
    {{ warnf "Не удалось получить feed %q: %s" $url . }}
  {{ else with .Value }}
    {{ $data := . | transform.Unmarshal }}
    {{/* дальнейшая работа с данными */}}
    {{ $data }}
  {{ else }}
    {{ warnf "Ресурс %q не найден" $url }}
  {{ end }}
{{ end }}

Практический эффект:

  • можно задавать строгий timeout для нестабильных источников;
  • сборка перестаёт «висеть» из-за одного внешнего API;
  • проще разделить критичные и некритичные источники (где-то errorf, где-то warnf).

Изображения: что важно понимать про AVIF/HEIF/HEIC и WebP #

В 0.157.0 добавили частичную поддержку AVIF/HEIF/HEIC: на текущем этапе это поддержка метаданных, а не полноценный новый pipeline обработки.

Что это значит на практике:

  • Hugo лучше распознаёт такие файлы;
  • можно безопаснее работать с метаданными;
  • но не стоит ожидать полной parity с привычной обработкой JPEG/PNG/WebP прямо «из коробки».

Также в релизе скорректированы настройки обработки WebP. Если вы строите агрессивный image pipeline, стоит прогнать визуальные regression-проверки на ключевых страницах.

Дополнительные исправления, которые могут «всплыть» в проде #

В релизе есть не самые заметные, но полезные улучшения:

  • фикс menu pageRef в multidimensional-настройках;
  • корректировки в логике section pages;
  • улучшенные сообщения об ошибках модулей (go mod download);
  • пропуск пустых taxonomy-ключей/значений в конфиге.

Каждый пункт по отдельности небольшой, но вместе они снижают количество «странных» инцидентов после релиза.

Сценарий, который раньше ломался: контент в нескольких модулях #

Чтобы понять ценность изменений вокруг GitInfo и section pages, представьте типичную mid-size-конфигурацию: основной репозиторий с темой, плюс два модуля с контентом — docs/ и blog/, каждый в своём Git-репо. Их подмонтировали в основной сайт через module.imports.mounts.

До 0.157.0 в этой конфигурации возникали мелкие неприятности: даты в footer’е импортированных постов отдавали поведение «default-на-momento-сборки» вместо «коммит-автор-дата»; menu иногда теряла pageRef для импортированных страниц при определённых вариантах языковой настройки; ошибки go mod download приходили без контекста, и приходилось вручную перебирать модули, чтобы найти проблемный.

В 0.157.0 каждый из этих краевых случаев починен. Если вы держите такой setup, после обновления заметна разница: меньше ручных правок шаблонов под «странности» modular-контента, прозрачнее ошибки при сетевых проблемах с одним из модулей.

Когда обновляться можно отложить #

Если у вас одиночный сайт без модулей, без resources.GetRemote в шаблонах, без AVIF/HEIF в pipeline и без активных кастомных меню с pageRef — этот релиз вас почти не коснётся. Обновитесь в плановом окне (вместе с пересборкой Docker-образа, например), но срочности нет.

Срочно обновляться стоит, если: используете resources.GetRemote и хотя бы раз попадали на медленный source; ведёте мультимодульный контент; пишете кастомные шаблоны с .GitInfo для импортированных страниц.

Чек-лист обновления до Hugo 0.157.0 ✅ #

  1. Обновите бинарь/образ Hugo до 0.157.0.
  2. Если используете GitInfo, проверьте enableGitInfo: true в конфигурации.
  3. Убедитесь, что CI делает глубокий клон репозитория (fetch-depth: 0 в GitHub Actions или эквивалент).
  4. Для всех resources.GetRemote проставьте осмысленный timeout и единообразный try-обработчик.
  5. Прогоните smoke-тесты меню, section pages и страниц с импортированным модульным контентом.
  6. Проверьте image pipeline (особенно WebP) на визуальные отличия.
  7. Сравните длительность сборки до/после обновления.

Мини-план миграции на 30 минут #

Если проект уже в хорошем состоянии, переход можно сделать быстро:

  1. 10 минут: поднять версию и собрать сайт локально без warning/error.
  2. 10 минут: проверить шаблоны с .GitInfo и блоки с resources.GetRemote.
  3. 10 минут: прогнать CI и открыть несколько критичных страниц руками.

Обычно этого достаточно, чтобы перейти на релиз без ночных откатов.

Итог 🧠 #

Hugo 0.157.0 не про «громкие фичи ради фич», а про зрелость платформы: лучшее поведение в модульных проектах, более предсказуемая работа с внешними запросами и аккуратные улучшения инфраструктурного уровня.

Если у вас контент разбит на модули, а сборка зависит от внешних данных, обновление стоит делать в ближайшем цикле.

Источники #