Dev News от Максима Соснова

Дайджест за 2026-09-07 - 2026-09-09

Playwright v1.62.0
Вышел релиз Playwright 1.62. Обычно я не пишу про релизы Playwright, но тут важное событие — допилили component testing. Текущее решение чем-то похоже на описание компонентов для Storybook.

Mobile View — see your site on desktop & mobile at once
Расширение для Chrome от подписчика — Mobile View. Позволяет легко посмотреть, как сайт выглядит на мобильном устройстве, в разных ориентациях, со снятием скриншотов, видео и прочими фичами. Можно запустить сразу 5 эмуляций в рамках одной сессии. Попробовал сам — выглядит действительно супер удобно и прям красиво.

——————————————

Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.

Mobile View — see your site on desktop & mobile at once

Расширение для Chrome от подписчика — Mobile View. Позволяет легко посмотреть, как сайт выглядит на мобильном устройстве, в разных ориентациях, со снятием скриншотов, видео и прочими фичами. Можно запустить сразу 5 эмуляций в рамках одной сессии. Попробовал сам — выглядит действительно супер удобно и прям красиво.

Это, конечно, не полноценный симулятор, но решение очень хорошее как для тестирования, так и для демонстрации.

Строго рекомендую хотя бы ознакомиться.


https://mobileview.app/

#development #chrome #tools #responsive #frontend

Playwright v1.62.0

Вышел релиз Playwright 1.62. Обычно я не пишу про релизы Playwright, но тут важное событие — допилили component testing. Текущее решение чем-то похоже на описание компонентов для Storybook.

Забавно, что инструкция по установке начинается с «запустите LLM». Буквально.

> Step 1: Point your coding agent at the skill

npx playwright init-skills

Set up component testing using the playwright-component-testing skill.

Затем надо немного сконфигурировать конфиг Playwright.

Затем создать давно знакомые нам stories-файлы
src/components/Button.story.tsx

import { Button } from './Button';

export const Primary = () => <Button title='Submit' />;

export const Disabled = () => <Button title='Submit' disabled />;

Т.е. по сути один в один истории Storybook. Интересно, не будет ли конфликтов? Пока выглядит, что Playwright-сборка должна будет уметь обрабатывать и исполнять все плагины и декораторы Storybook, либо придётся как-то делить истории Storybook и истории Playwright.

Затем пишем тесты

import { test, expect } from '@playwright/test';

test('renders primary button', async ({ mount }) => {
  const component = await mount('components/Button/Primary');
  await expect(component.getByRole('button')).toHaveText('Submit');
});

test('disabled button is disabled', async ({ mount }) => {
  const component = await mount('components/Button/Disabled');
  await expect(component.getByRole('button')).toBeDisabled();
});

Затем запускаем

npx playwright test --project=components

В доке также описаны ещё основные паттерны для тестирования. На них останавливаться не буду.

Надо будет попробовать в своём пет-проекте.

https://github.com/microsoft/playwright/releases/tag/v1.62.0

#development #playwright #testing #component-testing #releaseNotes

Дайджест за 2026-08-31 - 2026-09-04

How to find a Next.js memory leak in production
Очень хорошая и практичная статья про утечки памяти в Next.js. Чел рассмотрел 3 утечки (которые уже исправлены — поэтому обновляйтесь) и то, как их правильно диагностировать.

Canvas UI
Canvas UI — open-source библиотека готовых компонентов для создания красивых эффектов на основе технологии html-in-canvas, которая пока что включена только в Chrome и там за флагом. Эффект стекла, жидкости, VHS и другие готовые эффекты, оформленные как компонент, в который можно обернуть ваш HTML.

Measuring soft navigations
Web Vitals стали основным мерилом скорости работы сайтов. Но при этом Web Vitals плохо покрывают сценарии с SPA-переходами. Из-за этого почти никто не следил за скоростью работы сайтов при SPA-переходах. Но Google придумали методику для замеров SPA-переходов, и в новом Chrome за флагом доступны метрики Soft Navigations.

——————————————

Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.

Measuring soft navigations

Web Vitals стали основным мерилом скорости работы сайтов. Но при этом Web Vitals плохо покрывают сценарии с SPA-переходами. Из-за этого почти никто не следил за скоростью работы сайтов при SPA-переходах. Но Google придумали методику для замеров SPA-переходов, и в новом Chrome за флагом доступны метрики Soft Navigations.

Что определяется как soft navigation:
1. Действие перехода инициировал пользователь
2. Пользователь видит изменение URL
3. Есть видимое изменение (paint)

Спека пока обсуждается, поэтому могут быть изменения. На странице очень подробно описано, какие изменения будут у записей в Performance API (новые типы Entry + navigationId для идентификации метрик каждой отдельной страницы), как их включить, обрабатывать и мониторить.

Очень большой и подробный гайд. Ждём стабилизации.


https://developer.chrome.com/docs/web-platform/soft-navigations

#development #chrome #performance #web-vitals #spa #browser

Canvas UI

Canvas UI — open-source библиотека готовых компонентов для создания красивых эффектов на основе технологии html-in-canvas, которая пока что включена только в Chrome и там за флагом. Эффект стекла, жидкости, VHS и другие готовые эффекты, оформленные как компонент, в который можно обернуть ваш HTML.

Вместо тысячи слов лучше пройти по ссылке и посмотреть, как это выглядит. А выглядит это прям бомбически.

Также в библиотеке предусмотрено graceful degradation для браузеров, где не включен html-in-canvas, но результат может быть хуже.

https://canvasui.dev/

#development #webgl #canvas #ui #react #frontend

How to find a Next.js memory leak in production

Очень хорошая и практичная статья про утечки памяти в Next.js. Чел рассмотрел 3 утечки (которые уже исправлены — поэтому обновляйтесь) и то, как их правильно диагностировать.

Если ваше приложение использует Next.js версии между 15.5 и 16.2, то в них есть 3 задокументированных утечки памяти. Вот как их диагностировать:

1. Если утечка медленная и коррелирует с количеством уникальных урлов, которые обслужило приложение, то это утечка Router LRU-кеша
2. Если утечка пропорциональна трафику, то вполне вероятно это утечка дерева рендеринга
3. Если утечка не плавная, а ступеньками, а запросы обрабатываются через middleware, то это утечка айдишников таймаутов

Немного подробнее про каждую утечку.

№1: У роутера в Next.js есть LRU-кеш, и его размер ограничен одним мегабайтом. Но размер определяется некорректно. Собственно сами урлы и не учитываются, что даёт возможность для утечки на сотни мегабайт. Банально любой бот, который перебирает урлы, вызовет эту утечку. Если не можете обновиться — отфильтровывайте урлы до их обработки роутером Next.js.

№2: Дерево RSC-рендера не освобождается, если клиент разорвал соединение. Утечка может достигать 2 МБ на 1 отменённый запрос (что вообще-то нехило).

№3: У middleware отдельный TimeoutsManager, который хранит id таймаутов. id отпускается только если явно вызвать clearTimeout.

А дальше интересный личный кейс автора. У него приложение крутилось как serverless на Vercel, поэтому вместо OOM он получал 504 FUNCTION_INVOCATION_TIMEOUT на tag-страницах блога.

Автор провёл расследование. Сначала подозревал рендер MDX, но оказалось, что он достаточно быстрый — до 100 мс. Оказалось, что причина в функции, которая резолвила slug для страницы. Чтобы зарезолвить один единственный slug, функция грузила и парсила все посты для каждого слага, что давало квадратичную сложность и выливалось в 18 тысяч чтений с диска и 30 секунд на рендер.

Фикс простой: вместо парсинга всех постов на каждый запрос — распарсить единожды и сложить в кеш на инстанс. Скорость работы после исправления:
- next build: ~17.5 мин → 34 сек
- prerender поста: ~32 сек → ~1.6 сек
- on-demand tag page: 504 → ~134 мс

Для поиска утечек автор собрал CLI `next-leak`, который автоматизирует диагностику.

Также отдельно отмечу, что у автора очень красиво задизайнен блог. Не знаю, готовая ли это тема или он сам собрал — но выглядит очень красиво.


https://xabierlameiro.com/blog/nextjs/nextjs-memory-leak-in-production

#development #nextjs #memory #performance #debugging

Дайджест за 2026-08-24 - 2026-08-28

Check out the New Node.js API Documentation Preview
Команда Node.js готовит новый сайт с докой. Контент не изменился, изменилась оболочка. Посмотреть можно тут: beta.docs.nodejs.org.

When and what should I be logging?
Sentry написали гайд «когда и что логировать». Гайд не прям чтобы открывал глаза на какие-то новые концепции, но как интро вполне норм.

We Stopped Using RSC on TanStack.com
История о том, почему на tanstack.com отказались от RSC. Сначала перешли на RSC и стало лучше, а потом поняли, что можно было оптимизировать изначальное решение — и тогда бы RSC не понадобился.

——————————————

Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.

——————————————

Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы

We Stopped Using RSC on TanStack.com

История о том, почему на tanstack.com отказались от RSC. Сначала перешли на RSC и стало лучше, а потом поняли, что можно было оптимизировать изначальное решение — и тогда бы RSC не понадобился.

Как было. Есть сайт с докой, в которой используются тяжёлые библиотеки для рендера markdown и подсветки синтаксиса. Суммарно эти библиотеки занимали 358 КБ.

Как сделали. Включили RSC, тяжёлые библиотеки остались на сервере, на клиент идёт сразу готовый рендер. И перформанс-метрики сразу подскочили. Но позже оказалось, что RSC несёт свои проблемы и неудобства.

Затем инженеры подумали, что переход на RSC — это, возможно, было неверное решение. Перенесли рендер на бэкенд вместо того, чтобы оптимизировать сами тяжёлые зависимости.

Что переделали. Взяли более лёгкие библиотеки, допилили их и вернулись на обычный SSR. Получили заметное ускорение работы + упрощение архитектуры.

Какой итог:
- RSC хорош для решения проблемы с «тяжёлым» кодом
- Но он даёт сложность. Если есть вариант обойтись без RSC — стоит рассмотреть этот вариант.


https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com

#development #react #rsc #tanstack #performance #ssr

When and what should I be logging?

Sentry написали гайд «когда и что логировать». Гайд не прям чтобы открывал глаза на какие-то новые концепции, но как интро вполне норм.

Итак, что надо логировать:

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

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

Аудит. Если пользователь или система делает какое-то действие, необходимо логировать, кто и что сделал. Любые создания, обновления и удаления сущностей.

Контекст вокруг ошибок. Недостаточно просто залогировать ошибку. Нужно логировать весь контекст, в котором она произошла — какой это был ретрай, какой статус-код, какой URL и всё остальное, что может помочь при дебаге.

Как писать логи:
Используй структурированные логи. Не просто строка в логах, а структура. Например, JSON-объекты. В идеале логи должны содержать ответы на вопросы «что произошло?», «кто это сделал?» и «когда это произошло?».

Наращивай контекст логов. Сначала пользователь может быть неавторизован, но когда он авторизовался — его данные (userId, например) должны попадать в контекст последующих логов. Отдельно полезно делать связь логов через трейсинг.

Что не надо логировать

Избыточное логирование. Не надо логировать вызов всех функций и всех строчек кода.

Секреты и персональные данные. Тут в целом всё понятно.

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


https://blog.sentry.io/logging-best-practices/

#development #logging #observability #sentry #best-practices

Check out the New Node.js API Documentation Preview

Команда Node.js готовит новый сайт с докой. Контент не изменился, изменилась оболочка. Посмотреть можно тут: beta.docs.nodejs.org.


https://beta.docs.nodejs.org

#development #nodejs #documentation #dx

Дайджест за 2026-08-17 - 2026-08-21

postmortem.io · the library of real postmortems
postmortem.io — каталог публичных engineering postmortems. Каждая запись — краткая выжимка (скорее всего через LLM) + ссылка на оригинал для ознакомления. Если вы связаны с SRE в любом его проявлении — можете использовать как справочник проблем + примеров хороших постмортемов.

The secure way to release an npm package in 2026
Огромная статья от Evil Martians про то, как в 2026 публиковать npm-пакеты, чтобы их было сложнее угнать. В статье в самом начале есть чеклист, что надо сделать, чтобы снизить вероятность кражи пакета. А после чеклиста — почему именно важен каждый шаг и как выстраивается система защиты.

npm publish-time malware scanning and dual-use metadata
npm включает автоматический скан на зловреды в момент публикации пакетов, до того как пакет станет доступен для установки.

——————————————

Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.

——————————————

Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы

npm publish-time malware scanning and dual-use metadata

npm включает автоматический скан на зловреды в момент публикации пакетов, до того как пакет станет доступен для установки.

Как это работает:
- Вы публикуете пакет
- npm сканирует его. Сканирование может идти до 15 минут для больших пакетов
- Если всё ок — пакет будет доступен для скачивания
- Если не ок — то либо будет ручное ревью, либо блокировка публикации
- В случае блокировки пришлют уведомление. В худшем случае могут потребоваться действия с аккаунтом.


https://github.blog/changelog/2026-07-28-npm-publish-time-malware-scanning-and-dual-use-metadata/

#development #javascript #npm #security #supply-chain #github

The secure way to release an npm package in 2026

Огромная статья от Evil Martians про то, как в 2026 публиковать npm-пакеты, чтобы их было сложнее угнать. В статье в самом начале есть чеклист, что надо сделать, чтобы снизить вероятность кражи пакета. А после чеклиста — почему именно важен каждый шаг и как выстраивается система защиты.

В целом чеклист следует завету «не доверяй никому, кроме себя».

Чеклист:
1. Trusted Publisher: укажите конкретный воркфлоу, с которого можно только публиковать staged-версии библиотек
2. Запретить публикацию через токены
3. Включить 2FA для всех
4. Дать возможность создавать теги в GitHub только админам
5. Зафиксировать версии GitHub Actions, которые вы используете
6. Добавьте автоматический линт безопасности
7. Установите 3 дня кулдауна на новые версии зависимостей
8. Используйте npm 12 или другой пакетный менеджер, который не исполняет postinstall-скрипты
9. Создайте workflow для публикации, как в статье

Это не гарантия безопасности, но очень снижает риски того, что ваш пакет украдут.

От каких конкретно рисков защита:
1. Trusted Publisher — разрешаем публикацию только конкретному воркфлоу
2. Запрещаем публикацию напрямую (без стейджинга) и через токены. Если токен украдут — опубликовать не смогут. Сам стейджинг гарантирует ручной апрув
3. 2FA требует подтверждения через второе устройство
4. Т.к. публикация только по тегам, то разрешаем создавать теги только админам
5. Фиксация версий GitHub Actions позволяет не попасться на взлом CI Actions
6. Линт безопасности автоматически проведёт основные проверки безопасности
7. Кулдаун 3 дня на новые зависимости даёт время обнаружить malware до того, как вы его подтянете
8. Запрет postinstall-скриптов убирает целый кластер атак
9. Аккуратный publish-workflow (без лишних deps в critical job) сужает поверхность атаки при релизе

И, конечно же, в статье есть скилл для агента, который настроит всё за вас.

https://evilmartians.com/chronicles/the-secure-way-to-release-an-npm-package

#development #javascript #npm #security #ci #supply-chain #evilMartians

postmortem.io · the library of real postmortems

postmortem.io — каталог публичных engineering postmortems. Каждая запись — краткая выжимка (скорее всего через LLM) + ссылка на оригинал для ознакомления. Если вы связаны с SRE в любом его проявлении — можете использовать как справочник проблем + примеров хороших постмортемов.

https://postmortem.io/

#development #sre #devops #postmortem #reliability

Дайджест за 2026-08-10 - 2026-08-14

Announcing TypeScript 7.0
Вышел TypeScript 7.0 — нативный порт компилятора на Go. Ждали, и наконец дождались.

TanStack Charts
TanStack опубликовали ещё одну библиотеку — Charts. По названию понятно, что это библиотека для графиков.

Investigating three real-world incidents in our cybersecurity evaluations
Возможно, вы не слышали, но недавно модель OpenAI смогла выбраться из sandbox во время тестирования и взломать сервера Hugging Face. После этого инцидента Anthropic решили посмотреть, не было ли случайно у них таких кейсов. И оказалось, что были, но не такие мощные.

——————————————

Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.

——————————————

Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы

Investigating three real-world incidents in our cybersecurity evaluations

Возможно, вы не слышали, но недавно модель OpenAI смогла выбраться из sandbox во время тестирования и взломать сервера Hugging Face. После этого инцидента Anthropic решили посмотреть, не было ли случайно у них таких кейсов. И оказалось, что были, но не такие мощные.

Anthropic проводят исследование возможностей моделей, ставя им задачу в стиле CTF: флаг спрятан на другой машине, найди и достань. Модели говорилось, что она работает в симуляции и интернета нет. Однако из-за мискоммуникации с партнёром (видимо, тем, кто давал инфру) интернет всё-таки был (и эти люди будут нас учить секьюрити). Поэтому из 141 000 запусков в трёх из них модель вышла в интернет и сделала что-то плохое.

Кейс №1
В задании агенту дали название фиктивной фирмы и сказали, что флаг у неё. Однако, как говорилось выше, был доступ к интернету. А в интернете был вебсайт у одноимённой компании, который Claude и взломал — получил креды и доступ до продовой БД.

Кейс №2
В задании агент нашёл док для онбординга, в котором сказано, что сотруднику надо ставить определённый пакет с PyPI. Claude решил опубликовать этот пакет в PyPI, завернув туда зловред. Зловред скачали, он украл креды, Claude ими воспользовался. Отдельно интересно, что Mythos сказал: если бы это был реальный мир — это НЕ ОК, но т.к. это симуляция, то ничего страшного.

Кейс №3
Модель не нашла фейковую цель и пошла искать её в интернете. Просканировала 9000 хостов и взломала одно приложение, но поняла, что вышла за рамки задачи, и остановилась.


https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals

#development #ai #anthropic #security #claude

TanStack Charts

TanStack опубликовали ещё одну библиотеку — Charts. По названию понятно, что это библиотека для графиков.

Что обещают из коробки:
- Строгий TypeScript
- Framework-agnostic ядро + адаптеры: React, Vue, Solid, Svelte, Angular, Preact и другие
- SVG по умолчанию, Canvas опционально
- Отдельно делают скиллы или инструкции для ИИ. Прямо на главной в общем-то можно скопировать какой-то промпт для агента, чтобы он собрал демо-график.

https://tanstack.com/charts/latest

#development #typescript #javascript #charts #tanstack #react

Announcing TypeScript 7.0

Вышел TypeScript 7.0 — нативный порт компилятора на Go. Ждали, и наконец дождались.

Конечно же сразу идём смотреть цифры.

По скорости тайпчека крупные проекты стали проверяться в 7–12 раз быстрее (TS 6 → TS 7):

- vscode: 125.7s → 10.6s (11.9x)
- sentry: 139.8s → 15.7s (8.9x)
- bluesky: 24.3s → 2.8s (8.7x)
- playwright: 12.8s → 1.47s (8.7x)
- tldraw: 11.2s → 1.46s (7.7x)

А если увеличить количество воркеров — можно выйти примерно на 16x.

По памяти также есть улучшение, хотя и не такое заметное. Потребление памяти в этих же проектах падает на 5%-25%.

Также и все фишки typescript стали работать быстрее — проверка конкретного файла, go to definition и другие.

Отдельно радует фидбек разработчиков крупных компаний. Он одновременно хвалебный и показывает, какой же, извините, мрак у некоторых на проектах:
- Slack: typecheck в CI с ~7.5 мин до ~1.25 мин, merge queue быстрее на 40%
- Microsoft News Services: экономия 400 часов в месяц на ожидании CI
- Canva: first error в редакторе с ~58 сек до ~4.8 сек

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

Что ещё интересного в релизе:

Я уже выше упоминал воркеров. Так вот, процесс тайпчека теперь идёт параллельно в 4 воркера по умолчанию, но можно сделать больше. Воркеры частично повторяют работу друг друга, т.к. у них изолированная память, но для разных целей может потребоваться работать с одними и теми же объектами. Поэтому для окружений, где нужно оптимизировать использование ОЗУ, можно оставить одного воркера.

Для работы watch-режима сделали порт @parcel/watcher, который отлично себя показывает в vscode, на Go.

Для кейсов, где важна совместимость с TS6, оставили отдельный бинарь с реализацией ts6. В частности, совместимость нужна тем, кто использует typescript через API, т.к. у ts7 его ещё нет (ждём в 7.1).

Кто-то уже поставил себе?

https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

#development #typescript #javascript #tsgo #performance #releaseNotes

Дайджест за 2026-07-13 - 2026-07-17

Deno 2.9
Вышел Deno 2.9. Пропустил бы релиз, т. к. в целом всё как обычно — улучшают перформанс, улучшают DX, делают лучше интероп с другими пакетными менеджерами. Но в этом релизе добавили сборку desktop-приложений — можно получить GUI без Electron и других обвязок, Deno уже имеет всю инфраструктуру для этого.

Iterating faster with TypeScript 7
Статья от VS Code о том, как они мигрируют на новый TS 7. Т. к. VS Code и TypeScript принадлежат одной материнской компании (Microsoft), им очень удобно коллаборировать друг с другом. Более того, VS Code изначально был на TypeScript и шёл с ним рука об руку весь свой путь. В статье рассказывается, как за полгода они переехали на TS 7.

Node.js CLI Apps Best Practices
Сборник best practices от Liran Tal по Node.js CLI. 37 рекомендаций в 10 группах — от техники и безопасности до удобства работы в терминале. В каждом бест практисе есть описание, почему это важно и как не напортачить, ссылки на источники или готовые решения (например, в виде npm-пакетов). Также есть скилл, чтобы встроить все эти бест практисы в агента. MUST READ, если хотите делать крутые cli. Сборник очень хороший.

——————————————

Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.

——————————————

Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы