Скоро запускается открытый лекторий летних школ. Заглядывайте 10-го, кто хочет послушать как я буду 2 часа нудеть про Node.js. Другие лекции тоже интересные!

Очередной забавный кейс с npm

Есть у нас приложение, которое поднимает стенды с приложеньками, «ферма» называется. Вот просто, качает нужную ветку из git, делает условно npm ci && npm run build && npm run start и поднимает инстанс, на который мы натравливаем E2E. Да-да, мы знаем про докер, но пока не успели.

И вот буквально позавчера ловим странный баг. В одной из веток не устанавливается несколько зависимостей. Просто нет их node_modules. Локально не повторяется. Захожу на ферму, дёргаю npm ci из консоли — всё ок. Зависимости не ставятся:

1) только когда npm ci вызывается из самой фермы через child_process.exec,
2) только на конкретной ветке.

Ооок. Я магию не люблю, потому сажусь разбираться. Посмотрим что там в env. Ого, а там npm_config_legacy_peer_deps: 'true' . П-нятненько почему зависимости не ставятся, они же peerDeps.

Две загадки:

1) Откуда legacy-peer-deps залетает в env,
2) Почему он влияет не всегда.

Что ж, ответ на первую. В папке самой фермы в .npmrc лежит legacy-peer-deps=true. Когда мы её запускаем через npm run start npm читает .npmrc и прокидывает в env всю свою лабуду в npm_config_*. А child_process.exec запускает дочерние процессы с process.env родителя.

Ответ на вторую загадку. npm ci --legacy-peer-deps не разрушал приложение, потому что ставил все зависимости как и было написано в package-lock.json. Но в конкретной ветке случилась коллизия, зависимость поставили и в devDependencies и в просто dependencies. Вот после этого npm ci перестал доверять package-lock.json и пересчитал всё дерево, уже тихо применяя к нему правило --legacy-peer-deps.

Люблю я эту работу.

Бэкстейдж, кстати. В этот раз сильно меньше недоволен результатом, получилось упихнуть в полтора часа больше полезного и гораздо меньше воды. Уже не медь, но до золота ещё пара итераций нужна.

Никита молодец, будь как Никита и его команда!

CodeRun. Большой запуск

Делюсь с вами сокровенным. Я в прошлом году писал в этот канал, что мы с большой командой неравнодушных к кодерским соревнованиям людей запустили бету нового сервиса, CodeRun. Мы тогда собрали много полезного фидбека, в том числе от вас.

Сегодня мы выходим из беты! Случилось то, к чему я шёл несколько лет. Очень волнительно 🙂

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

Так как я вообще-то фронтендер и хочу больше фронтендерских челленджей, то помимо нового сезона CodeRun мы запускаем скриншотные задачи — задачи, где надо подобрать вёрстку под картинку. Как иногда в проектах бывает, только ещё более пиксель-пёрфект.

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

А всей большой команде CodeRun хочу выразить огромную благодарность за то, что помогли реализовать мою старую мечту — сделать классный тренажёр с интересными задачами для тех, кто хочет развиваться и прокачиваться. Люблю вас! 💛

https://coderun.yandex.ru/

Николас Закас (автор ESlint) поделился своими размышлениями про безопасное использование Bun и Deno. Хорошие поинты:

1 Не используйте API, специфичные для Deno или Bun. Это затруднит смену рантайма если что-то пойдёт не так с этими двумя. Придерживайтесь Node.js API, которые уже поддерживаются в Deno и Bun.

2 Используйте префикс 'node:' для внутренних модулей Node.js. И Deno, и Bun поддерживают большую часть внутренних модулей Node.js, но они могут идентифицировать эти модули только при наличии префикса 'node:'. Node.js прекрасно работает при использовании префикса 'node:', поэтому вы можете обеспечить совместимость во всех трех средах выполнения.

3 В Deno используйте пакеты из npm и JSR, а не спецификаторы HTTP-модулей. Одним из первых нововведений в Deno была возможность указывать модули с помощью URL-адресов. Deno по-прежнему остается единственным рантаймом, поддерживающим такой способ загрузки модулей, поэтому лучше всего использовать npm и JSR пакеты, которые можно использовать во всех трех рантаймах.

4 Используйте package.json для указания зависимостей. Deno рекомендует вам использовать deno.json или jsr.json для указания ваших зависимостей, но он также может использовать package.json.

5 Также всегда запускайте на CI проверки совместимости с Node.js. Node.js это отличный запасной вариант, если вы используете Deno или Bun, поскольку не привязан к какой-либо одной компании. Чтобы оставить возможность быстрой смены рантаймов полезно всегда запускать тесты в CI в Node.js даже если вы переходите на Deno или Bun.

Благодаря отличной совместимости Deno и Bun с Node.js API, сейчас проще, чем когда-либо писать единый код для всех трёх сред выполнения. Трюк заключается в том, чтобы нацелиться на Node.js, а затем использовать функции совместимости Deno и Bun. Таким образом, если в любое время произойдет смена рантайма, ваше приложение сможет работать без особых проблем.

For idiots like me. The rate function over a cpu seconds counter reads "How many seconds did the cpu work every second?". 1 second every second on 1 core will be 100%. 3 cores at 50% will be 1.5 seconds every second, etc... The bracket is the averaging window, longer periods will flatten the graph. Tune according to how erratic your cpu usage is.

link

Захотелось книжку «Девос для идиотов».

А вообще где нам нужен rate? Конечно же когда мы отгружаем process.cpuUsage() в какой-нибудь прометей. Нам нужно смотреть не в сами значения, а в прирост между ними. Потому и формула

rate(container_cpu_user_seconds_total[30s])

Typenoscript теперь и в Node.js?

В свежем выпуске мы затронули нашумевший PR. Что случилось то? А случилось такое, что в Node.js подвезли в экспериментальном режиме загрузчик для ts файлов. Работает он очень просто (правда просто). В ноду вшивается SWC в виде скомпиленного для WASM бинаря. TS файлы прогоняются через SWC и из них отстреливаются типы. Всё. Enum и namespace не работают (о счастье). Никакие транспиляции трансформации не производятся. Просто отстреливаются типы.

Есть ли проблемы? Конечно есть. Например, нужно писать расширение файлов в импортах. Потому что импорт так работает бай дизайн.

Почему это круто и важно? Потому что транспиляция раздражает. Потому что хочется всё иметь из коробки и без настроект. Накидать ts-файлик и запустить.

В общем, неожиданно и очень приятно.

UPD
Почитайте роадмап обязательно (спасибо @kravetsone, что напомнил)

Простой лайфхак как сделать звук на созвоне значительно лучше (причём с обеих сторон), если у вас под рукой только bt-наушники.

Выберите источником звука микрофон ноута и не насилуйте пропускную способность bt-канала.

А вот и продолжение истории поддержки TypeScript в Node.js подоспело. Был добавлен флаг --experimental-transform-types, который добавляет возможность запускать файлы с TypeScript-only (требующем трансформации) синтаксисом (Enum, namespace, module с поддержкой source-map). Однако Node.js всё ещё не читает ваш tsconfig.json.

Из интересного: чтобы импортировать (import, require) файл, вам необходимо будет указать расширение .ts, которое включается в TS-конфиге опцией allowImportingTsExtensions. А ещё появилась целая команда для поддержки TypeScript в Node.js.

Кроме того, импорты типов должны быть помечены как type импорты, как при включенном verbatimModuleSyntax в TS-конфиге, иначе вы получите ошибку в рантайме.

import type { Type1, Type2 } from './module.ts';
import { fn, type FnParams } from './fn.ts';

Также предлагается добавить в feature флаги информацию о возможности импортировать файлы с типами или TypeScript-only синтаксисом.

process.features.typenoscript
//               ^? "strip" | "transform"

Всего 4 дня назад в eslint появилась поддержка `.ts` конфигов благодаря jiti, поэтому нововведения в Node.js по импорту .ts файлов облегчат жизнь всему нашему сообществу.

Очень советую к прочтению этот README и ROADMAP, а ещё спасибо @melikhov_dev за упоминание!

Pull Request

Полтора часа с Кириллом хоронили ноду на бэкенде.

https://youtu.be/98qu3CqRNb8

https://youtu.be/DH9vEW5_PiY

Осень — это время когда проекты оживают. Запуски, презентации, становится снова интересно в индустрии.

Я побежал, у меня сентябрь горит.

HTTP 301/302 vs 307/308

Разницу между этими кодами кажется знают все, кто однажды менял домен в большом популярном сервисе :) Живёте вы годами на одном домене, копите внешние ссылки, прорастают приложения и виджеты. А в один прекрасный день едете на другой домен и вам нужно сохранить всё богатство в рабочем состоянии.

И вот тут появляется вроде бы мелочь (совсем нет) — 307/308 сохраняют оригинальный метод запроса и его body(payload). Ну а 301/302 уходят на новый адрес через GET, теряя всё тело и разрушая все ваши апишки.

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

Продолжаю и буду продолжать настаивать, что тёмная тема не может автоматически рассматриваться как «лучше для глаз, лучше ночью». Если запилили только тёмную, то пилите и светлую, пожалуйста.

Нужен ли режим сепии по умолчанию?

Татьяна Фокина на примерах очень хорошо объясняет, почему тёмной и светлой тем недостаточно для комфортной работы с сайтом.

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

Многие операционные системы поддерживают похожий режим для всего интерфейса сразу, когда цвета становятся более тёплыми.

Астигматизм — очень распространённая особенность зрения у взрослых, поэтому, возможно, не помешает в браузерах добавить какую-то дополнительную настройку доступности. Но пока такого нет, есть смысл для заботы о пользователях добавить третью тему. Таня верно в статье замечает, что менеджеры такому «обрадуются», конечно. К тому же кому-то тёмная тема как раз более комфортна для зрения, чем режим сепии. Но задуматься о том, что доступность — это не только про контрастность, важно.

https://a11y-blog.dev/ru/articles/is-sepia-mode-essential/

Традиционно вылетаю в родную Уфу на Ufadevconf. Наконец-то нашёл куда пристроить доклад про песочницы на node.js-бэкенде. Везу мерч, подходите с вопросами. Трансляции не будет.

Зато будет трансляция на юбилейном Я.Субботнике по фронтенду 15 декабря (что? да, Субботник будет в воскресенье!). Там и зафиналю тему. Непривычно делать так мало докладов за год, но что-то времени не хватает катастрофически.

Никита Прокопов негодует (как обычно). Обновил npm на минор и вылез ворнинг

(node:45421) ExperimentalWarning: CommonJS module /opt/homebrew/lib/node_modules/npm/node_modules/debug/src/node.js is loading ES Module /opt/homebrew/lib/node_modules/npm/node_modules/supports-color/index.js using require().
Support for loading ES Module in require() is an experimental feature and might change at any time
(Use node --trace-warnings ... to show where the warning was created)

Я мимо пройти не мог и решил разобраться. Первопричина понятна — node 23 включил экспериментальную поддержку синхронного require() для ESM-модулей. Зачем нужен ворнинг? Потому что поддержка неполноценная и если прилетит ESM c top level await то всё полетит к чертям (и это очень опасный момент с которым пока непонятно как жить).

Ладно, ясно-понятно, экспериментальная версия node.js споткнулась. Завтра починят. Вроде бы ничего такого. Получается, Никита не прав, у нас всё относительно хорошо? Ну, не совсем.

Интересен другой момент — почему это случилось на миноре npm и как оно работает в обычной node без реквайра? А разгадка простая:

Во-первых supports-color апнули на мажор. Это модуль от Синдре. Ну вы понимаете. Синдре опять переписал всё на pure ESM

Второй момент, как же оно работает сейчас? А никак не работает. Там внутри в debug/src/node.js — try catch

try {
   require('supports-color')
}  catch (error) {
        // Swallow - we only care if `supports-color` is available; it doesn't have to be.
}

И вот это уже печально. Апнули на сломанную версию, ошибок нет (они заглушены).

https://github.com/npm/cli/issues/7857

Алло, москвичи и рядом! 14 декабря пройдёт ночь опенсорс библиотек, в которой будет участвовать в том числе и моя команда. Событие как минимум необычное.

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

Заметил, что многие пропустили появление satisfies в TS 4.9, а штука-то классная.
Объясняю на пальцах. Иногда нам нужно убедиться, что объект соответствует какому-то типу, но при этом нужно сохранить специфичность типа.

type TestType = {a: number | string; b?: string};

const testObject = {a: 1} as TestType;

testObject.a.toFixed(); // Ошибка: Property 'toFixed' does not exist on type 'string'.

Используем satisfies

type TestType = {a: number | string; b?: string};

const testObject = {a: 1} satisfies TestType;

testObject.a.toFixed();  // Никаких ошибок

testObject.b?.toUpperCase(); // Ошибка: Property 'b' does not exist on type '{ a: number; }'