Инструмент mise теперь поддерживает задачи в монорепозиториях, позволяя запускать команды в нескольких проектах одновременно. Это упрощает управление зависимостями и скриптами, особенно при работе с большими кодовыми базами. Например, можно выполнить mise run build для сборки всех проектов или mise run test для запуска тестов.

Ключевое преимущество — автоматическое определение контекста и зависимостей между проектами, что сокращает рутинные операции. Интеграция с существующими инструментами вроде npm scripts делает переход плавным. Такой подход экономит время и снижает вероятность ошибок при ручном управлении задачами.

• Пользователи высоко оценивают mise за универсальность в управлении версиями языков (Node, Python, Rust, Go) и инструментами в одном конфиге, упрощающую onboarding в проектах.
• Отмечается удобство встроенного раннера задач, который заменяет Makefile/Just и работает в монорепозиториях, обеспечивая единый интерфейс для задач независимо от языка.
• Высказываются опасения по поводу сложности PATH-менеджмента и возможного чрезмерного расширения функциональности (например, отсутствие кэширования задач и поддержки Windows).
• Некоторые пользователи сравнивают mise с более сложными системами (Bazel, Nix), отмечая его как более простую альтернативу с низким порогом входа.
• Обсуждаются интеграции с другими инструментами (uv, moon, turborepo) и необходимость улучшения документации, особенно для новичков.

• Разработчики ищут удалённую работу, многие открыты к релокации, предпочитают гибридный формат или готовы к редким командировкам.
• Основные технологические стеки включают Python, JavaScript/TypeScript, React, Node.js, облачные платформы (AWS, GCP) и контейнеризацию (Docker, Kubernetes).
• Специализации варьируются от full-stack, data engineering и машинного обучения до дизайна продуктов и UX/UI.
• Ключевые интересы: работа с LLM, AI-агентами, компьютерным зрением, распределёнными системами и дизайн-системами.
• Многие кандидаты имеют опыт более 10 лет, опыт построения масштабируемых продуктов и решения сложных бизнес-задач.

Devbox — это инструмент для создания изолированных сред разработки на основе Docker. Каждый проект работает в собственном контейнере, что предотвращает конфликты зависимостей и сохраняет чистоту основной системы. Контейнеры автоматически перезапускаются и сохраняются между перезагрузками, а код остаётся на файловой системе хоста для удобного редактирования.

Инструмент предлагает простые команды CLI, встроенные проверки безопасности и шаблоны для Python, Node.js, Go и веб-разработки. Также поддерживаются расширенные функции Docker, такие как проброс портов, монтирование томов и настройка переменных окружения.

• Обсуждаются сходства и отличия Devbox от альтернатив: Devcontainers (от Microsoft), Toolbx, Distrobox и других, с акцентом на поддержку в разных IDE и сложность их реализации вне VSCode.
• Поднимается проблема конфликта имен с другими проектами, в первую очередь с Devbox от Jetify, что указывает на возможное отсутствие анализа существующих решений.
• Отмечаются вопросы о безопасности и изоляции, в частности, возможность использования Docker-in-Docker и её последствия.
• Участники делятся личным опытом использования Devbox и аналогичных инструментов, отмечая их удобство для создания воспроизводимых сред без потери производительности.
• Обсуждается, решает ли подход с контейнерами проблему "dependency hell" и насколько он оправдан для разных языков и типов разработки (веб, мобильная).

• Обсуждаются новые функции Claude Code: расширение для VS Code, команда /rewind для отмены изменений, переработанный интерфейс и управление контекстом.
• Пользователи сравнивают Claude Code с конкурентами (Cursor, Aider, Goose), отмечая его преимущества и недостатки, такие как интеграция с инструментами и эргономика.
• Поднимаются вопросы о конфиденциальности данных, потреблении ресурсов (ОЗУ) и проблемах с UX/UI в новом расширении VS Code.
• Обсуждаются технические аспекты: работа с CJK-вводом, управление памятью, поддержка MCP, а также использование тегов и магических команд в промптах.
• Высказываются предложения по улучшению: индикация функции в diff, отображение оставшегося контекста, отмена выполнения промпта и улучшение команды /resume.

• Пользователи отмечают высокую полезность инструмента для автоматизации сбора данных и исследований, экономящей сотни часов ручного труда, особенно в B2B-сегменте и венчурном капитале.
• Поднимаются вопросы о технических ограничениях: переусложнение простых задач, неполное извлечение данных с некоторых источников, проблемы с интерпретацией запросов и необходимость ручного вмешательства для уточнения.
• Обсуждаются особенности архитектуры и UX: текстовый браузер с постоянным контекстом, интерактивный контроль над агентом, важность прозрачности процесса и возможность совместной работы в реальном времени.
• Высказываются опасения по поводу соблюдения правил сканирования (robots.txt), законности сбора данных с таких платформ, как LinkedIn и Reddit, а также долгосрочной жизнеспособности модели ценообразования «unlimited».
• Разработчики делятся техническим стеком (NextJS, NodeJS, Gemini 2.5 Flash, Firecrawl) и планами по улучшению, включая лучшую классификацию задач, навигацию по пагинации и более четкое различие с конкурентами.

Многие библиотеки в экосистеме JavaScript стали избыточно сложными из-за попыток обработать все возможные крайние случаи, даже те, что на практике почти не встречаются. Например, функция clamp, предназначенная для ограничения чисел, превращается в монстра, проверяющего строки, валидирующего типы и значения, что приводит к появлению микробиблиотек вроде is-number с 90 млн загрузок в неделю. Это результат плохого технического дизайна: вместо чёткого определения ожидаемых входных данных разработчики добавляют слои проверок для гипотетических сценариев.

Правильный подход — проектировать функции под конкретные типы данных, оставляя валидацию значений на усмотрение вызывающей стороны. Библиотеки вроде is-arrayish или pascalcase, принимающие разнородные входы, лишь увеличивают сложность и зависимости без реальной пользы. Стоит вернуться к простоте: в большинстве случаев достаточно встроенных методов языка, а специализированные решения нужны только для узких задач, а не как стандарт.

• Обсуждение критикует избыточное использование зависимостей в JavaScript/TypeScript для простых задач, таких как проверка типов, что ведет к раздуванию экосистемы.
• Участники связывают проблему с историческими особенностями JavaScript: отсутствием строгой типизации и богатой стандартной библиотеки в прошлом.
• Поднимается вопрос о дизайне контрактов функций: следует ли валидировать входные данные внутри функции или возлагать эту ответственность на вызывающую сторону.
• Отмечается культурное различие между сообществами: в Python принята модель "согласованных взрослых", а в JS — оборонительное программирование.
• Обсуждается роль статической типизации (TypeScript) и стандартных библиотек как способа уменьшить потребность в микро-пакетах для проверок.

GitHub Actions начинает процесс отказа от Node 20, так как его поддержка завершится в апреле 2026 года. Планируется переход на Node 24 осенью 2025 года. Сейчас последняя версия раннера поддерживает обе версии, но по умолчанию используется Node 20. Для тестирования Node 24 можно установить переменную окружения FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true.

С 4 марта 2026 года раннеры перейдут на Node 24 по умолчанию. Чтобы продолжить использовать Node 20 после этой даты, нужно установить ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true, но это будет работать только до лета 2026 года, когда Node 20 окончательно удалят. Node 24 несовместим с macOS 13.4 и ниже, а также не поддерживает ARM32, что повлияет на самохостинг. Разработчикам действий и пользователям рекомендуется обновить конфигурации и рабочие процессы соответственно.

• Пользователи выражают недовольство частыми устареваниями (deprecations) и проблемами совместимости в GitHub Actions, особенно с версиями Node.js (пропуск версии 22, переход на 24) и действиями (например, actions/checkout).
• Обсуждаются проблемы безопасности из-за уязвимостей в устаревших версиях Node.js в раннерах GHA, что может привести к компрометации репозиториев и инфраструктуры.
• Предлагаются альтернативы: использование самодельных скриптов для установки Node.js, упаковка действий в Docker-контейнеры или переход на самописные раннеры (например, github-act-runner) для большего контроля.
• Критикуется привязка к проприетарному сервису (GHA) для обеспечения долгосрочной стабильности сборок; предлагается выносить логику сборки в собственные скрипты (Makefile).
• Отмечаются проблемы с экосистемой Node.js: медленная адаптация зависимостей к новым LTS-версиям и отсутствие расширенной поддержки старых ОС со стороны провайдеров.

pnpm 10.16

12 сентября 2025 · 3 мин чтения

Незначительные изменения

Новая настройка для отложенных обновлений зависимостей

Для снижения риска установки скомпрометированных версий пакетов вводится настройка minimumReleaseAge, которая задерживает установку недавно выпущенных зависимостей. Например, minimumReleaseAge: 1440 разрешает установку только пакетов, выпущенных не менее дня назад.

Исключения можно указать в minimumReleaseAgeExclude:

minimumReleaseAgeExclude:
  - webpack

Расширенная фильтрация зависимостей с помощью функций-поисковиков

Добавлена поддержка finders в .pnpmfile.cjs. Теперь можно искать зависимости не только по имени, но и по другим свойствам, например, по наличию определённой версии React в peerDependencies:

module.exports = {
  finders: {
    react17: (ctx) => {
      return ctx.readManifest().peerDependencies?.react === "^17.0.0";
    },
  },
};

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

pnpm why --find-by=react17

Функции могут возвращать дополнительную информацию для вывода.

Исправления

• Устранено предупреждение о устаревании при запуске в Node.js 24.
• Добавлена проверка на точную версию semver для nodeVersion.
• Исправлена возможность публикации .tar.gz файлов через pnpm publish.
• Прерывание процесса Ctrl-C теперь возвращает ненулевой код выхода.

• Пользователи обсуждают стратегии защиты от вредоносных обновлений пакетов, включая задержку обновлений на несколько дней или месяцев и выборочное обновление только критических пакетов.
• Поднимается вопрос о том, как рассчитывается возраст пакета: важно использовать дату публикации в реестре, а не предоставленную автором, чтобы избежать подделки.
• Предлагаются альтернативные решения, такие как система разрешений для пакетов (à la Deno), разрешение зависимостей по хешу, а не по имени, и автоматизированный анализ кода ИИ перед публикацией.
• Отмечается, что подобные функции уже реализованы или разрабатываются в других менеджерах пакетов (Yarn, uv, Bun, npm-check-updates), и обсуждаются технические детали их реализации.
• Указывается на проблемы экосистемы npm: большой размер node_modules, высокая частота обновлений и автоматическое обновление минорных версий по умолчанию.
• Обсуждается роль автоматизированного сканирования новых пакетов security-компаниями как основного механизма обнаружения угроз, который может быть эффективнее индивидуальных задержек.
• Подчёркивается, что семантическое версионирование не всегда идеально соблюдается, и даже минорные обновления могут ломать совместимость, создавая риски при автоматическом обновлении.

О нет, снова... Размышления об атаках на цепочку поставок NPM

Я долго откладывал эту статью — более года — но, как мы видим на этой неделе, пришло время снять покровы и сказать вслух:

В 2025 году Microsoft следует считать «плохим игроком» и угрозой для всех компаний, разрабатывающих программное обеспечение.

Конечно, если вы достаточно взрослые, чтобы помнить — это не первый раз...

Время — плоский круг

Мы снова здесь — в 2025 году Microsoft настолько всё испортили, что создали ещё больший риск, чем в 2000-х с их браузером, просто ничего не делая.

Изначально я начал писать этот пост во время инцидента с xz — изощрённой и долгосрочной попытки взять под контроль библиотеку, используемую в менеджерах пакетов большинства дистрибутивов Linux.

С тех пор произошло множество инцидентов, и конкретно NPM стал крупнейшим и самым простым способом распространения вредоносного ПО. Сначала большинство атак было направлено на кражу криптовалюты (поскольку техбро одержимы магическими электрическими деньгами и являются лёгкой добычей). Но теперь эти атаки на цепочку поставок нацелены на более критичные вещи, такие как токены и ключи доступа maintainers пакетов, как видно из инцидента с NX и теперь несколькими зависимостями, ежедневно используемыми тысячами разработчиков.

Опять же... это ничего нового в мире NPM.

Но так быть не должно было...

Мы прошли долгий путь, но никуда не ушли

У меня долгая история с NodeJS — примерно в 2010 году я начал работать над стартапом, и это было до того, как npm вообще появился.

В туманные дни 1990-х большинство проблем безопасности JavaScript не сильно касались бэкенда: это в основном была область Perl, PHP, Python и Java.

Однако веб был совсем другой историей.

В самые ранние дни Всемирной паутины был только один основной браузер, который все использовали: Netscape Navigator. Выпущенный в 1994 году, он был не просто браузером: на протяжении своей жизни он имел различные воплощения встроенного почтового клиента, календаря, HTML-редактора с FTP-браузером, а с плагинами мог воспроизводить медиафайлы, такие как Realplayer и MP3 (что я помню при его запуске), а также флеш-фильмы и игры. Именно здесь родился JavaScript.

Многие ранние сайты того времени были статичными — популярные инструменты для создания сайтов включали HotDog или Блокнот. Никаких навороченных IDE или фреймворков, только текстовый редактор, браузер и alert() для отладки.

Microsoft также вошла в игру с Internet Explorer — включённым в раннее DLC для Windows под названием «Plus! For Windows 95». В конечном итоге он стал программным обеспечением, на которое Microsoft поставила всю свою корпоративную стратегию (во многом как сегодня с ИИ).

Internet Explorer был встроен в каждый аспект Windows — сначала в 1995 году с Active Desktop, что продолжалось вплоть до Windows XP. С ним можно было встраивать фрейм на рабочий стол, а также документы Rich Text или электронные таблицы Excel. Он также был раздутым и багнутым — и с этим представлял две проблемы: огромный риск безопасности и обвинения в монополизации рынка браузеров.

Закон жёстко настиг Microsoft, и в 2001 году она проиграла — Microsoft было приказано разбить компанию, но апелляция отменила это решение.

• Участники критикуют экосистему npm за уязвимости в цепочке поставок и отсутствие безопасности по умолчанию, сравнивая её с другими менеджерами пакетов.
• Обсуждается роль крупных компаний (в частности, Microsoft как владельца npm) в решении проблем безопасности и их ответственность за состояние экосистемы.
• Предлагаются конкретные меры: обязательная 2FA, подписывание кода, политика задержки обновлений (cooldown), переход на альтернативы (pnpm), сканирование пакетов.
• Поднимается проблема эксплуатации труда добровольцев в open-source и недостаточного вклада коммерческих организаций в проекты, которые они используют.
• Отмечается, что культура JavaScript-разработки чрезмерно зависит от большого количества зависимостей, что увеличивает поверхность атаки.
• Указывается на необходимость более строгого контроля зависимостей, включая проверку кода и фиксирование версий (pinning).
• Некоторые участники считают, что фундаментальные изменения в экосистеме маловероятны, и рекомендуют индивидуальные меры защиты.

Коротко: в NPM проникли популярные пакеты (colors, debug и др.) через фишинг письмо «смени 2FA». Вредоносный код подменял адреса криптокошельков.
Почему это мелко: библиотеки используются в CLI-утилитах, а не в Web3; украденные API-ключи или майнеры были бы катастрофой.
Вывод: любая зависимость может быть трояном, но проверять всё дерево пакетов никто не успевает — надо успевать релизить.

• Атака на NX через NPM показала, что даже популярные плагины могут стать вектором для кражи creds и API-кейсов.
• Участники сходятся: «всё дерево зависимостей NPM по умолчанию доверяет всем», а ручная проверка каждой мелкой библиотеки невозможна при скорости релизов.
• Многие выжили лишь благодаря «отложенным обновлениям», изоляции в контейнерах или отказу от экосистемы Node/NPM целиком.
• Фишинг на домене npm.help подтвердил, что даже IT-специалисты не всегда замечают поддельные TLD; предлагают белые списки ссылок и DMARC-индикаторы в клиентах.
• Утверждение «мы просто не заметили более продвинутые атаки» звучит всё чаще: Jia Tan 3.0, по мнению комментаторов, уже где-то в supply-chain.

• В npm-пакетах DuckDB версий 1.3.3 и 1.29.2 обнаружена вредоносная вставка.
• При установке пакета запускается пост-скрипт, который скачивает и исполняет сторонний исполняемый файл, собирая сведения о системе и отправляя их на сторонний сервер.
• Проблемные версии удалены из реестра npm; рекомендовано немедленно удалить их из проектов и перегенерировать все ключи/токены.

• Атака на NPM-пакеты DuckDB — результат обычного фишинга: злоумышленник подменил сайт, украл 2FA и сразу опубликовал вредоносные версии.
• Пострадали 4 пакета; вредоносный код вмешивался в криптотранзакции, но денег не украл.
• Уязвимость — человеческий фактор: даже технические мейнтейнеры кликают по ссылкам в «срочных» письмах.
• Обсуждение сводится к тезису: подписывать артефакты, использовать пасскеи/HSM, вводить «заморозку» публикации после смены 2FA и требовать ≥2 подписи мейнтейнеров.
• NPM-сообщество считает, что критическая инфраструктура (NPM, PyPI, Maven) должна быть защищена строже, чем обычные сервисы.

Статические сайты = машина времени
Варун написал о геймификации блогов, и я вспомнил свои «бейджики» 2021 года. Сначала подумал, что скриншотов нет, но потом понял: сайт на Eleventy статичный, поэтому достаточно git checkout нужного коммита и eleventy serve, чтобы увидеть страницу в том же виде.

В отличие от WordPress или сборок, где посты тянутся из CMS только при деплое, у меня каждый коммит — полный снепшот. Путешествие во времени занимает две команды (если только я не забыл закоммитить).

Год назад я завёл GitHub Action, который ежемесячно делает скрин главной «на всякий случай», но теперь не переживаю: история дизайна всегда под рукой в git.

Если тема близка — пишите на juhamattisantala@gmail.com, буду рад обсудить.

• Участники обсуждают, как лучше «путешествовать во времени» по старым версиям сайтов: Wayback Machine, Git-архивы, локальные бэкапы или собственные «музейные» режимы.
• Кто-то предпочитает чистый HTML/CSS без генераторов, чтобы минимизировать зависимости и упростить долгосрочное хранение.
• Поднимаются вопросы обратной совместимости JS/CSS и роли стандартов: насколько браузеры гарантируют, что сегодняшние сайты откроются через десятилетия.
• Упоминаются практические сложности: старые зависимости, версии Node, базы данных, билд-инструменты.
• Появляются идеи распределённого архивирования (плагины, GitHub Actions, клиентские кэши) и примеры «игровых» подходов к ведению блога.

• 20+ специалистов из 4 континентов ищут удалённую работу; большинство — full-stack, DevOps, ML/AI и мобильные разработчики.
• Регионы: США (Austin, SF, NYC, Florida), Латинская Америка (Буэнос-Айрес, Богота, Медельин), Европа (Лондон, Осло, Хорватия), Азия (Бангкок, Ханой), Африка (Лагос) и др.
• Ключевые стеки: Rust/Go/Python, React/Node, AWS/GCP, Docker/K8s, LLM/AI-инструменты, iOS/Android, а также редкие — DSP, C++, embedded.
• Готовность к релокации: ~30 % «да», ~60 % «только удалённо», остальные — «возможно при убедительном предложении».
• Уровни: от стажёров и new-grad до 20-летних ветеранов и CTO; многие предоставляют портфолио и рекомендательные письма.

Agent Client Protocol (ACP) — единый стандарт связи между редакторами кода и агентами-разработчиками на базе ИИ.
Протокол в разработке, но уже позволяет строить полезные интеграции.

Зачем ACP?

• Редакторы и агенты сейчас жёстко связаны: каждая пара требует собственной интеграции.
• Это → лишние затраты, ограниченная совместимость и привязка к конкретным интерфейсам.
  ACP, как LSP для языковых серверов, развязывает стороны: агент, реализовав ACP, работает во всех совместимых редакторах, а редактор, поддерживающий ACP, получает доступ ко всей экосистеме агентов.

Как устроено

• Агент запускается как подпроцесс редактора.
• Обмен — JSON-RPC через stdio.
• Используются типы MCP, дополнены собственными (например, для диффов).
• Текст для пользователя — Markdown, без необходимости HTML.

Поддержка

Редакторы:

• Zed
• neovim (через плагин CodeCompanion)

Агенты:

• Gemini
• Скоро — ещё.

• Предложен новый протокол (ACP) для связи агентов-ИИ с IDE/редакторами, плюс библиотеки на Node, Python, Rust и сайт.
• Название ACP вызывает путаницу с уже существующим agentcommunicationprotocol.dev и IBM/Google A2A.
• Некоторые считают, что достаточно расширить LSP или MCP, другие предлагают «Neovim внутри Claude Code», а не наоборот.
• Уже есть первые реализации для Claude Code и Zed, но остаются проблемы с поиском несохранённых файлов и UI-дифами.
• Обсуждают риск фрагментации стандартов и желание, чтобы любой редактор мог подключиться без переписывания под каждого агента.

Задача
Лондонское агентство Strand ведёт сотни маркетинг-проектов в год. Финансовый учёт раньше велся вручную через таблицы. В 2020 г. команда из трёх разработчиков запустила прототип финансовой системы; он быстро стал критически важным, и потребовалось обеспечить надёжность и простоту поддержки при минимальных ресурсах.

Решение
Strand выбрал язык Gleam на платформе BEAM:

• Безопасность: чистый код не падает; сбои внешних сервисов изолируются лёгкими процессами.
• Практичность: язык мал, однозначен, осваивается за день; доступны 40 лет библиотек Erlang/Elixir.
• Опыт разработки: единый пакет с форматтером, автодополнением и понятными ошибками; сборка мгновенная.

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

• Вероятно, языки вроде Gleam выиграют у ИИ благодаря строгой типизации и быстрой обратной связи.
• Некоторые новички застревают в «абстракционном аду» и советуют сначала освоить Erlang/Elixir.
• Производственные истории успеха Gleam на BEAM вдохновляют.
• Однофайловые исполняемые файлы можно собрать через компиляцию в JavaScript + Node SEA или Burrito, но полноценный VM-free релиз пока нет.
• Качество примеров и стабильность языка становятся важнее их количества для LLM.
• Чистые, референциально прозрачные языки удобны ИИ для параллельного тестирования блоков кода.

Open Source — это один человек
Сокращённый перевод поста Джоша Брессерса

Публикация The Register, высмеивающая российского разработчика за то, что его утилита используется Пентагоном, — позор. На самом деле почти всё open-source ПО в мире пишут одиночки.

Проект ecosyste.ms индексирует 11,8 млн репозиториев. Из них 7 млн обслуживает один человек. Ещё 4 млн — данные о количестве мейнтейнеров отсутствуют, но большинство из них тоже «одиночки».

В экосистеме NPM картина та же:

• 4 млн пакетов → ~900 тыс. авторов (один человек — много проектов).
• Среди 13 тыс. самых скачиваемых пакетов (>1 млн загрузок в месяц) почти половина поддерживается одним человеком.
  Только при пороге в 1 млрд загрузок большинство проектов имеют команду >1 человека.

Вывод

• Риск цепочки поставок — не страна происхождения мейнтейнера, а один человек без ресурсов и оплаты.
• Уязвимость — не «русский хакер», а перегруженный разработчик, который может случайно или умышленно сломать критическую библиотеку.
• Обвинять таких людей в «предательстве» — неэтично и бесполезно.

Что делать? Однозначного рецепта нет, но начать стоит с признания проблемы и поддержки мейнтейнеров, а не травли.

• Проблема рисков цепочки поставок в OSS — это не инженерный, а управленческий вопрос: один автор, даже без злого умысла, создаёт уязвимость.
• Большинство пакетов NPM — одноразовые проекты одного человека; половина вообще не имеет активных мейнтейнеров.
• При «кончине» единственного мейнтейнера проект либо умирает, либо его форкают, либо приходит замена — зависит от размера аудитории и сложности кода.
• Критика статьи: автор путает скачивания CI/CD с реальным использованием, игнорирует реальное число контрибьюторов и подменяет статистику.
• DoD, как и любая крупная организация, использует Node/NPM для низкокритичных задач, а критичный код вендорится и аудируется.

Как создать инструкцию по установке MCP-сервера

1. Определите тип сервера

   • stdio – локальный процесс.
   • sse – удалённый HTTP-эндпоинт.

2. Соберите метаданные

   • Название, описание, автора, ссылку на репозиторий.
   • Требования: Node.js, Python, Docker и т.д.
   • Порт (для SSE), путь к исполняемому файлу (для stdio).

3. Сформируйте claude_desktop_config.json
   Пример stdio:

   {
     "mcpServers": {
       "my-server": {
         "command": "node",
         "args": ["build/index.js"],
         "env": { "API_KEY": "xxx" }
       }
     }
   }
   

   Пример SSE:

   {
     "mcpServers": {
       "my-server": {
         "url": "http://localhost:3000/sse",
         "headers": { "Authorization": "Bearer xxx" }
       }
     }
   }
   

4. Сгенерируйте инструкцию

   • Установите зависимости (npm i, pip install -r requirements.txt).
   • Скопируйте claude_desktop_config.json в %APPDATA%\Claude\ (Win) или ~/Library/Application Support/Claude/ (macOS).
   • Перезапустите Claude Desktop.

5. Проверьте работу
   Откройте Claude → шестерёнка → Developer → MCP → убедитесь, что сервер “Connected”.

6. Опубликуйте
   Добавьте README.md с шагами выше и примером конфига.

• Пользователи хотят не просто «забронировать», а исследовать: «покажи самые дёшевые окна в Токио за 3 месяца».
• Все сходятся, что полностью автономное бронирование пока ненадёжно: доверие к ИИ низкое, цены скачут, а условия договора надо принимать вручную.
• MCP-серверы рассматриваются как новая «AI-API» — удобно для агентов, но бизнес может быстро закрыть доступ, если это ударит по рекламе и контролю.
• Kiwi и прочие агрегаторы могут зарабатывать на самой продаже билетов и страховках, а не на рекламе, но риски покупки у посредников остаются.
• Пока что MCP-инструменты лучше работают как «умный поиск с последующим подтверждением человека», а не как полностью автономный консьерж.

Критическая уязвимость в NX
NX (Nrwl) скомпрометирован: злоумышленники внедрили вредоносный код, крадущий кошельки и учётные данные.

• Что случилось: в пакетах @nx/nx-linux-x64-gnu, @nx/nx-linux-x64-musl, @nx/nx-win32-x64-msvc обнаружен backdoor.
• Как работает: при установке пакета запускается скрипт, который крадёт файлы .env, wallet.dat, id_rsa и отправляет их на сервер злоумышленников.
• Кто под угрозой: все, кто установил заражённые версии с 2024-06-01 по 2024-06-05.
• Что делать:
  1. Проверить версию NX: nx --version.
  2. Обновиться до последней версии (≥19.1.1).
  3. Проверить проект на наличие подозрительных скриптов в node_modules/.bin.
  4. Сменить все пароли и ключи, хранившиеся в проекте.

Semgrep уже выпустил правило для обнаружения вредоносного кода:

semgrep --config=auto .

• Компрометация npm-токена позволила злоумышленнику встроить вредоносный post-install-скрипт в популярные пакеты Nx.
• Скрипт проверяет наличие Claude Code / Gemini CLI и использует LLM для поиска секретов, обходя статический анализ.
• Участники советуют отключать npm-скрипты (ignore-scripts true), использовать pnpm/bun, изолировать установку в контейнеры/VM и минимизировать зависимости.
• Подчёркивается, что AI-агенты, запускаемые без песочницы, становятся мощным вектором атаки.

Trace — полный путь одного запроса через все сервисы.
Span — отдельный шаг в этом пути (функция, SQL, HTTP-вызов).
Root span — первый span (обычно входящий HTTP-запрос).
Child span — вложенный шаг.
Context — передаёт trace_id и текущий span по асинхронным вызовам.
Sampler — решает, записывать ли трассировку.
Exporter — отправляет spans в OneUptime, Jaeger и т.д.

---

Структура span

• name — короткое имя операции
• start/end time — длительность
• status — OK / ERROR
• attributes — произвольные метки (user_id, db.table)
• events — точки во времени (exception, cache hit)
• links — связи с другими traces

---

Быстрый старт в Node.js / TypeScript

npm i @opentelemetry/api @opentelemetry/sdk-node \
      @opentelemetry/auto-instrumentations-node

// tracing.ts
import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

const sdk = new NodeSDK({
  serviceName: 'my-api',
  traceExporter: new OTLPTraceExporter({ url: 'https://otlp.oneuptime.com' }),
  instrumentations: [getNodeAutoInstrumentations()],
});
sdk.start();

---

Ручная инструментация

import { trace } from '@opentelemetry/api';
const tracer = trace.getTracer('my-service');

async function getUser(id: string) {
  return tracer.startActiveSpan('db.users.findById', async (span) => {
    span.setAttributes({ 'db.table': 'users', 'user.id': id });
    try {
      const user = await db.users.findById(id);
      span.setStatus({ code: SpanStatusCode.OK });
      return user;
    } catch (e) {
      span.recordException(e);
      span.setStatus({ code: SpanStatusCode.ERROR, message: e.message });
      throw e;
    } finally {
      span.end();
    }
  });
}

---

Express/Fastify middleware

import { trace } from '@opentelemetry/api';

export function traceMiddleware(req, res, next) {
  const span = trace.getTracer('http').startSpan(`${req.method} ${req.route?.path || req.url}`);
  trace.getActiveContext().with(trace.setSpan(trace.getActiveContext(), span), () => {
    res.on('finish', () => {
      span.setAttributes({
        'http.status_code': res.statusCode,
        'http.method': req.method,
        'http.route': req.route?.path,
      });
      span.end();
    });
    next();
  });
}

---

Практические советы

• Именование: verb noun (GET /users, db.users.insert).
• Атрибуты: добавляйте user.id, order.id, region.
• Ошибки: span.recordException(err) + span.setStatus({code: ERROR}).
• Sampling: head-based (решение на старте) или tail-based (после завершения).
• Антипаттерны: слишком мелкие spans, отсутствие span.end(), захардкоженные ID.

---

Сборка всего вместе

1. Запустите SDK на старте приложения.
2. Добавьте auto-instrumentations (http, express, pg, redis).
3. Дополните ручными spans для критичных операций.
4. Отправляйте traces в OneUptime → исследуйте flame-графы, ищите узкие места.

• OTEL хвалят как стандарт, но реальные реализации сильно разнятся между вендорами и часто усложняют жизнь.
• Базовые понятия: span — это интервал работы с уникальным ID и ссылкой на родителя, trace — DAG спанов, рассказывающий историю запроса.
• Авто-инструментация почти даром даёт данные для JVM-приложений, но вне веб-бэкендов примеров мало и приходится искать «правильный» подмножество.
• Некоторые жалуются на объём кода и хранилище (десятки ТБ трейсов за неделю), другие считают это разовой настройкой и платой за прозрачность системы.
• Появляются упрощающие обёртки (Logfire, otelize) и примеры интеграции, но документация по дашбордам Grafana всё ещё вызывает трудности.

Суть проблемы
В npm-реестр попали вредоносные версии пакетов Nx и связанных плагинов. Злоумышленники использовали временный доступ к npm-аккаунту @nxscope и опубликовали поддельные версии 19.8.0–19.8.2.

Затронутые пакеты

• nx
• @nx/angular, @nx/cypress, @nx/detox, @nx/devkit, @nx/esbuild, @nx/eslint-plugin, @nx/expo, @nx/express, @nx/jest, @nx/js, @nx/nest, @nx/next, @nx/node, @nx/playwright, @nx/plugin, @nx/react, @nx/rollup, @nx/storybook, @nx/vite, @nx/web, @nx/webpack, @nx/workspace

Что делать

1. Удалить вредоносные версии.
2. Установить официальные 19.8.3 или выше.
3. Проверить lock-файлы и CI на наличие подозрительных версий.

• Уязвимость в пакетах Nx: токен npm скомпрометирован, злоумышленники внедрили вредоносный код через post-install скрипты.
• Малварь ищет Claude Code / Gemini CLI и использует их как «живые» инструменты для поиска криптокошельков, ключей и других секретов.
• Участники советуют отключать npm-скрипты (ignore-scripts true), использовать Bun (по умолчанию не запускает скрипты), Verdaccio для вендоринга и инструмент vet для сканирования.
• Рекомендуют разрабатывать в изолированных контейнерах/VM (cubbi, bubblewrap, firejail) и пересматривать каждую зависимость вместо «npm install наугад».
• Основной вывод: современные цепочки поставок и AI-агенты создают новый вектор атак «prompt-as-malware», а операционные системы всё ещё позволяют приложениям свободно читать весь диск.

async-server — это CLI-утилита, объединяющая Claude Code, Linear и GitHub PR.
Она позволяет:

• Планировать задачи прямо в терминале (как в Linear).
• Писать код с помощью Claude Code: создавать ветки, коммиты, PR.
• Ревьюить изменения и мержить без выхода из консоли.

Установка:

npm i -g async-server
async-server init

Команды:

• async task "добавить логин" – новая задача.
• async code – Claude генерирует код.
• async pr – создаёт PR и связывает с задачей.

Полностью асинхронный workflow: задачи, код, ревью — всё в одном потоке.

• Пользователи хвалят темную тему и концепцию, но сомневаются в необходимости платить GCP за каждое взаимодействие и просят локальный режим.
• Критика: не хватает полноценного тестирования (сборка/запуск кода), а упоминание Linear в заголовке кажется лишним.
• Автор подтверждает: сейчас большая часть выполняется в облаке, но команда работает над локальной версией и улучшенным тестированием изменений.

Hyperclay — однофайловые HTML-приложения
Работайте как с глиной: открыли файл, изменили — изменения сохранились. Без сборки, деплоя и фреймворков.

• Прямое редактирование в браузере: меняете DOM — файл перезаписывает себя через /save.
• Полная переносимость: скачали HTML — запустили где угодно, офлайн.
• Версии: каждое сохранение фиксируется, откат в один клик.

Примеры: dev-log, writer, kanban, landing.

Почему это важно

Статические сайты удобны, но изменения исчезают после перезагрузки. Чтобы сделать цифровой объект «физическим» — нужен сервер, БД, API, аккаунты. Hyperclay убирает всё лишнее: UI, логика и данные — в одном самомодифицирующемся HTML-документе.

• Hyperclay — это NodeJS-сервер + клиентская библиотека, которая сохраняет изменения DOM прямо в исходный .html-файл, обновляя его на лету.
• Идея вызывает ассоциации с TiddlyWiki, Webstrates и даже HTA-архивами Windows 98, но делает акцент на многопользовательской работе и версионировании.
• Участники обсуждают проблемы локального file:// (CORS, модули), безопасность, ограничения iOS и то, что без сервера изменения не сохраняются.
• Некоторые делятся своими однофайловыми решениями: шифровальщик, Asteroids, «твиттер» на git-коммитах и т.д.
• Сообщество просит открытый код, нормальную документацию и понятную схему версионирования/обновления приложений.

Node.js v22.18.0 LTS
31 июля 2025

Главное

• TypeScript без конфигурации
  .ts файлы запускаются напрямую:

  echo 'const foo: string = "World"; console.log(`Hello ${foo}!`);' > file.ts
  node file.ts   # → Hello World!
  

  Ограничения описаны здесь. Отключить: --no-experimental-strip-types.

Ещё важное

• amaro обновлён до 1.1.0
• import.meta.main в ESM
• fs лучше справляется с всплесками событий через AsyncIterator
• permission передаёт флаги модели разрешений при spawn
• sqlite поддерживает readBigInts на уровне соединения
• url добавлен fileURLToPathBuffer
• watch новый флаг --watch-kill-signal
• Worker стал асинхронно disposable

Другое

• npm 10.9.3, sqlite 3.50.2, обновления minimatch, acorn, googletest
• мелкие исправления в crypto, build, assert и др.

• Node.js теперь умеет запускать .ts-файлы «из коробки», вырезая типы без транспиляции, но поддерживает лишь подмножество TS (без enum и т.п.).
• Новая возможность не распространяется на node_modules, что вызывает вопросы о библиотеках и приватных пакетах.
• Многие радуются упрощённому DX, но часть пользователей уже сталкивается с ошибками обновления из-за ограниченного набора фич.
• Критики считают, что Bun и Deno давно решают эти задачи лучше и быстрее, однако Node остаётся «де-факто» стандартом.
• Итог: шаг вперёд для Node, но полноценная замена tsc/Bun пока невозможна; выбор рантайма по-прежнему зависит от проекта.

Porffor — экспериментальный JS-движок, компилирующий код в WebAssembly и нативные бинарники. Вместо упаковки рантайма (как Node/Bun) он генерирует крошечные (<1 MB) и быстрые (миллисекунды) исполняемые файлы.

porf native hi.js hi   # 12.9 KB
./hi                   # 631 µs

Сравнение с Deno/Bun: размер 16 KB против 80–100 MB, старт в 631 µs против 15–37 ms.

Lambda

На AWS Lambda Porffor показал:

• Node (baseline): до 300 ms холодного старта.
• LLRT: ~3× быстрее Node, но дороже из-за отсутствия managed runtime.
• Porffor: ~12× быстрее Node и ~4× быстрее LLRT, при этом дешевле даже с учётом «managed runtime» Node.

P99 Porffor быстрее P50 у конкурентов.

Итог

Porffor ещё pre-alpha: поддержка JS ≈60 %, нет I/O и Node-совместимости. Подходит для маленьких лямбд без Node-API.
Код и данные бенчмарков: GitHub.

• Porffor — экспериментальный AOT-компилятор JS/TS → WASM → C, обещает убрать «холодные» старты Lambda и дать ~16 мс инициализации, но пока без GC, без полной совместимости с Node API и лишь ~60 % тестов ECMAScript проходит.
• Участники спорят, насколько критичны 200-600 мс холодного старта: кто-то считает проблемой для миллионов мелких запросов, кто-то — редким неудобством, решаемым резервными инстансами или переходом на Go/Rust.
• Сомнения в зрелости: «раньше быстро, пока не реализуешь оставшиеся 20 % фич»; безопасность и поддержка всей экосистемы JS вызывают скепсис.
• Плюсы: возможность компилировать в маленькие бинарники, использовать WASM-рантаймы, обходиться без JIT и доверять «своему» коду.
• Минусы: нет GC (хотят прикрутить WasmGC или Fil-C), нет I/O и полной Node-совместимости, корпоративные пользователи опасаются «экспериментов».

• Сгенерированное ИИ изображение, где ИИ руками «отвергает» меня. Очень мета.

В октябре 2024 Anthropic представила «Claude Computer Use», позволяющую ИИ управлять компьютером, копировать данные из браузера в таблицы и т.п. Я поддерживаю библиотеку для управления компьютером и этой весной решил разобраться, как они это делают. К моему удивлению, Anthropic использует мою библиотеку enigo.

Проверить использование enigo в Claude Desktop для macOS можно так:

• 7z x Claude.dmg
• perl -nle 'print $& while /.{0,67}enigo.{0,30}/g' Claude/Claude.app/Contents/Resources/app.asar.unpacked/node_modules/claude-native/claude-native-binding.node Вывод содержит путь к enigo-0.2.1/src/macos/macos_impl.rs

На Windows:

• 7z x Claude-Setup-x64.exe
• 7z x AnthropicClaude-0.11.6-full.nupkg
• perl -nle 'print $& while /.{0,75}enigo.{0,26}/g' Claude-Setup-x64/AnthropicClaude-0.11.6-full/lib/net45/resources/app.asar.unpacked/node_modules/claude-native/claude-native-binding.node Вывод указывает на enigo-0.2.1/src/win/win_impl.rs

Я горжусь, что enigo дорос до продакшена у компании с огромным бюджетом. Эмуляция ввода сложна из‑за слабой документации и платформенных особенностей. На мой взгляд, enigo — отличный выбор: работает на Windows, macOS, *BSD и Linux (Wayland, X11, libei) без root; написан на Rust (безопасность памяти, высокая скорость); самый популярный на crates.io (~300k загрузок, 1200+ звёзд). И всё же тревожно, что мой хобби‑проект установлен на тысячах устройств.

Сколько я на этом заработал? Нисколько: enigo под MIT‑лицензией — можно бесплатно использовать. Взамен — звёзды на GitHub и счётчик загрузок.

Интересно, что Claude Desktop — Electron‑приложение, но есть только для macOS и Windows. Сообщество запустило его на Linux, заменив вызовы enigo заглушками, хотя enigo кроссплатформенна — любопытный выбор.

Через знакомых я узнал об открытой роли в команде, делавшей секретную, ещё не выпущенную функцию Claude Desktop с enigo. Подал заявку, ждал. В итоге пришло письмо: команда не успевает рассматривать дополнительные заявки.

Я бы с радостью поработал в Anthropic: сделать аналог Computer Use, довести Claude Desktop до Linux, вложить свой опыт в эмуляцию ввода и полноценно отполировать enigo, чтобы Anthropic концентрировалась на моделях, а не на капризах ввода.

В целом я счастлив, что enigo в Claude Desktop, и всем об этом рассказываю. Забавно думать, что я метафорически дал Claude руки и ноги — и получить отказ. Письмо написал человек или сам Claude? По крайней мере, теперь я, наверное, в безопасности…

• Обсуждение вокруг автора OSS-библиотеки enigo, которую, по словам поста, использует Claude Desktop; при попытке податься в Anthropic он получил авто‑отказ без рассмотрения, что вызвало резонанс.
• Многие считают, что заявку, вероятно, даже не читали из‑за перегруженных или автоматизированных HR/ATS‑процессов; советуют искать тёплый интро к менеджеру, а не подаваться «в общий ящик».
• Поднята тема лицензий: permissive (MIT) позволяет корпорациям брать код без вклада; участники предлагают рассмотреть MPL/EUPL, Fair Source или даже целевые ограничения, хотя применимость и исполнение спорны.
• Несколько комментаторов призывают Anthropic хотя бы поблагодарить автора, дать консультационный контракт или символическую компенсацию; другие напоминают, что компания волна отбирать кого хочет.
• Обсуждаются возможные факторы отказа: геолокация (США vs Европа), визы, несоответствие профиля «AI‑инженеру», парадоксы найма и предпочтение «низкопрофильных» кандидатов.
• Приводятся похожие кейсы из индустрии: от игнора мейнтейнеров до неудачных интервью у компаний, зависящих от их софта.
• Общий вывод: современный тех‑набор страдает от автоматизации и перегрузки; для кандидатов критичны нетворкинг, прямой контакт с нанимающим менеджером и стратегия видимости, а для OSS — осознанный выбор лицензии.

Whoa, I didn't know about this: # Run with restricted file system access node --experimental-permission \ --allow-fs-read=./data --allow-fs-write=./logs app.js # Network restrictions node --experimental-permission \ --allow-net=api.example.com app.js Looks like they were inspired