v0.7.0

Rate limiting

• Маршруты итд.com разбиты на бакеты — группы маршрутов со своим счётчиком запросов в минуту. Раньше клиент считал лимит один на весь сайт, и исчерпанная квота на публикацию постов тормозила заодно чтение ленты. Теперь у каждого бакета своя очередь и своя пауза, а общее число одновременных запросов по-прежнему задаёт concurrency.

• Новая опция pacing решает, что делать с остатком квоты. react (по умолчанию) ждёт, только когда остаток кончился, smooth заранее держит ровный темп, off отключает подстройку. Опция заменила respectHeaders.

• Лимиты отдельных бакетов можно поправить через bucketOverrides, а itd.request() — направить в нужный бакет опцией rateLimitBucket.

• itd.rateLimitState() показывает остаток квоты по каждому бакету — сколько запросов ещё можно отправить и сколько ждёт в очереди.

• Несколько аккаунтов по умолчанию встают в одну очередь: лимиты считаются по IP, а не по аккаунту. Прежнее поведение возвращает rateLimitScope: 'account'.

Несовместимые изменения

• rateLimit.respectHeaders удалён: прежнее true — это pacing: 'react', прежнее false — pacing: 'off'.
• Умолчание rateLimitScope изменено с 'account' на 'shared'.

Таблица бакетов и настройки — в новом разделе справочника «Ограничения частоты».

Full Changelog: v0.6.0...v0.7.0

v0.6.0

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

Жизненный цикл клиента

• dispose() отменяет незавершённые запросы. Runtime владеет одним сигналом времени жизни, и транспорт объединяет его с сигналом запроса: после await itd.dispose() внутри клиента не остаётся ни активных сетевых операций, ни таймеров переподключения. Отменённый запрос получает ItdAbortError с
  причиной отмены.
• Ожидание чужого кода ограничено новой опцией shutdownTimeout (по умолчанию 10 000 мс). Срок общий на обработчики realtime-потока и на операции, вошедшие в обёртки плагинов. По его истечении ресурсы всё равно освобождаются, включая teardown плагина, а метод отклоняется ItdStateError с именем
  плагина или транспорта потока. shutdownTimeout: 0 возвращает ожидание без срока.
• Порядок терминальной очистки закреплён: потоки, накопленная телеметрия, отмена запросов, teardown плагинов.
• Поток, исчерпавший попытки переподключения, покидает клиент так же, как после disconnect(): close() и dispose() его больше не касаются, а повторный connect() возвращает поток клиенту.

Плагины

• next() у operation transformer стал одноразовым. Повторный вызов завершает операцию ItdConfigError с именем плагина — так же, как это уже работало у attempt interceptor. Раньше плагин мог породить вторую логическую операцию, а для posts.create это вторая публикация.

Realtime

• Опрос уведомлений идёт через общий конвейер клиента. В каталог добавлены операции realtime.poll.updates и realtime.poll.unread: опрос занимает слот очереди, виден плагинам и хукам, обновляет токен при 401 вместо разрыва потока и отменяется вместе с ним. Из транспорта ушли собственное получение
  токена, заголовок Authorization, распознавание 401 и снятие обёртки { data: … }.
• TransportContext получил необязательный порт request к конвейеру клиента. SSE по-прежнему работает через fetch: у соединения другой жизненный цикл.
• Очередь обновлений ограничена. Счётчик непрочитанного коалесцируется — ожидающее значение заменяется новым, и обработчик получает последнее; уведомления не коалесцируются. При переполнении поток закрывает соединение, дожидается разбора очереди и переподключается с обычной синхронизацией.

Хранилища

• Запись в record-хранилище стала транзакционной. Изменение видно чтениям только после подтверждения источником: неудачная запись не расходится с backend и больше не отравляет get() и keys() собственной ошибкой. Черновик строится внутри очереди записей, поэтому параллельные записи разных ключей не
  теряют друг друга.
• Нечитаемый ключ больше не ломает перечисление аккаунтов. accounts() пропускает запись, ключ которой не декодируется, с предупреждением — вместо URIError на весь список и пустого результата restore().

Full Changelog: v0.5.0...v0.6.0

v0.5.0

Новая модель плагинов, каталог операций и переработанный конвейер запросов

Конвейер запросов

• Очередь применяется к каждой сетевой попытке, а не ко всему логическому запросу: ожидание повтора больше не занимает слот конкурентности, а ограничитель частоты считает реальные обращения к серверу.
• Локальный результат не проходит очередь: ответ из кэша, мок или короткое замыкание плагина возвращаются сразу и не расходуют RPS.
• Очередь выбирается по итоговому URL.origin, уже после разрешения service и разового baseUrl. Два имени одного хоста делят лимитер, разные хосты изолированы.
• Авторизация разделена на три стадии: восстановление после 401 вокруг попытки, подготовка токена до очереди и подстановка свежих заголовков непосредственно перед отправкой.
• Служебные auth.signIn и auth.refresh проходят общий конвейер вместе с плагинами и очередью; отдельный урезанный auth-конвейер удалён.
• Номер попытки считает фактические входы в транспорт: повтор после обновления токена получает следующий номер, а auth.refresh ведёт собственный счёт.
• Порядок стадий и их частота закреплены contract-тестами и описаны в новом справочнике «Request pipeline».

Каталог операций

• Каждый метод SDK получил стабильный operationId — posts.create, users.me, auth.refresh и так далее. Идентификатор не меняется при переносе HTTP-пути.
• Публичный OPERATIONS хранит HTTP-метод и семантику повтора каждой встроенной операции; доступны operationMethod(), operationRetrySafety() и isBuiltInOperationId().
• Плагины распознают операции по идентификатору, а не по регулярным выражениям над URL: перенос эндпоинта больше не ломает правила расширений молча.
• Низкоуровневый itd.request() по умолчанию выполняется как операция raw; для собственных вызовов доступно пространство custom:*.

Плагины

• Два явных уровня расширения. operations.use() вызывается один раз на логическую операцию и работает с разобранным результатом, attempts.use() оборачивает каждую сетевую попытку и видит итоговый URL, заголовки и сырой Response.
• ClientPlugin заменил ItdPlugin: install(api) регистрирует преобразователи и перехватчики, а teardown дожидается запросов, уже вошедших в обёртку плагина.
• Перехватчик попытки не может незаметно породить вторую отправку: повторный вызов next() запрещён, короткое замыкание возможно только явным возвратом Response.
• Настройки плагинов передаются через extensions.<namespace> — регистрация ключей во время выполнения больше не нужна.

Повторы

• Повтор опирается на семантику операции, а не на HTTP-метод. RetrySafety различает safe, idempotent и unsafe: читающий POST вроде posts.stats повторяется, а posts.create — нет.
• Небезопасная операция повторяется автоматически только после ответа, который гарантирует, что запрос не был обработан.
• Отдельно проверяется возможность заново собрать тело: одноразовый поток не делает операцию повторяемой.
• Обычные повторы и лестница пауз после 429 считаются раздельно, поэтому последовательность 500 → 429 начинает лестницу с первой ступени.
• Точечное переопределение доступно через RequestOptions.retrySafety, а shouldRetry получает RetryDecisionContext с семантикой операции.

Параметры запросов

• Параметры эндпоинта и настройки выполнения разделены: itd.posts.list({ limit }, { signal, retry }).
• Для итераторов добавлен PaginationOptions: maxPages управляет перебором и не попадает в запрос к эндпоинту.
• Настройки загрузки файлов и телеметрии вынесены в собственные аргументы.

Realtime

• Новый транспорт WebSocketTransport для сред с WebSocket: путь /api/ws, собственная реализация сокета, заголовки апгрейда и распознавание отказа по недействительному токену. Подключается явно через transport; выбор auto по-прежнему использует поток событий или опрос.
• RealtimeComposer собирает feature-модуль без доступа к живому потоку: use(), filter() с type guard, route() поверх RealtimeRouter и errorBoundary() для защищённой ветки обработчиков.
• Движок потока отделён от публичного объекта: переподключение, снимки цепочек и конкурентность живут в собственном слое.

Хранилища

• Общий backend KeyValueStore под памятью, файлом, localStorage и sessionStorage. TokenStorage и MultiTokenStorage остались доменными фасадами поверх него.
• Добавлены декораторы withNamespace() и withCodec(), фабрики createKeyValueStore() и createRecordKeyValueStore().
• В itd-api/web появились SessionStorageTokenStorage, LocalStorageKeyValueStore и SessionStorageKeyValueStore.
• Файловый backend использует версионированный конверт, а повреждённый JSON больше не выглядит как пустое хранилище: и файл, и Web Storage сообщают об ошибке явно, вместо молчаливого выхода пользователя из сессии.
• MultiTokenStorage выводит список аккаунтов из ключей и не хранит отдельный индекс.

Жизненный цикл клиента

• dispose() стал терминальным: после него новые запросы, use(), defineService(), realtime() и повторный connect() завершаются ItdStateError. Повторный вызов возвращает тот же результат очистки, await using вызывает именно его.
• close() остаётся перезапускаемой остановкой: закрывает потоки, отправляет накопители телеметрии и гасит очередь.
• Накопленная телеметрия отправляется и при dispose() — до teardown плагинов и не открывая доступ новым пользовательским вызовам.
• ItdAccounts получил такой же терминальный dispose(): контейнер отзывает storage-срезы и подписки.

Пакеты

• @itd-api/cache: правила задаются полем operations вместо routes, каталог доступен как CACHE_OPERATIONS. Кэш и граф инвалидации опираются на operationId, поэтому совпадение URL у itd.request() больше не включает кэш случайно.
• @itd-api/testing: добавлен createMockOperations() — подмена логической операции по operationId с последовательностями ответов, историей вызовов, passthrough и проверкой неиспользованных сценариев. createMockFetch() остаётся для проверки HTTP-деталей, повторов и ошибок транспорта.
• @itd-api/crypto: набор шифруемых полей сопоставляется с operationId, собственное распознавание маршрутов удалено.
• @itd-api/hydrate: переведён на новые контракты расширения.

Технические улучшения

• Сборка клиента вынесена во внутреннюю фабрику runtime: конфигурация, транспорт, авторизация, очереди и единственный конвейер собираются в одном месте, а ItdClient остаётся фасадом.
• Ресурсы клиента создаются лениво, при первом обращении.
• Пользовательское определение сервиса накладывается на встроенное: auth и заголовки наследуются, пока ключ не задан явно.
• Каталоги операций и мутаций заморожены целиком, включая вложенные описания.
• Добавлен справочник «Request pipeline» с инвариантами конвейера и таблицей точек расширения.

Несовместимые изменения

• ItdPlugin, PluginContext и Transformer заменены на ClientPlugin, PluginApi, OperationTransformer и AttemptInterceptor; плоские use() и useHooks() внутри плагина удалены.
• Смешанные параметры и настройки запроса разделены во всех методах ресурсов; optionKeys и REQUEST_OPTION_KEYS удалены вместе с извлечением полей в базовом ресурсе.
• retryWrites и внутренний повтор сетевых записей удалены — их заменяет RetrySafety.
• createRecordMultiStorage() заменён на createRecordKeyValueStore().
• dispose() больше не оставляет клиент пригодным для запросов.
• cache({ routes }) и CACHE_ROUTES переименованы в cache({ operations }) и CACHE_OPERATIONS без переходных псевдонимов.
• Совместимые перегрузки намеренно не добавлялись: 0.5.0 меняет публичные контракты один раз, вместо того чтобы надолго оставить два протокола.

Совместимость

• @itd-api/cache@0.1.0, @itd-api/crypto@0.1.0, @itd-api/hydrate@0.1.0 и @itd-api/testing@0.1.0 требуют itd-api@>=0.5.0 <1.0.0.
• @itd-api/proxy и @itd-api/turnstile не зависят от контракта ядра и не менялись.

Full Changelog: v0.4.0...v0.5.0

v0.4.0

Новый пакет @itd-api/hydrate, улучшенная типизация и внутренняя декомпозиция SDK

@itd-api/hydrate

• Новый пакет @itd-api/hydrate добавляет типизированные методы действий непосредственно к моделям постов, комментариев, пользователей, вложений и уведомлений.
• Посты получают методы get(), like(), unlike(), comment(), repost(), remove(), restore(), pin() и unpin().
• Комментарии поддерживают реакции, ответы, изменение, удаление, восстановление и загрузку ответов через getReplies().
• Авторы, профили и участники уведомлений получают методы работы с подписками, блокировкой и постами пользователя.
• Вложенные модели, страницы, Paginator, collect(), асинхронный перебор и результаты действий гидратируются автоматически.
• Гидратация поддерживается в realtime-контекстах, middleware и обработчиках уведомлений.
• Методы моделей не перечисляются через Object.keys() и не попадают в JSON.
• Пакет совместим с авторизацией, настройками запросов и подключёнными плагинами, включая @itd-api/cache.

Типизация

• Добавлен публичный тип CreatePostData для нормализованного результата PostBuilder.build() и resolvePost().
• Входной CreatePostInput по-прежнему принимает обычный объект, PollBuilder или функцию настройки опроса.
• RealtimeRouter теперь поддерживает собственный тип контекста, что позволяет безопасно использовать его с гидратированными realtime-обновлениями.
• Существующие публичные exports основного пакета сохранены.

Технические улучшения

• Модели разделены по доменам: пользователи, контент, уведомления, аккаунты, платформа и статусы.
• Контракты плагинов отделены от registry, порядка установки и выполнения hooks.
• Система вложений разделена на публичные контракты, фабрики, ограничения, настройки и потоковую обработку.
• Mock server из @itd-api/testing разделён на состояние, seed-данные, сущности и маршруты.
• Удалены внутренние фасады, которые больше не требовались для совместимости.

Full Changelog: v0.3.0...v0.4.0

v0.3.0

Новая система обработки realtime и пакет для тестирования.

Realtime

• Промежуточные обработчики обновлений через stream.use(). Обработчик может преобразовать обновление, выполнить действия до и после следующего обработчика либо остановить его дальнейшую передачу.
• Типизированные подписки и фильтры через onUpdate() и onNotification(). Уведомления можно отбирать по типу, участнику, сущности, родительской сущности и дополнительному условию.
• Маршрутизация обновлений через RealtimeRouter: отдельные цепочки обработчиков для разных типов событий и общий обработчик для остальных обновлений.
• Управляемая конкурентность: concurrency задаёт число одновременно обрабатываемых обновлений, а sequentialize() сохраняет порядок для связанных событий.
• Единый контекст обновления с нормализованными данными, источником и исходным транспортным кадром.
• Универсальное событие message для низкоуровневого наблюдения за всеми кадрами realtime-транспорта.
• Добавлены drain(), события ошибок обработчиков и предсказуемые снимки цепочек и маршрутов на момент получения обновления.

Тестирование

• Новый пакет @itd-api/testing для проверки клиентов, плагинов и прикладных сценариев без настоящего API.
• createMockFetch() позволяет задавать последовательности ответов, сетевые ошибки, задержки, незавершающиеся запросы и собственные маршруты.
• createMockServer() предоставляет API-сервер в памяти с общим состоянием пользователей, записей, комментариев, реакций, подписок и уведомлений.
• Операции клиентов изменяют состояние сервера: созданные записи и комментарии можно получить, изменить, удалить и восстановить.
• Добавлены готовые заготовки данных, управляемые часы, тестовый realtime-транспорт и ответы Server-Sent Events.
• Поддерживается проверка плагинов, повторных запросов, raw-ответов и сетевых перехватчиков клиента.

Технические улучшения

• Добавлен интерфейс ItdClock для управления тайм-аутами, повторами, ограничением
  частоты запросов и переподключением realtime.
• Retry-After в формате HTTP-даты учитывает часы клиента.
• Обновлены руководства и справочник realtime.
• Добавлена отдельная документация по @itd-api/testing.

Совместимость

• Существующие REST-методы и событийные подписки realtime сохраняются.
• @itd-api/testing@0.0.1 требует itd-api@^0.3.0.
• Требуется Node.js 18 или новее.

Full Changelog: v0.2.0...v0.3.0

v0.2.0

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

Возможности

• Переработанная система аттачей с новой архитектурой: единая система загрузки
  файлов для комментариев, постов и профилей. Улучшенная обработка ошибок, лучшая
  типизация, поддержка multipart запросов. Автоматическое определение MIME-типов и
  валидация размеров.
• Методы работы с текстовой разметкой: новый парсер parseMarkup() для анализа
  форматированного текста, поддержка меншенов, хэштегов, ссылок. Расширенный
  telemetry API с методами отправки спанов и трассировки.
• Утилиты для профиля пользователя: uploadBanner() и deleteBanner() для работы
  с баннерами, getAppVersions() для получения версий установленных приложений.
• Улучшенная обработка хранилища: переделана система работы с сессиями, лучшая
  интеграция со Storage API браузера и Node.js файловой системой.

Документация

• Новый сайт документации на GitHub Pages с полным API reference, примерами и гайдами.
• Обновлены все руководства
• Добавлены примеры использования для всех новых методов.
• Расширена документация по конфигурации и работе с ошибками.

Технические улучшения

• Миграция с tsup на tsdown для лучшей производительности сборки и использования более современной библиотеки
• Отдельные entry points для web среды с оптимизацией для браузеров.
• Матрица покрытия кода и улучшенные CI/CD workflows.

Full Changelog: v0.1.0...v0.2.0

v0.1.0

Первая версия библиотеки: ядро, разделы REST/realtime, мульти-аккаунты и экосистема
плагинов собраны в согласованный публичный контракт.

Возможности

• Полный клиент REST + realtime для итд.com: посты, комментарии, пользователи,
  подписки, хэштеги, поиск, уведомления, файлы, отчёты, верификация, платформа.
• Авторизация «сама»: продление токена по 401, повтор исходного запроса,
  единый refresh для параллельных вызовов, событие authError. Вход по токену,
  паре токенов или email+пароль с Turnstile.
• Несколько аккаунтов через ItdAccounts / FileMultiTokenStorage: именованные
  клиенты с раздельными токенами, cookie, deviceId и прокси, общая или раздельные
  очереди запросов, restore() без повторной капчи.
• Единая пагинация: курсор, страницы и смещение спрятаны за одним for await
  (iterate() / .pages()).
• Уведомления из REST и потока приведены к одной форме.
• Система плагинов и официальные дополнения:
  @itd-api/crypto, @itd-api/cache, @itd-api/proxy, @itd-api/turnstile.
• Билдер разметки и билдер создания постов ((p) => p.content(...).attach(...)).
• Ноль зависимостей у пакета; ESM + CommonJS; полные .d.ts с описаниями на русском;
  Node 18+, браузер, Bun, Deno, React Native. Точка входа itd-api/node — загрузка
  файлов по пути и файловое хранилище сессий.

Совместимость

• Публичный API совместим с 0.0.x.
• Требуется Node ≥ 18.

Full Changelog: v0.0.11...v0.1.0

v0.0.10

Full Changelog: v0.0.9...v0.0.10

v0.0.9

Full Changelog: v0.0.8...v0.0.9

v0.0.8

Full Changelog: v0.0.7...v0.0.8