npmx.dev: a fast, modern browser for the npm registry.

npmx.dev - альтернатива сайту npmjs.com. Как и npmjs, позволяет искать и исследовать пакеты в npm, но также имеет несколько дополнительных фичей: поддержка темной темы, возможность провалиться в исходники пакета, показ используемой модульной системы, показ размера пакета и тд

Выглядит интересно

https://github.com/npmx-dev/npmx.dev

#development #javascript #npm

Announcing TypeScript 6.0 Beta

Анонсировали бету TypeScript 6.0. Версия, которая должна стать переходной между текущей реализацией TS на JS и будущей реализацией на Go в 7.0. Версия 6.0 будет нести в себе изменения, упрощающие миграцию на будущую 7.0 версию, но также и некоторые полезные изменения.

Первое интересное исправление. Если у вас есть Generic-функция, которая вычисляет аргумент generic'а по переданному аргументу функции внутри, то если функция является стрелочной, то все будет работать корректно, а если это метод объекта - то будет ошибка. Шок контент. Пример ниже

declare function callIt<T>(obj: {
    produce: (x: number) => T,
    consume: (y: T) => void,
}): void;

// Works, no issues.
callIt({
    produce: (x: number) => x * 2,
    consume: y => y.toFixed(),
});

callIt({
    consume(y) { return y.toFixed(); },
    // error: 'y' is of type 'unknown'.

    produce(x: number) { return x * 2; },
});

Это связано с тем, как TS обрабатывает this у функций. Хотя ни там, ни там он не используется, во втором случае у функции есть свой this и это как-то влияет на тайп-чекер. Теперь это исправили

Завезли флаг --stableTypeOrdering для упрощения миграции до 7 версии. Этот флаг, как следует из названия, стабилизирует порядок типов в скомпилированных декларациях. Оказывается, есть кейс, когда заведение переменной, которая никак не связана с функцией, меняет порядок типов в декларации функции. Пример

Вот так компилируется, что функция возвращает 100 или 500

// Input: some-file.ts
export function foo(condition: boolean) {
    return condition ? 100 : 500;
}

// Output: some-file.d.ts - 100 | 500
export declare function foo(condition: boolean): 100 | 500;

Но если добавить перед этим переменную, то возвращаемое функцией значение начнет компилироваться как 500 или 100

// Input: some-file.ts
const x = 500;
export function foo(condition: boolean) {
    return condition ? 100 : 500;
}

// Output: some-file.d.ts - 500 | 100
export declare function foo(condition: boolean): 500 | 100;

Внимание, флаг может замедлить тайп чекинг на 25%.

Также в TypeScript 6 вошли:
- target es2025
- Поддержка Temporal
- Поддержка новых методов в Map: getOrInsert, getOrInsertComputed
- Поддержка RegExp.escape
- lib dom.iterable внесли просто в dom. Теперь достаточно подключить только dom чтобы итерироваться по document.querySelectorAll

Ломающие изменения
На основе анализа конфигов пользователей, часть опций стали дефолтными, часть требует явного указания.
- Необходимо указывать types. По дефолту теперь будет []. Для включения старого поведения можно установить ["*"]
- rootDir по дефолту теперь ..
- strict: true по дефолту
- module: "esnext" по дефолту
- target: "es2025" по дефолту. В целом политика такая, что дефолтным будет считаться текущий стабильный ES.
- noUncheckedSideEffectImports: true по дефолту
- libReplacement: false по дефолту
- target: es5 задепрекейтили. Теперь минимальный таргет - es2015 (более известный как es6)
- --moduleResolution node задепрекейтили. Те кто использовали эту опцию, должны переехать или на nodenext или на bundler
- Удалена поддержка --module amd, umd, systemjs
- baseUrl больше не поддерживается, используйте paths
- --outFile задепрекейтили, используйте бандлеры вместо TS для вывода результата в 1 файл
- Задепрекейтили старый синтаксис для модулей. Это, конечно, может выстрелить т.к. могут быть third-party type declarations, где такой синтаксис используется

// ❌
module Foo {
    export const bar = 10;
}

// ✅ 
namespace Foo {
    export const bar = 10;
}

declare module "some-module" {
    export function doSomething(): void;
}

- Также задепрекейтили ассерты импортов в пользу with

// ❌ 
import blob from "./blahb.json" asserts { type: "json" }

// ✅ 
import blob from "./blahb.json" with { type: "json" }

В общем, готовимся к переезду на 7.0. Как минимум морально. Как максимум - заменяем все устаревшее на современное.


https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-beta/

#development #typescript #javascript #breaking

wc3ui - библиотека компонентов в стиле wc3

Битва UI-китов закончена. Наконец-то нашелся ультимативный ui-kit, предоставляющий компоненты как в warcraft III. Гонка ui-kit'ов потеряла смысл с таким игроком.

Выглядит круто. Даже захотелось внедрить в какой-то пет-проект и снова перепройти кампании wc3. Надеюсь есть в канале люди, у которых сводит олд-скулы от такого.

https://wc3ui.banteg.xyz

#development #javascript #uikit #wc3

@github-ui/storybook-addon-performance-panel

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

https://github.com/github/storybook-addon-performance-panel

#development #javascript #storybook #performance

fetch-network-simulator

fetch-network-simulator - библиотека, которая позволяет симулировать проблемы с сетью при работе с fetch.

Что можно делать:
- Повышать задержку
- Терять пакеты
- Автоматические ретраи
- Ответы приходят в порядке, отличном от порядка запросов (полезно для вскрытия кейсов, когда приложение ожидает, что при отправке двух запросов А и Б, ответы точно придут в том же порядке)
- Ограничение на параллельность

Все это настраивается прямо в JS коде. Выглядит интересно: можно посмотреть как будет работать сайт при наличии различных сетевых проблем и найти какие-то проблемы в самом сайте. DevTools делают что-то похожее, но не все (потерю пакетов там, вроде бы, не эмулировать).

Настройка библиотеки выглядит так

import { enableNetworkSimulator } from "fetch-network-simulator";

if (process.env.NODE_ENV === "development") {
  enableNetworkSimulator({
    debug: true, // optional: structured request lifecycle logs

    latency: { enabled: true, delayMs: 1500 },
    packetLoss: { enabled: true, lossRate: 0.3 },
    retry: { enabled: true, maxAttempts: 3, retryDelayMs: 200 },
    staleResponse: { enabled: true, staleProbability: 0.5 },
    burstControl: { enabled: true, maxConcurrent: 1 },
    networkSpeed: { enabled: true, kbps: 500 }
  });
}

https://github.com/thisiskps/fetch-network-simulator

#development #javascript #fetch #performance

Electrobun v1

Год назад я в канале писал, что анонсировали разработку Electrobun - это Electron, но поверх bun. И вот теперь вышел Electrobun v1

Какие изменения:
1. Автор уже завез один свой проект на Electrobun. Получается уже можно сделать что-то рабочее
2. Поддержка macos, windows, ubuntu
3. Своя реализация OOPIF (Out Of Process IFrame) для вставки webview. Про создание своего OOPIF есть отдельная статья

https://blackboard.sh/blog/electrobun-v1/

#development #javascript #bun #electron #electrobun

Fastest Frontend Tooling for Humans & AI

Статья про замену инструментов вокруг разработки на более быстрые. Во-первых, это полезно разработчикам. А во-вторых, это ускоряет работу ИИ-агентов.

Что предлагает автор:
Первое - уже переехать на typescript, написанный на go (tsgo). Сам автор уже полгода сидит на tsgo и очень доволен т.к. tsgo в 10 раз быстрее. Также говорит, что tsgo находит ошибки, которые не находит обычный tsc

Миграция:
- npm install @typescript/native-preview
- Удалить легаси-флаги конфига TS
- Заменить все вызовы tsc на tsgo
- Добавить "typescript.experimental.useTsgo": true в конфиг vscode

Второе - переехать на oxfmt вместо prettier. Oxfmt это более быстрая реализация prettier с кучей встроенных плагинов. Также oxfmt фолбечится до prettier для обработки файлов не на JS/TS.

Миграция через ИИ-агента:
> Migrate this project from Prettier to Oxfmt. Read https://oxc.rs/docs/guide/usage/formatter/migrate-from-prettier.md. Update all scripts, tools, and hooks to use Oxfmt. Remove all Prettier configuration files and reformat the code using Oxfmt.

Также полезным будет установить расширение для vscode
code --install-extension oxc.oxc-vscode.

Третье - переехать на oxlint вместо eslint. Oxlint умеет запускать eslint плагины внутри себя, что позволяет переехать на более быстрый линтер, не потеряв при этом богатую экосистему плагинов

Миграция также через ИИ-агента
> Migrate this project from ESLint to Oxlint. Read https://oxc.rs/docs/guide/usage/linter/migrate-from-eslint.md. Update all scripts, tools, and hooks to use Oxlint. Remove all ESLint configuration files. Lint the code and fix any lint errors.

Также автор собрал свой конфиг для линтера, который вы можете поставить. Сам конфиг не интересен, но интересны принципы, которые лежат в основе конфига:
1. Только ошибки, никаких предупреждений.
2. Строгий, консистентный код-стайл.
3. Предотвращение багов (запрет любых конструкций, которые могут к ним привести)
4. Только быстрые правила. Медленные отключаются
5. Субъективные правила отключены (например, влияющие на стиль написания кода)

Эти правила уменьшают двусмысленность, что полезно при ИИ-кодинге.

Также из быстрого инструментария:
1. npm-run-all2 - команда для запуска других команд в параллель
2. ts-node + swc

Звучит интересно. Кто-то уже пробовал tsgo и oxlint?

https://cpojer.net/posts/fastest-frontend-tooling

#development #javascript #eslint #typescript #oxlint #prettier

Can't Maintain. Can you spot the better API?

"Не поддерживаемый" (Can't maintain) - сайт с короткими квизами, где надо выбрать более поддерживаемый вариант реализации JS или React-кода. При ответе краткий экскурс, почему один из вариантов более поддерживаемый, чем другой. Очень залипательный сайт.

https://cant-maintain.saschb2b.com

#development #javascript #quiz #react

Why is WebAssembly a second-class language on the web?

WebAssembly развивается с 2017 года, но все еще не стал полноценной частью веб-экосистемы. В статье Ryan Hunt объясняет, какие проблемы есть у современного WASM и что надо изменить, чтобы wasm стал популярен у разработчиков

Есть 2 основные проблемы, делающие WASM "неудобным":
1. Код из WASM не может напрямую работать с Web API. Для этого нужна JS прослойка, которая будет мостиком между WASM и Web API
2. WASM код нельзя загрузить никак, кроме как из JS-кода (что является следствием первой проблемы)

Вторую проблему уже решают в пропозале esm-integration. Он позволяет загружать wasm-модули как обычные js-модули

import { run } from "/module.wasm";

run();

<script type="module" src="/module.wasm"></script>

Но необходимость прослойки для работы с Web API все еще делает неудобной работу с Web API. Можно писать эту прослойку самому, но это а) не самая тривиальная работа; б) требует одновременно компетенций как в wasm, так и в web. Можно использовать embind или wasm-bindgen, но там тоже есть свои нюансы

Компиляторы, собирающие нативный код в WASM, не занимаются сборкой JS-кода для интеграции wasm в web-api - они лишь собирают wasm, а дальше разработчик сам должен написать мостик между WASM и Web API, если это требуется для приложения.

Также есть проблема, что даже если написать такой мостик, то от этого пострадает перформанс. В классическом бенчмарке TodoMVC wasm+JS оказался почти в 2 раза медленнее, чем wasm-код с доступом к web api.

Как решение этой проблемы предлагается WebAssembly Component - пропозал, разрабатываемый с 2021 года

WebAssembly Components:
- Могут быть созданы из разных языков программирования
- Могут быть запущены в разных рантаймах
- Могут использовать друг друга
- Могут напрямую вызывать Web API

Это позволит снизить порог входа для интеграции WASM в приложения.

https://hacks.mozilla.org/2026/02/making-webassembly-a-first-class-language-on-the-web/

#development #javascript #web #wasm

How we Rewrote 130K Lines from React to Svelte in Two Weeks

Команда strawberry за 2 недели переписала 130к строчек кода с React на Svelte с применением ИИ-агентов. Интересный кейс, про который можно и почитать. Хотя, конечно, тот факт, что ИИ-агенты хорошо справляются с переписыванием - давно не новость

Почему вообще понадобилось переезжать с React:
1. Strawberry использует несколько отдельный рендереров для разных компонентов своего браузера. Каждый компонент - отдельное React-приложение. Обновление этих приложений из главного процесса приводит к плохому UX.
2. Strawberry - это ИИ-стартап, знаете ли. ИИ-агенты, которые работают как ядро приложения, постоянно вызывают ререндер React-приложений.

В общем, React быстрый, но недостаточно быстрый для чуваков из Strawberry (хотя конечно больше похоже на то, что они просто решили не париться с оптимизацией ререндеров)

Отдельно забавляет подход, с которым начался процесс переписывания. Какое-то обсуждение через ADR, RFC или хотя бы тред - это все лишнее. Чел просто на один из дейликов пришел и сказал "смотрите, переписал уже 60% кодовой базы на Svelte". Живем в эру, где быстрее показать Proof of Concept, чем начать обсуждение какой-то инициативы.

Как состоялось переписывание:
1. Были оформлены правила миграции, чтобы гарантировать, что ИИ-агенты пишут код "правильно". Короткие примеры правил: "Avoid $effect", "Prefer stores over component state", "Keep reactivity explicit."
2. За 1 раз переписывается одна фича
3. ИИ-агент читает правила, портирует код, тестирует код.
4. Старый код не удалялся, пока не была завершена миграция (чтобы при любых проблемах можно было поднять эталонные исходники и сравнить решение)
5. Часть библиотек отсутствует на svelte, поэтому пришлось их написать самим (через агентов конечно)

Какие результаты:
1. х2 ускорение
2. FCP уменьшился с 300мс до 124мс
3. Количество ререндеров в приложении уменьшилось в 10 раз
4. Удалили 56 неиспользуемых зависимостей


В общем, история, откровенно говоря, странная. Создается ощущение, что как использовался "тяп-ляп" подход при разработке на React, так и используется, просто повезло, что ИИ-агенты справились с рефакторингом. С другой стороны, хороший пример как можно сделать миграцию кодовой базы с применением ИИ-агентов



https://strawberrybrowser.com/blog/react-to-svelte

#development #javascript #react #svelte #migration #refactoring #ai

Reveal.js 6.0

Вышел новый релиз Reveal.js. Reveal.js — это инструментарий для создания веб-презентаций из кода. Основное важное изменение для релиза — нативная поддержка React. Теперь можно собирать интерактивные презентации на привычном стеке.

Я даже уже попробовал использовать. Может показаться смешным, но у нас в направлении есть своя презентация для фит-интервью. К нам приходят кандидаты, мы спрашиваем их про их опыт и всякое разное, а потом рассказываем про нас через презу. Но преза сделана на PowerPoint и не обновляется годами, потому что никто особо не хочет лезть править презентацию.

В общем, решил совместить приятное с полезным и отправил агента сначала мигрировать презентацию с pptx на reveal. Агент нашёл какой-то пакет для парсинга слайдов на Python и собрал базу для презентации. Результат простой миграции выглядит, конечно, достаточно убого.

Дальше пошли сплошные плюсы. Заставил агента через Chrome MCP провести ревью слайдов и исправить явные косяки. С этой задачей он справился: где-то выровнял, где-то увеличил, а где-то распределил контент по слайду.

Дальше пошёл самый кайф. Т. к. на слайдах были картинки, а тут у нас целый React, то почему бы не добавить интерактива? Описал, какой интерактив я ожидаю на слайдах, и вообще попросил все картинки из интернета заменить на что-то более живое.

Результат следующий: половина коллег сказали «вау, круто», другая половина оценила как «юзлес кринж». Считаю, главное, что мне нравится :)

Но как итог:
- Reveal.js норм ложится для создания интерактивных презентаций на React. Слайды с демками, кликабельные блоки, кастомные анимации любой сложности — всё можно сделать в Reveal.js.
- ИИ-агент с доступом к Chrome MCP вполне бодро может собрать презентацию сам по вашему контенту и с вашим видением.


https://github.com/hakimel/reveal.js/releases/tag/6.0.0

#development #javascript #react #revealjs #presentation #release #ai #agents

Next.js 16.2

Вышел релиз Next.js 16.2. Кратные ускорения (400% ускорение старта при разработке и 50% ускорение рендеринга), правки в Turbopack и адаптация фреймворка для AI. Ещё новая дефолтная страница для 500 ошибки.

Что прикольного завезли:

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

Удобное отображение диффа между серверной и браузерной разметкой, когда разъехалась гидрация. За это однозначный лайк. Также более удобное отображение ошибок в dev overlay.

Я бы не писал в канал, если бы не отдельные телодвижения в релизе для ИИ-агентов.

Что конкретно сделали:

Теперь при создании нового приложения через create-next-app создаётся Agents.md. В файле написано, что это Next.js репозиторий и необходимо смотреть доку в node_modules/next/dist/docs. Это сделано потому что, по исследованию, наличие доки по фреймворку рядом с кодом позволяет агентам достигать лучших результатов в бенчмарках.

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

При старте сервера Next.js пишет в lock-файл PID процесса. Если попытаться стартануть новый сервер, то Next.js не позволяет это сделать и говорит, что сервер уже запущен. Это также полезно для агентов, которые любят запустить приложение с десяток раз.

Сделали DevTools для агентов. Можно получать инфу из DevTools через CLI. В целом, как будто ИИ-агенты и так могут это делать через MCP или прямое или почти прямое использование CDP через CLI, но встроенная в фреймворк возможность так делать, конечно, удобнее для массового использования.

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


https://nextjs.org/blog/next-16-2

#development #javascript #react #nextjs #turbopack #release #ai #agents #devtools

Start naming your useEffect functions, you will thank me later

Огромная статья, в которой очень простой месседж — именуй чёртовы колбэки в useEffect.

В чём суть. Есть две большие причины именовать колбэки в useEffect.

Первая: самодокументирующийся код. useEffect(() => {}) говорит о том, как мы запускаем код (при изменениях чего-то), но не говорит о том, что там запускается и почему.

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

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

Автор даёт в статье пример компонента, который общается по WebSocket и синхронизирует состояние сущности.

Пример useEffect с именованным колбэком:

useEffect(function resetStockOnLocationChange() {
    if (prevLocationId.current !== locationId) {
      setStock([]);
      prevLocationId.current = locationId;
    }
  }, [locationId]);

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

Вторая причина для именования колбэков чисто прагматичная. Лучше в инструментарии и в стек-трейсах видеть at resetStockOnLocationChange, чем at anonymous.

В общем, именуйте колбэки в useEffect. Это бесплатно и сразу делает вашу жизнь лучше. Можно ещё написать или найти ESLint-правило, которое не даст коммитить анонимные useEffect.


https://neciudan.dev/name-your-effects

#development #javascript #react #hooks #useeffect #best-practices #article

You can't cancel a JavaScript promise (except sometimes you can)

Статья от Inngest про то, как можно отменить исполнение Promise. По прочтению оказалось, что не совсем отмена, но тем не менее интересно.

С момента стандартизации Promise и async/await сообщество требует возможности отменить Promise, но решения пока нет.

Если вам нужны отменяемые асинхронные операции, у вас, по сути, есть 2 пути:

Первый способ: использовать генераторы. Они прекрасно для этого подходят (т.к. генераторы отдают поток управления во вне, в вызывающий их код), но сообщество не очень любит их использовать. async/await гораздо удобнее


Второй способ: кидать ошибку типа InterruptedError из приостанавливаемого кода, но тогда надо уметь ее везде обрабатывать.

Что придумали в Inngest. У них какой-то немного странный фреймворк - они описывают workflow как шаги (steps)

async function myWorkflow(step) {
  console.log("  Workflow: top");

  const data = await step.run("fetch", () => {
    console.log("  Step: fetch");
    return [1, 2, 3];
  });

  const processed = await step.run("process", () => {
    console.log("  Step: process");
    return data.map((n) => n * 2);
  });

  console.log("  Workflow: complete", processed);
}

Который затем исполняется

async function main() {
  // In-memory store of completed step results
  const stepState = new Map();

  // Keep entering the workflow function until it's done
  let done = false;
  let i = 0;
  while (!done) {
    console.log(`Run ${i}:`);
    done = await execute(myWorkflow, stepState);
    console.log("--------------------------------");
    i++;
  }
}

При этом функция execute после выполнения каждого step кеширует результат работы step, затем приостанавливает workflow и вызывает новый запуск workflow. Это очень упрощенно, в Inngest SDK все сложнее, но смысл примерно такой.

Поэтому есть потребность обрывать исполнение workflow. Для этого используется интересный хак: после выполнения первого незакешированного step функция execute подменяет результат выполнения так, чтобы возвращался Promise, который никогда не завершится

// Hang forever
return new Promise(() => {});

Затем ссылка на конкретный запуск workflow теряется и, оказывается, в NodeJS сборщик мусора видит, что есть функция, на которую нет ссылок и которая никогда не выполнится потому что ожидает завершения промиса, который никогда не завершится. Сборщик мусора удаляет из памяти функцию и все что с ней связано.

В общем, максимально странное решение и, если честно, немного удивительно что это вообще работает. Но, как говорится, если это работает - это не глупо. Запоминаем и используем с осторожностью в nodejs коде.

https://www.inngest.com/blog/hanging-promises-for-control-flow

#development #javascript #Promise

boneyard - Pixel-perfect skeleton loading screens, extracted from your real UI. No manual measurement, no hand-tuned placeholders.

В названии ссылки в общем-то все написано. Библиотека, автоматически создающая скелетоны для ваших экранов. Есть адаптеры на React, Preact, Vue, Svelte 5, Angular, React Native.

Использование такое

import { Skeleton } from 'boneyard-js/react'

function BlogPage() {
  const { data, isLoading } = useFetch('/api/post')
  return (
    <Skeleton name="blog-card" loading={isLoading}>
      {data && <BlogCard data={data} />}
    </Skeleton>
  )
}

Как это работает:
- Вы запускаете сайт
- Запускаете специальную команду npx boneyard-js build
- Она находит все Skeleton и делает снапшот разметки, который сохраняется в bones.json
- Информация из bones.json используется для построения скелетонов

Выглядит прикольно

https://github.com/0xGF/boneyard

#development #javascript #library #skeletons

Post Mortem: axios npm supply chain compromise

Axios опубликовали пост-мортем про взлом Axios, в котором опубликованы причины, таймлайн и предпринимаемые действия для предотвращения такого в будущем

Что случилось:
- В середине марта началась атака через социальную инженерию на мейнтейнера
- 30 марта была опубликована взломанная версия plain-crypto-js
- 31 марта (через 19 часов) был опубликован axios с plain-crypto-js
- Через 40 минут сообщество начало репортить проблему, но злоумышленники удаляли эти репорты (у них был доступ к аккаунту мейнтейнера)
- Через час после публикации опубликован пул реквест с депрекейтом "плохих" версий axios
- Еще через полтора часа опубликованные версии были удалены с npm

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

https://github.com/axios/axios/issues/10636

#development #javascript #axios #postMortems #security #npm

What's actually new in JavaScript (and what's coming next)

Хороший обзор уже вышедших новшеств ES2025 и грядущих новшеств в ES2026. Обзор очень большой - там приводится и краткая история изменений, и примеры в стиле "до и после" и в каких версиях браузеров уже доступны изменения. Поэтому делаю вам обзор на обзор, чтобы вы могли быстро ознакомиться с изменениями.

Iterator helpers (ES2025)
Уже было в канале, но повторение не будет лишним. Добавили хелперы для итераторов, аналогичные методам массива, что позволяет создавать эффективные пайплайны для обработки данных прямо на интераторах

function* naturalNumbers() {
  let n = 1;
  while (true) yield n++;
}

const firstTenEvenSquares = naturalNumbers()
  .filter(n => n % 2 === 0)
  .map(n => n * n)
  .take(10)
  .toArray();

Set methods (ES2025)
Операции над множествами (пересечение, объединение и тд) теперь прямо в Set. Методы intersection, union, difference, symmetricDifference, isSubsetOf, isSupersetOf, isDisjointFrom

Эти методы создают новый Set, а не меняют существующий.

JSON modules (ES2025)
Нативный импорт JSON (наконец-то!)

import config from './config.json' with { type: 'json' };

Никаких fetch + JSON.parse и настройки сборщиков.

Promise.try (ES2025)
Фича была в Bluebird 10+ лет и теперь попала в стандарт. Позволяет обернуть функцию с неизвестным поведением (sync/async/throw error) в один Promise с единым .catch()

До

try {
  const result = fn();
  Promise.resolve(result)
    .then(r => processResult(r))
    .catch(err => handleAnyFailure(err));
} catch (err) {
  handleErr(err);
}

После

Promise.try(() => thirdParty.doThing())
  .then(result => processResult(result))
  .catch(err => handleAnyFailure(err));

В отличие от старого workaround'а Promise.resolve().then(fn) - не добавляет лишний микротаск.

RegExp.escape (ES2025)
Безопасное экранирование пользовательского ввода для регулярок. Изменение предлагалось в стандарт еще 15 лет назад.

const regex = new RegExp(RegExp.escape(userInput), 'gi');

Intl.DurationFormat и Intl.Locale (ES2025)
Форматирование длительности ("2 hours, 15 minutes") и метаданные локали (weekInfo, hourCycles, getCalendars)

Что ожидаем в ES2026

Math.sumPrecise (ES2026)
Довольно старая и известная проблема - 0.1 + 0.2 !== 0.3. Это особенность работы чисел с плавающей точкой, которая неприемлема в различных доменах (например, в финансовом). Уже есть различные решения, но в ES2026 ожидаем еще 1го - метод для точной суммы чисел

Как работает сейчас

const cents = Array(10000).fill(0.1);
cents.reduce((a, b) => a + b);  // 1000.0000000001588


const values = [1e20, 1, -1e20];
values.reduce((a, b) => a + b); // 0, хотя ожидали 1

Как будет работать

Math.sumPrecise(cents);   // 1000
Math.sumPrecise(values);  // 1

Iterator.concat (ES2026)
Склеивает итераторы без генератора-обёртки:

Iterator.concat(first(), second());

Map.getOrInsert / getOrInsertComputed (ES2026)
Паттерн "Достань, значение, если есть. Если нету - создай и достань" будет встроено в Map

// Было:
if (!counts.has(word)) counts.set(word, 0);
counts.set(word, counts.get(word) + 1);

// Стало:
counts.set(word, counts.getOrInsert(word, 0) + 1);

Array.fromAsync (ES2026)
Метод для сборки асинхронного итератора в массив

До

const allItems = [];
for await (const item of fetchPages()) {
  allItems.push(item);
}

После

const allItems = await Array.fromAsync(fetchPages());

JSON.parse с source text (ES2026)
При парсинге JSON можно будет получить 3-й аргумент с исходным текстом поля. Это, например, позволяет парсить большие числа без потери точности

Также в статье большой блок про то, какие еще изменения не попали в стандарт и почему они не попали. Но в обзор на обзор это уже не влезет

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


https://neciudan.dev/whats-new-in-javascript

#development #javascript #es2025 #es2026 #tc39 #language-features

TypeScript Tips Everyone Should Know

Никогда не было и вот опять - читшит с бест практисами по Typescript. 15 простых бест-практисов, которые можно брать в любой проект (или отдать агенту в виде скилла). Т.к. читшит ультра короткий, то приведу примеры из него прямо в посте

Prefer unknown Over any - тут всем всё понятно, unknown безопаснее any

Let Type Inference Do the Work - если TS может вывести тип сам, то и не надо его описывать

const name = "Ada";
// вместо
const name: string = "Ada";

Prefer satisfies Over as - satisfies позволяет проверить на соответствие типу без приведения типов, в отличие от as

const routes = {
  home: "/",
  about: "/about",
} satisfies Record<string, string>;

Derive Types From Values Instead of Duplicating Them - получайте типы из значений, а не делайте копию в типах.

const roles = ["admin", "user", "guest"] as const;

type Role = (typeof roles)[number];

Model Impossible States With Discriminated Unions - делайте некорректные состояния невозможными с помощью Discriminated Unions

type State =
  | { status: "loading" }
  | { status: "success"; data: User }
  | { status: "error"; error: Error };

Use Exhaustive Checks With never - при проверках switch/case (да и в других вариантах), в default следует возвращать never. Если вдруг TypeScript поймет, что не все ветвления проверены и можно войти в ветку с never, то TS кинет ошибку

function render(state: State) {
  switch (state.status) {
    case "loading": return <Spinner />;
    case "success": return <UserCard data={state.data} />;
    case "error": return <ErrorMessage error={state.error} />;
    default: {
      const exhaustive: never = state;
      return exhaustive;
    }
  }
}

Use as const for Configuration and Constants - фиксируйте типы конфигов и констант через as const, они будут точнее выведены

const theme = { mode: "dark" } as const;

Use Type Predicates for Reusable Narrowing

function isUser(value: unknown): value is User {
  return typeof value === "object" && value !== null && "id" in value;
}

Build New Types From Existing Types - используйте Pick, Omit, Partial, Required и другие type utils для построения производных типов

type UserPreview = Pick<User, "id" | "name">;

Validate External Data at Runtime - TypeScript не проверяет данные из внешнего мира. Валидируйте их на границе с API

const UserSchema = z.object({
  id: z.string(),
  name: z.string(),
});

Avoid enum in Most Cases - union проще рефакторить, сериализовать и приносит меньше сюрпризов в рантайме, чем Enum.

const roles = ["admin", "user"] as const;
// вместо enum Role { Admin, User }

Prefer Generics That Infer Automatically - если generic может сам вывести тип — так и делайте. Хороший API не заставляет писать тип вручную

getData(userSchema);
// вместо
getData<User>(userSchema)

Enable Strict Compiler Options - удивительно, что в конце списка :). Включите строгий режим проверок.


Learn Template Literal Types - используйте строковые шаблоны в типах.

type Route = `/api/${string}`;

"Type-Safe" Does Not Mean "Runtime Safe" - даже если вы используете строгий TS, у вас нет any, ts-expect-error и всё чётко, это не гарантирует, что в рантайме у вас не будет ошибок.

https://github.com/AllThingsSmitty/typescript-tips-everyone-should-know

#development #typescript #javascript #best-practices #cheatsheet

eslint-plugin-unicorn

Как-то я упустил момент, когда eslint-plugin-unicorn начал активно развиваться. А тем временем там уже больше 300 правил! Правила всякие разные — от специализированных до тех, которые можно использовать в любом проекте.


https://github.com/sindresorhus/eslint-plugin-unicorn

#development #eslint #javascript #typescript #lint

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