Разделить фид и ссылки на сайте

[pepelsbey]

У нас есть несколько проблем с отображение фида, которые можно было бы решить другим рендерингом маркдауна. Например, YouTube и Apple Podcasts не любят заголовки <h2>. Но проблема в том, что содержимое фида буквально рендерится в описание эпизода на сайте: заголовки, списки, ссылки.

То есть, если убрать заголовки из фида, чтобы они не ломали YouTube и Apple Podcasts, то на сайте будет плохо.

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

[monochromer]

Помнится, самой первой реализацией создания страниц для подкаста было вытягивание файлов через Github API. Было жутко медленно, неудобно и требовало создания токена для API.

Также можно класть рядом два репозитория - сайт и подкаст - и связывать через символические ссылки.

3-ий способ - git-субмодули. В .eleventyignore нужно будет добавить некоторые файлы из репо подкаста, чтобы лишние файлы не обрабатывались.

Ну и, на мой взгляд, самый лучший вариант - добавить репо подкаста в package.json как зависимость (npm позволяет добавлять git-репозитории) и подключить md-файлы как виртуальные шаблоны, либо создать плагин, который будет экспортировать коллекцию. Но для этого нужно обновить Eleventy до самой последней canary-версии.

[pepelsbey]

Идея с подкастом как зависимостью для сайта — отличная. Она только упирается в возможности движка, но думаю рано или поздно всё равно нужно будет до 3-й версии обновляться, чего бы не начать с альфы)

[monochromer]

добавить репо подкаста в package.json как зависимость

Есть опасение, что из-за того, что у пакета нет версионирования, где-нибудь в Github Actions он может закэшироваться навечно.

[pepelsbey]

у пакета нет версионирования

Можно автоматически релизить мажорную версию пакета podcast раз в неделю :)

[monochromer]

Ещё одна проблема - придётся вписывать (можно автоматизировать) размер mp3-файла в дата-файлы, так как на стороне репозитория сайта не будет доступа к mp3-файлам.

В репозитории подкаста для этого используется такой код:

config.addFilter('length', (path) => {
  const stats = fs.statSync(path);
  return stats.size;
});

`<enclosure
  type='audio/mpeg'
  url='${data.meta.url}episodes/${episode.fileSlug}.mp3'
  length='${this.length(`src/mp3/${episode.fileSlug}.mp3`)}'
/>`

[pepelsbey]

Размеры можно брать из фида 😁

[monochromer]

Размеры можно брать из фида 😁

фид я собираюсь генерировать на стороне репозитория сайта )

[pepelsbey]

А, точно! Привычка)

[monochromer]

на стороне репозитория сайта не будет доступа к mp3-файлам.

Предлагаю прогонять перед коммитом скрипт, который будет создавать json с размером файла. Попробовал записывать в yaml, но библиотеки форматируют по другому - убирают пустые строки, добавляют кавычки.

Есть опасение, что из-за того, что у пакета нет версионирования, где-нибудь в Github Actions он может закэшироваться навечно.

В общем, так и есть. Когда добавляется git-репозиторий как пакет, то в package-lock.json добавляется ссылка на хеш коммита, например:

"node_modules/test-child": {
  "resolved": "git+ssh://git@github.com/<organization-or-user>/<repo-name>.git#5687b1e50660e5d437d0af59387978d881a2b3cc"
}

Поэтому внутри Github Actions npm ci будет всегда ставить версию, соответствующую коммиту. npm i тоже не сильно, поможет, так как у Actions есть свой кэш.

Варианты решения - в package-lock.json вписать руками имя ветки вместо хэша коммита:

"node_modules/test-child": {
  "resolved": "git+ssh://git@github.com/<organization-or-user>/<repo-name>.git#main"
}

Но это не очень надёжно, так как lock-файл может быть пересоздан.

Другой вариант - внутри action ставить обновлённую версию.

[monochromer]

Ещё один вариант установки всегда свежей версии репозитория подкаста - добавить скрипт postinstall:

{
  "postinstall": "npm install git://github.com/web-standards-ru/podcast.git#main --save=false --package-lock=false"
}

Так не нужно каждый раз обновлять файлы package.json и package-lock.json для git.

[HellSquirrel]

Привет.
Я была бы осторожной с сабмодулями, и с символическими ссылками. При сборке с ними постоянно возникают какие-нибудь проблемы (ну точнее у меня возникают и я всегда фолбечусь на решение попроще)
По поводу генерации, я очень не в контексте, но кажется если есть md исходник из него хорошо все вытаскивать. Если исходник публичный, то, кажется github api не нужно можно прямо GET-запросом выдергивать.
C API ключиком тоже, кажется не большая проблема - закинули его в secrets и забыли

[monochromer]

Закинул два PR'а по теме:

• #16
• web-standards-ru/web-standards.ru#360