Веб-страница

Connection Allowlist в Chrome может отключить вход через FedCM Chrome добавил сайтам способ заранее ограничить все сетевые подключения страницы. Механизм включается добровольно через заголовок Connection-Allowlist, но после включения любое забытое направление блокируется. Под удар попадает и FedCM — браузерный протокол для кнопок федеративного входа. В Chrome 152 владельцу сайта нужно вручную разрешить все адреса поставщика удостоверений. В список входят конечные точки .well-known, Config, Accounts, ID assertion, Disconnect и Client metadata. Запись может выглядеть так: ("https://idp.example/*" response-origin). Без этих разрешений интеграция FedCM может повести себя не так, как ожидается, вплоть до того, что пользователь не сможет войти. Google описала этот побочный эффект отдельно. Для сайта с таким входом нужно сопоставить заголовок со всеми конечными точками провайдера до включения механизма. Пока Connection-Allowlist не задан, сетевое поведение страницы остаётся прежним.

pnpm закрыл глобальную подмену реестра через файл проекта pnpm — пакетный менеджер для JavaScript и TypeScript с общим хранилищем пакетов на диске и строгим деревом зависимостей. В версии 12.1.0 он перестал принимать настройку scope из pnpm-workspace.yaml: закоммиченный в репозиторий файл через неё дотягивался до глобальной конфигурации разработчика. Цепочка срабатывала на обычном pnpm login. Репозиторий держал в pnpm-workspace.yaml строку вида scope: acme, логин подхватывал её наравне с флагом --scope и дописывал маршрут @acme:registry в машинно-глобальный auth.ini — файл вне репозитория, который pnpm считает доверенным источником и который перебивает ~/.npmrc в каждом проекте на машине. В выводе команды при этом было видно только Logged in on https://registry.npmjs.org/, про scope ни слова. Дальше пакеты @acme/* резолвились с записанного реестра и в проектах, к тому репозиторию отношения не имеющих. Теперь такой scope игнорируется, а pnpm подсказывает, где его задавать: флагом --scope, переменной PNPM_CONFIG_SCOPE или в глобальном конфиге. Поведение унаследовано от npm CLI и повторяется в pacquet, поэтому в трекере это завели обычной задачей на укрепление, без security-advisory. Оговорка про версии: 12.1.0 и 11.25.0 вышли 29 августа под тегами next-12 и next-11, а latest на 30 августа всё ещё показывает на 11.24.0. Проверить pnpm-workspace.yaml в своих и чужих репозиториях на строку scope и заглянуть в глобальный auth.ini на лишние маршруты можно уже сейчас.

Svelte ускорил старую реактивность, которой всё ещё много в проектах Команда Svelte выпустила обновление для проектов, где сохранились реактивные выражения с двоеточием. Именно такой код платил лишнюю цену при сортировке зависимостей, хотя приложение могло годами работать без перехода на руны. В Svelte 5.57.0 поиск по Map в этом месте перевели с квадратичной сложности на линейную. Изменение относится к legacy-реактивности; для кода на рунах эта оптимизация не заявлена. Процента ускорения приложения целиком авторы не приводят: в описании релиза указана только смена сложности алгоритма. В том же выпуске кеш сеттеров перевели с массива на Set, SSR-маркеры сворачиваются в первый push, а для единственного дочернего элемента генерируется вызов only_child. Оптимизация прежде всего касается проектов, которые сохранили старый синтаксис Svelte. На GitHub релиз собрал 13 реакций к 30 августа 2026 года.

Push to deploy без долларовой карты: что выросло на месте Heroku Схему, которую Heroku придумал в 2008-м, до сих пор трудно переплюнуть: git push — и через минуту сайт живой. Vercel, Render, Railway и Netlify выросли из той же идеи, но упираются в одно и то же: оплата долларовой картой и серверы не здесь. На Tproger вышел разбор от команды, которая четыре года собирала российский аналог: MVP за полгода, потом деплой через MCP прямо из Codex и Claude, встроенная IDE с агентом, управляемый PostgreSQL с pgVector и прокси к API OpenAI, Anthropic и Telegram, чтобы приложение в московском регионе не упиралось в блокировки. Отдельным блоком — честное сравнение с каждым из пяти конкурентов: где похоже, где хуже, где иначе. В нашем канале Tproger разобрали подробнее.

В Node.js завезли работу с ZIP без единой зависимости Распаковать архив в Node до сих пор означало тащить adm-zip, yauzl или jszip — за одну операцию вы получали в дерево зависимостей чужой код, который потом надо обновлять и проверять на уязвимости. В Node.js 26.8.0 от 26 августа в модуль zlib добавили ZipEntry, ZipFile и ZipBuffer. Читать архивы и разбирать их по записям теперь можно средствами платформы. Что ещё в релизе: — net.BlockList заметно ускорили, а TracingChannel в diagnostics_channel объявлен стабильным; — в Cipher и Decipher включили режимы SIV и GCM-SIV: шифрование, устойчивое к повторному использованию nonce, что чаще всего и ломает AES-GCM в чужом коде; — у StatementSync во встроенном sqlite появились close() и поддержка Symbol.dispose, то есть подготовленный запрос можно держать в using; — MIMEType.parse разбирает тип и возвращает null вместо исключения на мусоре; — в REPL появилась базовая подсветка синтаксиса; — корневые сертификаты обновлены до NSS 3.126. 26.x — текущая линейка Current; в LTS zlib с ZIP приедет позже, так что в прод пока не тащите. #nodejs

Zod научился компилировать схемы и стал быстрее в разы До версии 4.5 парсер интерпретировал схему прямо во время валидации: на каждый parse() Zod обходил дерево и по ходу решал, что проверять. Во вчерашнем релизе появился z.compile() — он один раз проходит схему целиком и генерирует под неё плоский JavaScript без циклов, который выполняется через new Function(). На валидных данных срабатывает быстрый путь, на невалидных Zod возвращается к обычному парсеру за подробной ошибкой. Собирать ничего не нужно, всё происходит в рантайме: import "zod/compile" в точке входа или флаг node --import zod/compile включают компиляцию для всех схем сразу. Ускорились и отказы — .safeParse() перестал захватывать стек-трейс и на неудачном пути стал быстрее примерно в 7,5 раза. Перед обновлением проверьте два места: z.iso.datetime() больше не принимает время без секунд (2020-01-01T06:15Z теперь ошибка), а .min(), .max() и .length() у строк считают кодовые точки Unicode вместо кодовых единиц UTF-16. #javascript #перформанс

Файл про офисных котов прошёл все четыре «доказательства» пользы llms․txt Последний год клиентам продают llms․txt — файл в корне сайта, который якобы помогает попасть в ответы языковых моделей. Доказательства всегда одни и те же: ботам файл скачали, Google его проиндексировал, модель пересказала его содержимое, ChatGPT подтвердил, что это помогает ранжированию. Марк Уильямс-Кук проверил эту логику так: придумал стандарт cats․txt, в котором сайт формально декларирует своих офисных котов — имена, должности, породы и обязательную метрику привязанности PurrLevel по десятибалльной шкале. Написал спецификацию, опубликовал в блоге и отдельно вынес в LinkedIn, потому что модели к этой площадке по непонятной причине благосклонны. Все четыре «доказательства» файл прошёл, не запнувшись. Боты его скачали, Google проиндексировал, модели начали пересказывать подробности про кота Odd, который не существует нигде, кроме этого файла, а ChatGPT пространно подтвердил, что cats․txt может помочь ранжированию. Идею подхватили: кто-то добавил файл себе на сайт, кто-то поднял catstxt.org с более аккуратной спецификацией, чем оригинал. Про сам llms․txt автор отдельно оговаривает: ни OpenAI, ни Anthropic, ни Google не документировали его использование в поиске. Джон Мюллер из Google высказался прямее: ни один чат-бот файл не скачивает, это видно по логам сервера. Ahrefs прогнал 100 000 доменов и увидел, что краулеры, ради которых файл кладут, в основном его игнорируют; отдельные крупные исследования не нашли и прироста цитирования. Вывод, который стоит забрать: набор наблюдений становится доказательством, только если он мог бы не случиться при ложной гипотезе. Скачали, проиндексировали, пересказали — происходит с любым текстовым файлом в корне. #seo #ии

htmx 4.0 вышел и намеренно не стал версией по умолчанию Восемь месяцев работы, релиз сегодня. Для пользователя четвёртая версия почти совпадает со второй, но внутри библиотека переехала с XMLHttpRequest на fetch() — ради этого всё и затевалось. Главных изменений авторы называют три, и заметнее прочих наследование атрибутов. В htmx 2 атрибут на родителе по умолчанию действовал на потомков, как в CSS: hx-confirm на div спрашивал подтверждение у каждой кнопки внутри. В htmx 4 наследование включается явным суффиксом: <div hx-confirm:inherited="Точно?"> <button hx-delete="/item/1">Удалить</button> </div> hx-disinherit при этом исчез, его следует убрать. Дальше — имена событий, приведённые к схеме htmx:<фаза>:<система>, и история навигации, которая перестала по умолчанию храниться локально: авторы называют старый кэш источником многих обращений в поддержку. Полный список несовместимостей длиннее трёх пунктов и лежит в руководстве по миграции. Тег latest в npm остался на ветке 2.x примерно до начала 2027 года, чтобы не переключить силой тех, кто подключает htmx с CDN без указания версии; четвёртая ветка живёт под next. Места, которые надо чинить, ищет команда upgrade-check из комплекта. #javascript #фронтенд

Разница между «у нас есть бэкап» и «мы готовы к аварии» — примерно как между наличием огнетушителя и умением им пользоваться при пожаре. Первое не гарантирует второе, а узнают об этом обычно в момент, когда сервис лежит у всех на глазах, включая руководство и клиентов. На самом деле готовность инфраструктуры к сбою определяет не факт хранения копий, а расчёт допустимого времени простоя, структура плана восстановления и техническая настройка репликации, которую проверяют заранее регулярными учениями переключения на резервную площадку. Будет полезно инфраструктурным инженерам, техлидам и руководителям, которые хотят сделать свои системы реально устойчивыми к авариям. Больше об аварийном восстановлении: 1. Почему бэкап есть, а восстановиться не получится: разбор точек отказа 2. Как должен выглядеть DR-план, который сработает в аварию 3. Аварийное восстановление до аварии: как настроить DRaaS, пока ничего не упало

WebGPU в Unity вышел из эксперимента Начиная с версии 6000.6 WebGPU в Unity — полноценный графический бэкенд с обычной поддержкой, а не экспериментальная опция. Для браузера это вычислительные шейдеры, а с ними отсечение невидимого на GPU, апскейлер STP, VFX Graph на миллионы частиц и скиннинг на GPU: на WebGL 2 всё это было недоступно. Ловушка при выкладке чисто веб-разработческая: WebGPU браузер отдаёт только в защищённом контексте, поэтому сборка, открытая по обычному HTTP или файлом с диска, молча откатится на WebGL 2. В нашем канале «GameDev» разобрали подробнее, как его включить и почему WebGL 2 нельзя убирать из списка.