Dev News от Максима Соснова
前往频道在 Telegram
Привет! Меня зовут Максим Соснов и по утрам я читаю всякие разные дайджесты про фронтенд, разработку и управление разработкой. Самые интересные, по моему мнению, ссылки из этих дайджестов я кидаю в этот канал с небольшим описанием. Контакт: @msosnov
显示更多2 799
订阅者
无数据24 小时
-57 天
-2530 天
数据加载中...
相似频道
标签云
进出提及
---
---
---
---
---
---
吸引订阅者
九月 '26
九月 '26
+1
在0个频道中
八月 '26
+31
在0个频道中
Get PRO
七月 '26
+35
在0个频道中
Get PRO
六月 '26
+46
在0个频道中
Get PRO
五月 '26
+46
在1个频道中
Get PRO
四月 '26
+41
在0个频道中
Get PRO
三月 '26
+39
在0个频道中
Get PRO
二月 '26
+41
在0个频道中
Get PRO
一月 '26
+31
在0个频道中
Get PRO
十二月 '25
+27
在1个频道中
Get PRO
十一月 '25
+33
在1个频道中
Get PRO
十月 '25
+65
在2个频道中
Get PRO
九月 '25
+54
在1个频道中
Get PRO
八月 '25
+52
在0个频道中
Get PRO
七月 '25
+86
在7个频道中
Get PRO
六月 '25
+50
在0个频道中
Get PRO
五月 '25
+57
在0个频道中
Get PRO
四月 '25
+68
在4个频道中
Get PRO
三月 '25
+79
在2个频道中
Get PRO
二月 '25
+72
在2个频道中
Get PRO
一月 '25
+75
在1个频道中
Get PRO
十二月 '24
+88
在2个频道中
Get PRO
十一月 '24
+156
在1个频道中
Get PRO
十月 '24
+96
在1个频道中
Get PRO
九月 '24
+87
在0个频道中
Get PRO
八月 '24
+134
在3个频道中
Get PRO
七月 '24
+87
在1个频道中
Get PRO
六月 '24
+111
在0个频道中
Get PRO
五月 '24
+795
在2个频道中
Get PRO
四月 '24
+41
在0个频道中
Get PRO
三月 '24
+55
在1个频道中
Get PRO
二月 '24
+63
在1个频道中
Get PRO
一月 '24
+98
在1个频道中
Get PRO
十二月 '23
+94
在2个频道中
Get PRO
十一月 '23
+31
在1个频道中
Get PRO
十月 '23
+88
在1个频道中
Get PRO
九月 '23
+58
在0个频道中
Get PRO
八月 '23
+47
在0个频道中
Get PRO
七月 '23
+36
在0个频道中
Get PRO
六月 '23
+44
在0个频道中
Get PRO
五月 '23
+27
在0个频道中
Get PRO
四月 '23
+54
在0个频道中
Get PRO
三月 '23
+61
在0个频道中
Get PRO
二月 '23
+33
在0个频道中
Get PRO
一月 '23
+42
在0个频道中
Get PRO
十二月 '22
+35
在0个频道中
Get PRO
十一月 '22
+138
在0个频道中
Get PRO
十月 '22
+65
在0个频道中
Get PRO
九月 '22
+114
在0个频道中
Get PRO
八月 '22
+18
在0个频道中
Get PRO
七月 '22
+48
在0个频道中
Get PRO
六月 '22
+32
在0个频道中
Get PRO
五月 '22
+15
在0个频道中
Get PRO
四月 '22
+4
在0个频道中
Get PRO
三月 '22
+4
在0个频道中
Get PRO
二月 '22
+21
在0个频道中
Get PRO
一月 '22
+64
在0个频道中
Get PRO
十二月 '21
+6
在0个频道中
Get PRO
十一月 '21
+8
在0个频道中
Get PRO
十月 '21
+333
在0个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 01 九月 | +1 |
频道帖子
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| 2 | Дайджест за 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 не понадобился.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.
——————————————
Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы | 519 |
| 3 | 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 | 697 |
| 4 | 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 | 807 |
| 5 | Check out the New Node.js API Documentation Preview
Команда Node.js готовит новый сайт с докой. Контент не изменился, изменилась оболочка. Посмотреть можно тут: beta.docs.nodejs.org.
https://beta.docs.nodejs.org
#development #nodejs #documentation #dx | 768 |
| 6 | Дайджест за 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 включает автоматический скан на зловреды в момент публикации пакетов, до того как пакет станет доступен для установки.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.
——————————————
Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы | 777 |
| 7 | 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 | 904 |
| 8 | 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 | 916 |
| 9 | postmortem.io · the library of real postmortems
postmortem.io — каталог публичных engineering postmortems. Каждая запись — краткая выжимка (скорее всего через LLM) + ссылка на оригинал для ознакомления. Если вы связаны с SRE в любом его проявлении — можете использовать как справочник проблем + примеров хороших постмортемов.
https://postmortem.io/
#development #sre #devops #postmortem #reliability | 922 |
| 10 | Дайджест за 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 решили посмотреть, не было ли случайно у них таких кейсов. И оказалось, что были, но не такие мощные.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.
——————————————
Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы | 901 |
| 11 | 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 | 973 |
| 12 | 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 | 1 127 |
| 13 | 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 | 1 195 |
| 14 | Дайджест за 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. Сборник очень хороший.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.
——————————————
Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы | 1 178 |
| 15 | Node.js CLI Apps Best Practices
Сборник best practices от Liran Tal по Node.js CLI. 37 рекомендаций в 10 группах — от техники и безопасности до удобства работы в терминале. В каждом бест практисе есть описание, почему это важно и как не напортачить, ссылки на источники или готовые решения (например, в виде npm-пакетов). Также есть скилл, чтобы встроить все эти бест практисы в агента. MUST READ, если хотите делать крутые cli. Сборник очень хороший.
1. Command Line Experience — UX в терминале:
- Поддерживайте POSIX-аргументы (-abc = -a -b -c, короткие и длинные флаги)
- Проектируйте CLI так, чтобы им было легко и удобно пользоваться
- Запоминайте данные и настройки между запусками
- Поддерживайте цвета и их отключение
- Поддерживайте rich interactions — select, autocomplete, spinner/progress bar
- Делайте кликабельные hyperlinks в терминале (URL и file:line:col)
- Zero configuration — запуск без конфига и умный детект
- Обрабатывайте SIGINT
2. Distribution — как упаковать:
- Минимум зависимостей
- Фиксируйте версии в npm-shrinkwrap.json
- Cleanup конфигов при uninstall
3. Interoperability — CLI как часть unix toolchain:
- Умейте обрабатывать STDIN в пайпах (curl … | your_cli)
- Умейте выводить structured output (--json) для парсинга и пайпов
- Несколько советов для поддержки кросс-платформенности
- Уважайте приоритет конфигурации: CLI args → env → project → user → system
4. Accessibility
- Docker-образ для тех, у кого нет Node.js
- Graceful degradation / --json для CI и слабых терминалов
- Поддержка актуальных Node.js версий, понятная ошибка на старых
- #!/usr/bin/env node в shebang
5. Testing — не доверяйте locale в assert'ах на текст help/output
6. Errors — ошибки, которые помогают:
- Используйте коды ошибок (например, E4002)
- Сообщения об ошибках должны вести к действию — не «что-то сломалось», а «сделай X»
- Предоставьте дебаг режим
- Используйте правильные exit codes
- Упростите репортинг багов
7. Development — package.json hygiene:
- Советы по использованию поля bin
- Используйте относительные пути
- Не тащите в files лишнее
8. Analytics — должна быть опциональной
9. Versioning
- Всегда предоставляйте флаг --version
- Используйте semver
- Показывайте версию в help/errors и package.json
- Старайтесь быть обратно совместимыми
- Публикуйте релизы в npm
- Пишите понятные release notes
10. Security — минимизируйте возможность argument injection
Также в приложении есть сравнительная таблица CLI-фреймворков и ссылки на обучающие материалы.
https://github.com/lirantal/nodejs-cli-apps-best-practices
#development #nodejs #cli #best-practices | 1 125 |
| 16 | Iterating faster with TypeScript 7
Статья от VS Code о том, как они мигрируют на новый TS 7. Т. к. VS Code и TypeScript принадлежат одной материнской компании (Microsoft), им очень удобно коллаборировать друг с другом. Более того, VS Code изначально был на TypeScript и шёл с ним рука об руку весь свой путь. В статье рассказывается, как за полгода они переехали на TS 7.
Зачем вообще это понадобилось VS Code:
- Хотели как можно скорее переехать на новый TS 7, который написан на Go и работает быстрее
- Переезжать по шагам легче, чем делать большой прыжок с большим переездом — особенно в большом проекте
TS 7 анонсировали весной 2025. Летом уже был работающий typecheck, который команда VS Code активно тестировала. Команда VS Code репортила проблемы, команда TS тут же их чинила.
Также команда VS Code сделала расширение для работы с TS 7, которое позволяет легко переключать TS между версиями и легко репортить проблемы.
Далее проект VS Code переехал на TS 6. TypeScript 6 — версия, которая всё ещё написана на TypeScript, но поведение которой близко к будущему TS 7.
Далее подключили TS 6 и TS 7 параллельно. Сборку всё ещё делали как раньше, но начали проводить typecheck расширений дополнительно через TS 7 — и оба билда и проверки должны всегда проходить в CI. Так находили расхождения в поведении. Самая частая ошибка, из-за которой ломался CI — различие в форматировании. Я правда не понял, в чём именно, если TS 7 делал лишь typecheck.
К началу 2026 TS 7 уже стал более-менее стабильным. Расширения на него мигрировали по одному. Во время переноса упростили тулы для сборки:
Было:
- tsc — тайпчек и dev-сборка
- webpack — prod-сборка
- esbuild — быстрый emit
Стало:
- tsgo — тайпчек и dev-сборка
- esbuild — prod-сборка
На текущий момент весь проект переключился на TS 7.
Цифры:
Typecheck основного проекта:
# TS 6
tsc --noEmit -p src/tsconfig.json → 36 сек
# TS 7
tsgo --noEmit -p src/tsconfig.json → 5 сек
npm run watch (main + ~50 extensions):
- TS 6: ~80 сек
- TS 7: ~20 сек
- re-check после initial watch: ~1 сек
Language tooling в редакторе:
- было ~60 сек
- стало ~10 сек
https://code.visualstudio.com/blogs/2026/06/26/iterating-faster-with-ts-7
#development #typescript #tsgo #vscode #performance | 963 |
| 17 | Deno 2.9
Вышел Deno 2.9. Пропустил бы релиз, т. к. в целом всё как обычно — улучшают перформанс, улучшают DX, делают лучше интероп с другими пакетными менеджерами. Но в этом релизе добавили сборку desktop-приложений — можно получить GUI без Electron и других обвязок, Deno уже имеет всю инфраструктуру для этого.
Как это работает: вы, как обычно, пишете веб-приложение:
Deno.serve(() =>
new Response(
"<!DOCTYPE html><h1>Hello from Deno desktop 👋</h1>",
{ headers: { "content-type": "text/html" } },
)
);
Собираете его:
deno desktop main.ts
Получаете бинарь. Кликаете на него и видите Hello World в GUI.
Что умеет из коробки:
- Сборка для Windows, macOS, Linux
- Системное webview по умолчанию, но можно забандлить CEF (Chromium Embedded Framework)
- Управление иконкой в Tray и Dock
- Управление окном
Звучит прикольно.
https://deno.com/blog/v2.9
#development #javascript #typescript #deno #releaseNotes | 943 |
| 18 | Дайджест за 2026-07-06 - 2026-07-10
eslint-plugin-unicorn
Как-то я упустил момент, когда eslint-plugin-unicorn начал активно развиваться. А тем временем там уже больше 300 правил! Правила всякие разные — от специализированных до тех, которые можно использовать в любом проекте.
Skills for coding agents
Набор скиллов для coding-агентов от BuilderIO. Наборов скиллов много, но здесь мне понравились /visual-plan и /visual-recap, с помощью которых агент может создать план и отчёт, которые удобно читать и в которых используется канвас с диаграммами, мокапами и всем таким. Выглядит круто.
The Goldilocks customizable select height
Относительно недавно браузеры разрешили полностью кастомизировать <select>. Но, как обычно, чтобы получить идеальное решение, нужно добавить щепотку своего CSS. Jake Archibald в статье показывает, как добавить эту щепотку CSS и получить хороший select. В статье есть интерактивное демо каждого улучшения и видео для тех, у кого браузер не поддерживает все требуемые фичи.
——————————————
Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.
——————————————
Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы | 877 |
| 19 | The Goldilocks customizable select height
Относительно недавно браузеры разрешили полностью кастомизировать <select>. Но, как обычно, чтобы получить идеальное решение, нужно добавить щепотку своего CSS. Jake Archibald в статье показывает, как добавить эту щепотку CSS и получить хороший select. В статье есть интерактивное демо каждого улучшения и видео для тех, у кого браузер не поддерживает все требуемые фичи.
Проблема 1: picker упирается в край viewport
По умолчанию список опций упирается в край экрана, и непонятно — это конец списка или есть что-то ещё. Решение банальное — добавить отступ от края:
.custom-select::picker(select) {
margin-block-end: 1em;
}
Но:
- в Firefox это просто не работает
- в Chrome/Safari margin снизу выглядит плохо, когда picker переворачивается и список выпадает вверх
Для Firefox: считаем вручную через calc(100% - var(--viewport-margin)).
Chrome & Safari: используем position-try-fallbacks: flip-block, flip-inline, … — при перевороте picker'а margin тоже «переворачивается». margin-block-end сверху становится margin-block-start.
Проблема 2: picker становится слишком маленьким
У Chrome дефолт min-block-size: 1lh. Если упереть select в край экрана, список сжимается и становится неюзабельным. Решение банальное — поднимаем минимальный размер:
.custom-select::picker(select) {
min-block-size: 12em;
}
Но тогда короткий список из пары опций начинает выглядеть странно — появляется пустое пространство.
Тут Jake использует расчёт размера на основе контента:
.custom-select::picker(select) {
min-block-size: calc-size(fit-content, min(size, 12em));
}
В Firefox и Safari нет calc-size(), там используется :has() для определения количества элементов.
Проблема 3: picker становится слишком большим
Picker всегда растягивается на всю возможную высоту.
Решение: второй max через calc-size(stretch, …):
.custom-select::picker(select) {
--max-size: 30em;
max-block-size: calc-size(stretch, min(size, var(--max-size)));
}
Итоговый CSS
Итого 5 простых строчек (и около 30, если считать фолбек для браузеров, не поддерживающих эти 5 строчек) для улучшения кастомизированного select:
.custom-select::picker(select) {
min-block-size: calc-size(fit-content, min(size, 12em));
max-block-size: calc-size(stretch, min(size, 30em));
margin-block-end: 1em;
}
https://jakearchibald.com/2026/goldilocks-select-height/
#development #css #html #select #web #jakeArchibald | 947 |
| 20 | Skills for coding agents
Набор скиллов для coding-агентов от BuilderIO. Наборов скиллов много, но здесь мне понравились /visual-plan и /visual-recap, с помощью которых агент может создать план и отчёт, которые удобно читать и в которых используется канвас с диаграммами, мокапами и всем таким. Выглядит круто.
Также есть скиллы для организации группы агентов, но они уже менее интересны.
https://github.com/BuilderIO/skills
#development #ai #agents #cursor #skills | 1 012 |
