Регенерация на основе изменений с помощью генераторов статических сайтов

Похоже, что все генераторы статических сайтов, которые я нашел, полностью восстанавливают весь сайт каждый раз, когда в какой-то файл на сайте вносятся изменения.

Например, одним из наиболее популярных генераторов сайтов является Jekyll, который поддерживает Github Pages. Каждый раз, когда автор вносит изменение (например, исправление грамматики в файл сообщения или изменение макета about.html) и ему требуется регенерировать этот контент, Jekyll не оставляет другого выбора, кроме как регенерировать весь сайт, даже если есть сотни файлов, вывод которых не изменился в результате последних правок.

Время, необходимое для регенерации больших сайтов, по-видимому, является частой жалобой на большинство генераторов статических сайтов.

Есть ли какая-либо техническая причина (из точки зрения разработки или проектирования генераторов статических сайтов), которая мешает кому-либо написать генератор статических сайтов, который "умно" относится к своему содержимому и мог бы знать о себе до такой степени, что мог бы понять, какие файлы были изменены и какие файлы зависят от этого (или наоборот) и будут регенерировать только необходимые файлы?

Поскольку большинство людей (особенно пользователей Jekyll / GH Pages) хранят свои сайты в репозитории git, даже кажется, что генератор сайтов может использовать информацию о фиксации и отслеживать изменения и полагаться на эту информацию, чтобы знать, какие файлы необходимо регенерировать и которую можно оставить в покое. Мысли?


web jekyll code-generation static-site github-pages
person Chase May    schedule 12.07.2013    source источник

Ответы (1)


arrow_upward
8
arrow_downward

Короткий ответ: это сложно.

Самое сложное - не знать, какие файлы были изменены. Сложнее всего знать, на какие выходные файлы повлияли измененные файлы. Например, если вы измените заголовок сообщения в блоге, необходимо будет обновить основной индекс блога. Так будут любые страницы тегов. То же самое и с любой страницей, на которой другой пост указан как «связанный пост». Если у вас есть выдержки на вашей домашней странице, сделайте то же самое.

Но с этим можно справиться. Вы можете сохранить ориентированный ациклический граф, который отслеживает зависимости для любой данной страницы, и повторно создавать страницы, которые включают биты других страниц, которые изменяются. Это увеличивает накладные расходы и сложность кода, а также время вычислений, но это, вероятно, того стоит.

Однако сложнее знать, какие страницы необходимо регенерировать в результате изменений элементов, с которыми они еще не связаны. Что произойдет, если вы добавите новый тег к сообщению в блоге? Теперь страницу тега для этого нового тега также необходимо сгенерировать заново. Если вы используете теги для создания «связанных постов», все посты на вашем сайте должны быть сгенерированы заново, поскольку «лучшие» отношения для любого поста теперь могут быть другими. Что происходит, когда вы добавляете новую запись? Чтобы избежать ненужной компиляции, генератор статического сайта должен знать, какие страницы включили бы этот пост, если бы он был поблизости, и также регенерировать их.

Обратите внимание, что во всех этих случаях ложные срабатывания (страницы, которые не изменились, но все равно перекомпилированы) допустимы, но ложноотрицательные (страницы, которые должны быть перекомпилированы, но не являются) абсолютно недопустимы. Поэтому в любом случае генератор сайта должен проявлять осторожность: если есть вероятность того, что страница изменится при повторной компиляции, ее необходимо перекомпилировать.

Например, Nanoc отслеживает изменения, о которых вы упомянули. Он хранит направленный ациклический граф страниц, зависящих от других страниц, и кэширует его между компиляциями, чтобы ограничить количество перекомпиляций. Он не регенерирует каждую страницу каждый раз, но он часто перекомпилирует некоторые страницы, которые не нужно компилировать. Есть еще много возможностей для улучшения.

person bobthecow    schedule 13.07.2013