#такое дня

Когда-то давным давно, во времена первых браузеров и изобретения JavaScript, кто-то подумал, что было бы неплохо получать доступ к элементам в глобальном пространстве имён. Речь идёт в том числе об атрибуте name для ссылок.

Вам все знакомы якоря вида #cheatsheet в адресной строке браузера. Да-да, хештеги не взялись из ниоткуда.

Так вот, пока браузеры пытались договориться (не пытались), что же должно быть индикатором доступа, name или id, вышло так, что IE сделал элементы с id свойствами не только объекта document, но и объекта window. А остальные, естественно, скопировали.

Что это значит? А то, что если вы добавили id элементу, то этот стал доступен как переменная в глобальном пространстве ваших скриптов. Без объявления! Буквально вот так: https://codepen.io/alinaki/pen/zYLJVZN

Если кому интересно подробнее почитать, что куда и как попадает, спецификация ответит на этот вопрос: https://html.spec.whatwg.org/multipage/dom.html#dom-tree-accessors

Но если коротко: не надо это использовать если вы не на хакатоне. Приведёт к таким спагетти, что мало не покажется.

А вот знать надо.

#js #dom #node

#инструмент дня

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

Если кто общался со мной в чате, знает: первая рекомендация для работы — это Node Version Manager, nvm.

Зачем управлять версиями ноды? Oh, sweet summer child...

Ну, как минимум, проекты не всегда переводят на поддержку самых последних версий, даже всеми любимые фронтенд-утилиты. Да и legacy strikes back.

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

И тут на сцену выходит Volta: https://volta.sh/

Написана на Rust, быстро инициализируется, позволяет задать нужную ноду прямо в package.json! В итоге переключился на новый проект — и у тебя уже другая версия Node.js

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

#js #node #nvm #volta

#инструмент дня

С места в карьер: утилита qnm предназначена для поиска установленных пакетов в node_modules. Зачем?

Ну, как минимум, это офигенно быстрый способ просмотреть версии всех установленных лично и не очень лично модулей: https://github.com/ranyitz/qnm

Почему ремарка про "не очень лично"? Потому что какой-либо пакет может запросто тянуть за собой более старую или более новую версию некой утилиты, на которую вы так сильно опирались.

Почему-то меня в этом отношении очень раздражает emotion. Его тащат просто куда ни попадя, а у людей потом на CSS-in-JS аллергия...

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

Моя рекомендация!

#npm #node #package

#такое дня

Когда-то давным давно, во времена первых браузеров и изобретения JavaScript, кто-то подумал, что было бы неплохо получать доступ к элементам в глобальном пространстве имён. Речь идёт в том числе об атрибуте name для ссылок.

Вам все знакомы якоря вида #cheatsheet в адресной строке браузера. Да-да, хештеги не взялись из ниоткуда.

Так вот, пока браузеры пытались договориться (не пытались), что же должно быть индикатором доступа, name или id, вышло так, что IE сделал элементы с id свойствами не только объекта document, но и объекта window. А остальные, естественно, скопировали.

Что это значит? А то, что если вы добавили id элементу, то этот самый элемент стал доступен как переменная в глобальном пространстве ваших скриптов. Без объявления! Буквально вот так: https://codepen.io/alinaki/pen/zYLJVZN

Если кому интересно подробнее почитать, что куда и как попадает, спецификация ответит на этот вопрос: https://html.spec.whatwg.org/multipage/dom.html#dom-tree-accessors

Но если коротко: не надо это использовать если вы не на хакатоне. Приведёт к таким спагетти, что мало не покажется.

А вот знать надо.

#js #dom #node #бородач

#инструмент дня

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

Если кто общался со мной в чате, знает: первая рекомендация для работы — это Node Version Manager, nvm.

Зачем управлять версиями ноды? Oh, sweet summer child...

Ну, как минимум, проекты не всегда переводят на поддержку самых последних версий, даже всеми любимые фронтенд-утилиты. Да и legacy strikes back.

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

И тут на сцену выходит Volta: https://volta.sh/

Написана на Rust, быстро инициализируется, позволяет задать нужную ноду прямо в package.json! В итоге переключился на новый проект — и у тебя уже другая версия Node.js

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

#js #node #nvm #volta #бородач

#инструмент дня

С места в карьер: утилита qnm предназначена для поиска установленных пакетов в node_modules. Зачем?

Ну, как минимум, это офигенно быстрый способ просмотреть версии всех установленных лично и не очень лично модулей: https://github.com/ranyitz/qnm

Почему ремарка про "не очень лично"? Потому что какой-либо пакет может запросто тянуть за собой более старую или более новую версию некой утилиты, на которую вы так сильно опирались.

Почему-то меня в этом отношении очень раздражает emotion. Его тащат просто куда ни попадя, а у людей потом на CSS-in-JS аллергия...

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

Моя рекомендация!

#npm #node #package #бородач

#инструмент дня

И снова на связи Глеб, автор extended-fetch. Слово автору.

Недавно потребовалось проанализировать зависимости в проекте (была проблема с транзитивными) и искал удобный инструмент для визуализации дерева зависимостей.

В итоге нашел https://npmgraph.js.org/

Что дает инструмент:

- анализ пакета из репозитория npm
- анализ package.json
- отображение интерактивного графа зависимостей (самое вкусное)
- выделение цветом заивисимостей по степени актуальности / по типу модуля (esm/cjs) / по числу мэйнтейнеров
- для выбранного модуля доступен детальный отчет по клику (на скриншоте пример)

Всем деревьев зависимостей, котаны!

Напоминаю, что кто угодно может выкатить пост на канал, если есть чем поделиться. Не стесняйтесь!

#node #dependencies

#релиз дня

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

Итак, встречайте: Bun 1.1. Теперь со вкусом Windows!

Для тех, кто пропустил последний год: Bun — это среда выполнения JavaScript, аналогичная Node.js и решающая в целом те же задачи, но построенная вокруг JavaScript-движка JSC aka JavaScript Core.

Напомню, что JSC используется в браузере Safari и в React Native. А это значит, что туда свои силы вкладывают Apple и Facebook. Node.js построен вокруг движка V8, используемого в Google Chrome.

Но дело, конечно, не только в движке. Bun весьма быстрее Node.js и включает в себя не только среду выполнения и оболочку командной строки, но и сборщик, и тесты и пакетный менеджер (npm все же не часть node если что).

Ну просто для сравнения, bun install в 18 раз быстрее pnpm и yarn, и в 30 раз быстрее npm.

К Bun были претензии, что скорость свою они достигли путем срезания углов, многие фреймворки даже принципиально не стали чинить баги, с ним связанные. И не беспочвенно.

Но в версии 1.1 нам пообещали, что множество проблем совместимости с Node.js уже устранено.

И, конечно, главное нововведение: полноценная поддержка Windows! Парни реально последние полгода на это положили.

В общем, смотрим видео о выпуске, там много всего: https://youtu.be/yXTFOeGly9o?si=F4tr_R8X8ec0_BXx

Ну и по факту это значит, что теперь смело можно рассчитывать, что написав скрипт для Bun в Linux, он прекрасно запустится в macOS и Windows и работать будет одинаково.

В общем, когда переходим, котаны? А кто уже?

#bun #node #jsc

#инструмент дня

С места в карьер: утилита qnm предназначена для поиска установленных пакетов в node_modules. Зачем?

Ну, как минимум, это офигенно быстрый способ просмотреть версии всех установленных лично и не очень лично модулей: https://github.com/ranyitz/qnm

Почему ремарка про "не очень лично"? Потому что какой-либо пакет может запросто тянуть за собой более старую или более новую версию некой утилиты, на которую вы так сильно опирались.

Почему-то меня в этом отношении очень раздражает emotion. Его тащат просто куда ни попадя, а у людей потом на CSS-in-JS аллергия...

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

Моя рекомендация!

#npm #node #package #бородач

#инструмент дня

С места в карьер: утилита qnm предназначена для поиска установленных пакетов в node_modules. Зачем?

Ну, как минимум, это офигенно быстрый способ просмотреть версии всех установленных лично и не очень лично модулей: https://github.com/ranyitz/qnm

Почему ремарка про "не очень лично"? Потому что какой-либо пакет может запросто тянуть за собой более старую или более новую версию некой утилиты, на которую вы так сильно опирались.

Почему-то меня в этом отношении очень раздражает emotion. Его тащат просто куда ни попадя, а у людей потом на CSS-in-JS аллергия...

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

Моя рекомендация!

#npm #node #package #бородач

#новость дня

В node.js появилась экспериментальная нативная поддержка TypeScript!

Крепко же их bun приложил...

Ссылка на PR: https://github.com/nodejs/node/pull/53725

По факту происходит отбрасывание типов, поэтому средства вроде Enum и namespace не поддерживаются. Инициатива предоставления стабильного API поверх TypeScript получила название amaro и в дальнейшем планируется выделение в отдельный обновляемый модуль. Работает (кто бы сомневался) при помощи swc, собранного в WebAssembly!

Так что никаких больше ts-node!

node main.ts

...и поехали!

#node #typescript #ts

#инструмент дня

Volta? nvm? asdf? fnm? n?

Вы же поняли? Да, это всё менеджеры версий node.js.

Ладно-ладно, asdf чуть шире штука.

И хорошо, если нестабильные версии ноды ставишь только ради проверки фишек...

Так вот, к чему это я?

А к тому, что наш любимый pnpm с версии 10.14 тоже стал таким менеджером!

Подробнее: https://pnpm.io/blog/releases/10.14

{
  "devEngines": {
    "runtime": {
      "name": "node",
      "version": "^24.4.0",
      "onFail": "download" // we only support the "download" value for now
    }
  }
}

Поддерживаются Node.js, Deno, и Bun.

За что мы так любим pnpm? За воркспейсы в том числе. Так вот, теперь в разных воркспейсах могут быть и разные версии ноды!

Круто? Не то слово :)

#pnpm #nvm #volta #node #bun

#ссылка дня

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

С Bun 1.3 можно сёрвить HTML-файлы напрямую, а JavaScript, TypeScript, JSX и CSS обрабатываются автоматически. Горячая перезагрузка позволяет видеть изменения мгновенно, а для проектов на React достаточно bun init --react, чтобы получить готовую среду. Сборка для продакшн стала проще: bun build --production оптимизирует проект без лишних конфигов.

Внутри появились новые возможности: поддержка MySQL наряду с PostgreSQL и SQLite, встроенный Redis-клиент, улучшенная маршрутизация, WebSocket, работа с cookies и новые механизмы изолированных установок пакетов. Всё это делает Bun 1.3 полноценной средой, где фронтенд, бэкенд и сборка объединены в одном инструменте.

Теперь Bun действительно бандлит, простите

https://bun.com/blog/bun-v1.3

#bun #node #bundle #webpack

#инструмент дня

Появился Nub — новый «всё-в-одном» тулкит для JavaScript. Название, конечно, опасное: любой пост про него автоматически звучит как обращение к аудитории.

GitHub: https://github.com/nubjs/nub
Site: https://nubjs.com/

Кто уже догадался, откуда у названия ноги растут?

Да, оттуда.

Но есть нюанс: Nub не пытается заменить Node.js.

Смысл такой: дать разработчику всё приятное, что люди обычно хвалят в Bun — быстрый запуск, TypeScript из коробки, меньше зоопарка CLI, — но оставить выполнение кода на старом добром Node.js.

Nub — это один Rust-бинарник поверх обычного Node.js. Он умеет:

— запускать TypeScript/TSX/JSX без отдельного build step
— автоматически подхватывать tsconfig paths
— грузить .env
— импортировать YAML/TOML/JSONC/JSON5
— работать как быстрый runner для package.json scripts
— заменять npx/pnpm exec
— ставить зависимости
— управлять версиями Node
— делать watch mode

То есть вместо набора из tsx, ts-node, dotenv, tsconfig-paths, nvm, pnpm run, npx и пары заклинаний из README вашего монорепо — один nub.

Главный selling point не «мы быстрее всех, потому что переписали мир на Zig, потом по-ковбойски переписали его на Rust с помощью ИИ, а теперь давайте все сделаем вид, что это нормальный жизненный цикл инфраструктурного рантайма».

Код в итоге выполняет обычный Node.js. Nub просто добавляет слой удобства: транспиляцию через oxc, хуки резолвинга, полифиллы и быстрые команды вокруг проекта.

На сайте, конечно, бенчмарки красивые:

nub run — сильно быстрее npm run / pnpm run
nubx — сильно быстрее npx
nub install — быстрее pnpm и, по их тестам, даже чуть быстрее bun install
nub index.ts — примерно как обычный node по старту и быстрее tsx

Плюс отдельно упирают в supply-chain безопасность: build scripts по умолчанию не запускаются, свежие подозрительные релизы можно придерживать, вредоносные пакеты проверяются через OSV.

Выглядит как очень понятная реакция на последние годы JS tooling: всем понравилось, что Bun быстрый и удобный, но не всем хочется тащить в прод ещё один почти-Node, который иногда внезапно оказывается «почти», а потом ещё и внезапно оказывается почти переписанным.

Nub говорит: а давайте оставим Node, но перестанем страдать от того, что вокруг него исторически вырос целый огород одноразовых CLI.

Пока штука свежая, я бы не тащил её сразу в критичный CI без проверки, но для внутренних тулов, dev-скриптов и монореп — очень интересно.

#node #bun #typescript #oxc #rust