Обновить ноду

[firefoxic]

ЗаLTSилась 18я нода.
Студенты будут LTS скачивать.
Надо чтобы все конфиги (включая экшены) были готовы к этому.

[nikolai-shabalin]

Ага. Только сегодня. Буду тестировать.

[firefoxic]

Хьюстон, у нас проблемы!

Джейк Арчибальд депрекейтит libsquoosh, и обновления для поддерки 18й ноды не будет (если только комьюнити не продавит удалить вообще это ограничение по ноде и зарелизить в таком окончательном и неподдерживаемом виде).

Аналогов я не знаю. Где-то sharp упомнинают, но gulp-плагин с ним живой не удалось найти.

Жутко не охото возвращаться к imagemin и собирать плагинчики под него на каждый чих 😓

А сборка наша с gulp-libsquoosh на 18й ноде падает совсем…

[nikolai-shabalin]

Ох. Да, придётся от фразы "качайте LTS" как-то отказаться в уже созданном курсе. Придумаю что-нибудь

[firefoxic]

Появились какие-то мысли, как это решить?

[nikolai-shabalin]

Приступлю на следующей неделе в понедельник. Пока мыслей нет.

[firefoxic]

Предлагаю созвониться, я немного поресёрчил, может поможет чем-то это.

[nikolai-shabalin]

С понедельника без проблем. Можно в телеграме

[yslpn]

Есть новости?

Очень удобный шаблон, но хочется последнюю LTS версию ноды)

[nikolai-shabalin]

Пока не хочется отказываться от squoosh. Поэтому ничего нового пока нет.

Используем 16 ноду и радуемся =) Как только найдём элегантное решение я тут отпишусь

[firefoxic]

Пожалуй для истории надо бы и тут оставить варианты решения, озвученные на созвоне.

1. Замена для libsquoosh
   • gulp-imagemin — использовали до libsquoosh, в дефолтном сетапе работает почти в холостую, для нормальной работы требует установки отдельных плагинов и тонкой муторной растройки (очень не хочется возвращаться к нему).
   • gulp-image — использовал раньше в своих проектах как замену imagemin, хорошо жмёт, не требует тонны плагинчиков, но судя по ридми требует некоторые системные либы (в Linux дополнительно ничего не требовалось ставить, но то Linux, в основном все на винде и макоси).
   • gulp-webp и gulp-avif — дополнения к предыдущим двум, потому что те не умеют геренировать webp и avif.
   • sharp — в принципе замена для libsquoosh, но gulp-плагин умеющий всё сразу пока отсуствует, и надо либо самим писать, либо ждать, пока кто-то напишет. Кстати, в gulp-avif @dean992008 именно sharp использует. Но нам то надо не только avif генерировать. В общем пока всё грустно с вариантом замены. Он кажется нежизнеспособным, потому что у нас вряд ли есть ресурсы запилить инструмент с функциональностью как у libsquoosh (чтобы и оптимизация была и конверты в webp и avif). Хотя может @dean992008 и смог бы 👀
2. Ограничение версии ноды
   • На новом сайте ноды кроме кнопок для закрузки инсталлятора уже предлагается установка через nvm для Linux/macOS и nvs для Windows, который есть и для Linux/macOS тоже. Попользовался nvs, но вернулся обратно на родной nvm (неудобно, что в терминале не видно сразу версию активной ноды). В принципе есть и nvm-win, в нём просто CLI чуть отличается, а так тот же nvm и студенты-виндопользователи удачно пользуются им. Вообще в целом лучше учить студентов сразу пользоваться нодой через nvm, чтобы не было проблем в дальнейшем с удалением и переключением ноды (а мне уже не раз приходилось «спасать» бывших студентов от ошмётков установленной системно ноды).
3. Отказ от jpg/png
   • Can I use... WebP image format — у webp уже очень хорошее покрытие даже глядя на caniuse, но если из этого всего выкинуть те версии, которых нет в browserslist в проектах, то поддержка будет 100%-я. Не знаю, как это бьётся с Лигой, но там вроде тоже 2 last versions нужны, так что вопрос скорее настройки автоматизации, а не соответствия программы требованиям Лиги. Но могу ошибаться. В общем в идеале было бы совсем отказаться от jpg/png, учить студентов экспортировать любой растр в png (чтобы по пути качество не терять) и сразу кидать его в squoosh.app откуда вынимать webp и avif, которые и класть прямо в source/img/, а автоматизацией просто копировать их оттуда в build/img/. Получается одноразовая оптимизация растра и уменьшение коптильни при каждой публикации пулреквестов. Ну и полная независимость учебной автоматизации от такой хрупкой (как оказалось) зависимости, как оптимизаторы растра. Но это счастье возможно только с обновлением всей программы и если ничему не противоречит.

Напомню, что всё это моё видение.

[firefoxic]

Я это выложил, потому что вот какая мысль пришла. Даже нынешние правки автоматизации не смогли попасть в текущую программу, потому что её (с кучей материалов) сильно изменять надо. Но если взять ещё какую-нибудь правку, например давнее желание избавиться от Less, то это опять много изменений в материалах. И возможный отказ от jpg/png в исходниках — снова куча изменений. Так может сначала добить автоматизацию до какого-то более-менее завершённого варианта и под него уже материалы переделывать один раз, а не на каждый чих. Кажется это сэкономит уйму сил и времени.

[nikolai-shabalin]

Так может сначала добить автоматизацию до какого-то более-менее завершённого варианта и под него уже материалы переделывать один раз, а не на каждый чих. Кажется это сэкономит уйму сил и времени.

Именно такой путь и выбран сейчас

[baileys-li]

Блин, если бы прочёл ишью, то меньше бы думал с утра, почему сборка не запускается 😁

Ну поскольку все равно нашел решение, которое устраивает меня, то кинул ПР.

Я сразу говорю, что мне будет лень откатывать размер 3x и переносить таску в галпфайл. Если нужно будет, то лучше кину всем из треда инвайты в мой форк. Я бы вас бы ещё в ревьюеры добавил, но нет такой опции.

А так, я помню, что Николай в отпуске

[baileys-li]

3. Отказ от jpg/png

Получается решил 2/3

На счёт третьего есть идея. В разметке оно в принципе есть не просит. Везде браузер сам может решить что лучше загрузить. Для фона в CSS я студентам советую заводить миксин на image-set и webp как дефолт. Так чуть выигрываем в Lighthouse.

Для защиты HTML 2 сойдёт, но в реальности техника Apple, которая ещё в ходу, может не поддерживать. Так что для себя идеально ещё чекать поддержку webp и по флагу ставить доп класс на body.

Я потом дооформлю решение и подумаю куда отправить.

[firefoxic]

Я пока вдумчиво не изучал PR, но из того, что понял пока такая мысль: это всё здорово, но было бы круче использовать это всё дело как вспомогательный вариант для 3 варианта.

Я всё-таки буду топить за 3й вариант, потому что:

1. Манипуляции растром на каждый чих (в том числе на CI) — это лишнее копчение неба (несколькими сотнями студентов, да ещё и некоторыми наставниками, вроде меня 😰), незачем даже в прод генерить этот растр, и уж тем более в дев-разработке.
2. То, что где-то на каком-то реальном проекте может быть какое-то ощутимое количество пользователей старых железок с яблоком на заднике — это уже реалии конкретно этого проекта, а на курсе предусмотреть все реалии всех проектов невозможно, нам важно подходам научить.

Поэтому я бы предложил такое. По подходу реализуем 3 вариант, то есть все необходимые файлы растра должны быть в source/img/, при этом вёрстка расчитана только на webp и avif, а самые исходные исходники растра (исключительно в png формате) пусть лежат только у студента в папке img/ внутри заигноренной для гита папки raw/ (у меня на проектах когда-то в такой всякие psd, ai и прочие pdf хранились, про git-annex тогда не знали мы 🤭).

И вот чтобы избавить студентов от ручной конвертации каждой версии каждой картинки в squoosh.app, добавить отдельную от тасок билда и дев-сборки таску обработки растра. Причём со всеми плюшками кэширования (которое вроде можно было и самим галпом организовать изящно), чтобы лишний раз уже конвертированное не не конвертировать. Производить конвертацию только если файл не конверировался ещё совсем или если кэш не совпадает (файл изменился).

Ещё раз: эту таску не подмешивать в таски buildProd и runDev. Вместо этого на запуск этой отдельной таски завести отдельный скрипт, чтобы студенты после добавления/изменения картинок в raw/img/ руками запускали npm run convertImages, получая в исходниках нужные файлы растра.

Резюмирую: не нужно (по крайней мере в обучении) таскать по сети и занимать на дисках гигбайты в виде никому не нужных жипегов с пэнэгешками (и тем более их оптимизацией заниматься), как и не нужно (ещё больше на обучении) заводить конвертацию растра на каждый чих при разработке и сборке в прод (gh-pages), а вот автоматизация самой конвертации — это хорошо :)

[baileys-li]

Манипуляции растром на каждый чих — это лишнее копчение неба

Там ≈96% всех манипуляций будет сводиться к "достать из кэша файл" ¯_(ツ)_/¯

в том числе на CI

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

это уже реалии конкретно этого проекта

Сомнительно, но ок.

Я бы хотел бы чтобы на ретро или в скринкастах четко показали, что «в реальности от вас скорее всего потребуют делать вот (скрин с <picture /> со всеми форматами), но в рамках курса будет легче оставить только прогрессивные форматы»

Как убрать оригинальные форматы закомментировал в ПР. По идее ты можешь прямо в ПР добавить suggestions в batch и закомитить их одним коммитом, если хочешь

source/img/

Давайте source/image/ кстати

внутри заигноренной для гита папки raw/

Идею понял. Но в реальном проекте я бы остановился на своём варианте.

Просто чтобы покрыть кейс — Ой, клиенту не понравилось сжатие картинок, повысьте качество для всех — Ой, а мы удалили исходники. Придётся заново вырезать из макета . Блин

[baileys-li]

В общем пусть ещё Николай даст фидбек. Предлагаю запланировать встречу в КурилкеГоворилке в Учительской, когда он выйдет из отпуска

[baileys-li]

Переделал под вариант Сергея (но от png/jpg пока не отказываемся)

[efiand]

Есть ли смысл подправить вотчер так, чтобы не происходила реоптимизация вообще всех картинок подряд? А происходила бы только для текущей измененной картинки, наподобие https://github.com/efiand/gulp-static/blob/main/gulpfile.js#L214-L223 ?

[baileys-li]

@efiand да вроде нет.

Сначала я я подключал другой пакет на кэширование результатов, так что он просто скипал уже оптимизированные картинки.

А потом Сергей предложил просто следить за временной папкой, картинки из которой не попадают в гит и после оптимизации исходники можно удалить

[efiand]

А потом Сергей предложил просто следить за временной папкой, картинки из которой не попадают в гит и после оптимизации исходники можно удалить

Да, временная папка это хорошо, я сам так делаю, но ведь туда попадут оптимизаты именно исходников, чтобы их не хранить в нескольких копиях и минимизировать путаницу от этого. Да, гитхаб резиновый, но тут движет та же совесть, что заставляет экономить 6 функций в памяти. И тут уже хочется не перетряхивать создание webp или в данном случае ещё и avif и всех уменьшенных копий при добавлении одинокой картинки.

Ещё заметил, что у нас часто летают туда-сюда статичные файлы, тогда как сервак можно натравить на билд и сырцы одновременно, опция server принимает массив.

[firefoxic]

А ещё можно студентов учить страницу 404 делать. Но для этого надо сборку сразу давать, а не когда весь проект уже свёрстан.

[efiand]

А ещё можно студентов учить страницу 404 делать

Это тоже очень хорошее дело, но я этому обычно учу только тех, кто хотел шаблонизатор (сам или после моего предложения). Ибо "мартышить" - мне кажется, не надо приучать. Я бы вообще на первом интенсиве давал одностраничник, как на грейдировании (хотя бы в объеме обособить лэйаут с шапкой и подвалом от заменяемых страничных частей), а на втором уже шаблонизатор, там и страница 404 ничего не будет стоить.

[firefoxic]

В общем по хорошему простейшая сборка должна быть уже на html1 (ведь от html/css они сейчас ошарашиваются не на нём, а на подготовительном курсе). Достаточно обработки стилей автопрефиксером и csso (по дефолту в портянке, но подключить склейку импортов для тех кто жаждет), сборка стека из иконок (это оказывается легко даётся студентам — всего-то понять как пути менять с «к файлу» на «к фрагменту»), ну главное — линтинг! А на html2 надо уже по возможности полную машинерию, но с возможностью постепенного вкатывания: твиг-шаблонизация как возможность совсем не писать шаблоны и/или постепенно выделять куски в них; сразу нормально продуманная система обработки графики (и пофиг, что не понятно им будет, как и в случае со стеком на html1, им не надо понимать как оно собирается). Ну и выкидывать лучше этот галп… одни мучения от него 🤕

[efiand]

твиг-шаблонизация как возможность совсем не писать шаблоны

Я под этим соусом студентам твиг и продаю. И что паг мэйнстримный им потом все равно легче дастся, чем с полного нуля, то есть занятие не бесполезное.

Ну и выкидывать лучше этот галп… одни мучения от него 🤕

webpack, parcel, vite? В целом, думаю, будущее за последним.

[baileys-li]

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

Не совсем тебя понял. Да файлов в репе много больше. Но они и так были. Просто в ветке билд.

webpack, parcel, vite? В целом, думаю, будущее за последним.

Все ещё считаю Astro оптимальный выбор под курс. Вчера как раз видел новичка, который её освоил

[efiand]

Да файлов в репе много больше. Но они и так были.

Раньше webp генерировались на лету, и происходило это для всех картинок при изменении лишь одной. Теперь логично таким же образом не хранить в сырцах копии меньших изображений ретины, если их можно собрать на основе крупных. А еще avif. Перетряхивать всё это на каждое изменение одной картинки выглядит расточительным, хранить в сырцах весь зоопарк вариантов и форматов - как будто тоже не совсем правильно.

Я папку place использую только для однократной минификации и раскидывания по типам - static/img будут источниками webp, static/ уже нет, это фавиконки потому что. static/img/.svg не будут более модифицироваться, они однократно прошли svgo, source/icons будут подхвачены для спрайта и, соответственно, не попадут как есть в build/img. Для этого в place предусмотрены подпапки.

[efiand]

Astro выглядит клёво, но не выглядит универсально и базово для становления не astro-разработчиком, а просто. В некотором роде opinionated-настройка над тем же vite. С этой точки зрения можно и на sveltekit начать учить, я только за. И там столько сахара, что новичок дойдет до создания чего-то товарного, но шаги влево или вправо уже проблематичны.

[baileys-li]

Раньше webp генерировались на лету, и происходило это для всех картинок при изменении лишь одной.

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

Astro выглядит клёво, но не выглядит универсально и базово для становления не astro-разработчиком, а просто.

Нууу хз. Как по мне очень близко к ваниле. Есть сахар, но он довольно грамотный. Плюс мета фреймворк и упор на SSG

С этой точки зрения можно и на sveltekit начать учить,

SvelteKit клёвый, хотел бы поработать с ним коммерчески. Но там больше opinionated. Взять хотя бы плюсы в названиях файлов. И он дальше от ванильности чем Atro (но ближе чем Next.js офк)

[efiand]

как-то проще.

Видимо, потому что не всем кажется понятной задача настроить коллбэк для chokidar у галп-вотчера. Я ведь нигде в сборках и не видел подобного, все гоняют кучу данных почем зря при точечных изменениях. Мысль об изысканиях в этом направлении возникла из какого-то хабракоммента к одной из статей Академии. Кэш - наверное, это хорошее решение, но это, имхо, борьба с симптомами, а не с причиной. Лучшим вариантом кажется не сверять ненужное при отправке в конвейер, а просто не отправлять.

так что он просто скипал уже оптимизированные картинки.

А если нам нужно перестроить картинку и, соответственно, инициировать пересоздание avif и webp, и в новой версии - уменьшенные их копии не-ретиновые.

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

Astro в целом выглядит интересно. Но если даже думать о Vite с ванилой - все равно в целом смягчение программы (в сравнении с моими ощущениями от 2018) приводят к тому, что до акселератора доходят студенты, кто и в галпе не успел разобраться, а в Лиге их галп и ждет. Выпускникам профессии "Astro-разработчик" в Лиге будет трудно, кмк.

[firefoxic]

в Лиге их галп и ждет. Выпускникам профессии "Astro-разработчик" в Лиге будет трудно

Я если честно вообще в шоке от того, что там в Лиге со сборками. Казалось бы уж вот Лига то не скована программой и критериями курса, которые обновить целая история (не на один год как выясняется), и уж им то ничего не мешает обновлять свой туллинг для упрощения и ускорения работы лиговцев. И уже под нужды бегущей впереди Лиги можно было бы курсы корректировать. Но нет, там только недавно обновилась сборка, но так обновилась, что мне что-то аж поплохело на неё смотреть.

Что мешает в лиге зафигачить сборку на vite? Ведь не нужно кучу всего переделывать в программе с инфы про галп на инфу про vite. Нужно просто сказать, что не нужно теперь искать папку build и кричать «всё пропало» от не нахождения её при запуске. В остальном же для верстаков идущих в Лигу было бы всё так же: в конфиги не лезь, свои исходники клади сюда → там ридмишка что и куда именно. Всё!

Vite — условность. Любую другую сборку подставьте нетухлую, в которой не надо думать о том «как бы нам графику лишний раз не гонять по папкам», ибо там оно не гоняется.

[efiand]

что мне что-то аж поплохело на неё смотреть.

Мне объясняли положение вещей единообразием в целях поддержки легаси, что успели наделать за минувшие годы. Про смену сборки в команде джунов согласен полностью.

Касательно сборки, где не надо гонять, это можно и на галпе: place-папки, gulp.watch().on('all', <коллбэк для точечного создания из изменившейся картинки webp, awif, non-retina>). Хот-релоадинг, возможно, нетривиален посредством browser-sync, я не добрался до настройки, ибо уже смотрю в сторону vite, но холодной перезагрузки на мелких студенческих проектах за глаза.

[baileys-li]

@nikolai-shabalin закрываешь ишью?

[nikolai-shabalin]

Как только с картинками разберусь

[nikolai-shabalin]

Кто-нибудь может заглянуть в #45? Там, и работа с картинками, и обновлением ноды.

[firefoxic]

А ещё не пора от png/jpg отказаться? ))

[nikolai-shabalin]

А ещё не пора от png/jpg отказаться? ))

В HTML2 можно. Можно у учительской осбудить для HTML2.

Мы это в компании уже года два назад обсуждали, но к единому мнению не пришли.

[nikolai-shabalin]

Мяу. Теперь работает 20 нода