#тред дня
Задержался с постом, релизил обновление продукта. Ух у юзеров будет бомбить, изменение уровня ribbon в MS Office.
Да, почти никакого автопостинга, с пылу с жару, цените, мои дорогие 😙
Итак, тут Андрей Ситник в очередной раз поднял тему безопасности npm-пакетов. Думаю, нелишним будет и тут сохранить. Далее слово автору с незначительной редактурой:
Угон пакета и вставка вредоносного кода — риски большинства пакетных менеджеров.
В npm при деплое можно снизить риски и ускорить деплой:
Использование
Но так даже лучше — при обновлении зависимостей сразу понятны риски (обновления devDependencies менее опасно).
TS и файлы типов не нужны для компиляции .ts в .js — swc и babel умеют отрезать типы.
Поэтому и для фронтенд-проекта и для nodejs-сервиса tsc и типы должны быть в devDependencies.
Проверка типов должна идти как тесты в отдельном задании.
Для nodejs-сервиса в dependencies записываются только те зависимости, что нужны для запуска сервера (а не его компиляции).
Отдельным заданием ставятся все зависимости и собирается JS-файлы. А внутри docker-образа сервиса установка только с
#npm #yarn #pnpm #node #security
Задержался с постом, релизил обновление продукта. Ух у юзеров будет бомбить, изменение уровня ribbon в MS Office.
Да, почти никакого автопостинга, с пылу с жару, цените, мои дорогие 😙
Итак, тут Андрей Ситник в очередной раз поднял тему безопасности npm-пакетов. Думаю, нелишним будет и тут сохранить. Далее слово автору с незначительной редактурой:
Угон пакета и вставка вредоносного кода — риски большинства пакетных менеджеров.
В npm при деплое можно снизить риски и ускорить деплой:
npm install --production --ignore-scripts
--production
не будет ставить devDependencies, --ignore-scripts
выключит postinstall-скрипты.Использование
--production
при деплое, значит что вам более системно надо разделять dependencies (только что нужно для сборки) и devDependencies (всё остальное).Но так даже лучше — при обновлении зависимостей сразу понятны риски (обновления devDependencies менее опасно).
TS и файлы типов не нужны для компиляции .ts в .js — swc и babel умеют отрезать типы.
Поэтому и для фронтенд-проекта и для nodejs-сервиса tsc и типы должны быть в devDependencies.
Проверка типов должна идти как тесты в отдельном задании.
Для nodejs-сервиса в dependencies записываются только те зависимости, что нужны для запуска сервера (а не его компиляции).
Отдельным заданием ставятся все зависимости и собирается JS-файлы. А внутри docker-образа сервиса установка только с
--production
.#npm #yarn #pnpm #node #security
👍7
#заметка дня
Пожалуйста, прекратите засорять глобальное пространство имён утилитами из npm/yarn.
Это я о чём:
Не надо! Даже если документация говорит вам это сделать. Или, ещё хуже, рандомный ютубер или блогер.
Используйте для ваших локальных задач npm-скрипты:
А для глобальных, скорее всего, есть инструменты получше.
Итак, как же работают npm-скрипты?
Если вы зайдёте в каталог node_modules, со всеми пакетами, там будет вложенный каталог .bin. Но вот исполняемых файлов, бинарников, там нет. А есть т. н. символические ссылки, симлинки. А вот уже они указывают на нужный файл в каком-либо конкретном пакете.
Как они узнают, куда указывать? Всё просто: в package.json нужного пакета будет, опять же, секция bin.
Итого, если node run xxx не нашёл скрипта с нужным именем, он полезет за ним в локальное пространство имён. Не найдя приложения в локальном пространстве имён, он полезет в глобальное и запустит приложение.
Почему это полезно?
Да потому что можно держать миллион разных версий gulp/webpack/vite/далее везде и не страдать по этому поводу. Работать будет всегда и везде. А если сюда приплюсовать nvm… Но об этом потом.
Кому интересны подробности, вот вам баззворд для лучшего понимания проблемы: PATH.
Задавайте ваши ответы, котаны.
P. S. inb4 npx
#js #node #run
Пожалуйста, прекратите засорять глобальное пространство имён утилитами из npm/yarn.
Это я о чём:
$ npm i -g gulp
…bla-bla-bla
$ gulp
Не надо! Даже если документация говорит вам это сделать. Или, ещё хуже, рандомный ютубер или блогер.
Используйте для ваших локальных задач npm-скрипты:
$ npm i gulp
…create your scripts
$ npm run gulp
А для глобальных, скорее всего, есть инструменты получше.
Итак, как же работают npm-скрипты?
Если вы зайдёте в каталог node_modules, со всеми пакетами, там будет вложенный каталог .bin. Но вот исполняемых файлов, бинарников, там нет. А есть т. н. символические ссылки, симлинки. А вот уже они указывают на нужный файл в каком-либо конкретном пакете.
Как они узнают, куда указывать? Всё просто: в package.json нужного пакета будет, опять же, секция bin.
Итого, если node run xxx не нашёл скрипта с нужным именем, он полезет за ним в локальное пространство имён. Не найдя приложения в локальном пространстве имён, он полезет в глобальное и запустит приложение.
Почему это полезно?
Да потому что можно держать миллион разных версий gulp/webpack/vite/далее везде и не страдать по этому поводу. Работать будет всегда и везде. А если сюда приплюсовать nvm… Но об этом потом.
Кому интересны подробности, вот вам баззворд для лучшего понимания проблемы: PATH.
Задавайте ваши ответы, котаны.
P. S. inb4 npx
#js #node #run
👍15❤1👎1
#фишка дня
Посмотрите на этот код; ничего странного не замечаете?
А здесь происходит ого-го какая драма!
Итак, этот, казалось бы, невинный кусок кода очень даже содержит в себе бэкдор. Посмотрите внимательно на GitHub Gists: https://gist.github.com/bekharsky/fa4c071ce657e37f6d0f3e7f4a91799b
Да, это на скриншоте сложно заметить, но в деструктурировании req.query вторым параметром лежит невидимый символ \u3164. Заполнитель, буквально.
То есть:
Добавляете символ как параметр запроса с командой на выполнение ну и дальше он передаётся в список ниже. А уж там...
Доклад по методу: https://certitude.consulting/blog/en/invisible-backdoor/
Вообще, таких символов очень много (очень рекомендую почитать статью). Не копируйте все подряд из сети себе.
#node #js #security #unicode
Посмотрите на этот код; ничего странного не замечаете?
А здесь происходит ого-го какая драма!
Итак, этот, казалось бы, невинный кусок кода очень даже содержит в себе бэкдор. Посмотрите внимательно на GitHub Gists: https://gist.github.com/bekharsky/fa4c071ce657e37f6d0f3e7f4a91799b
Да, это на скриншоте сложно заметить, но в деструктурировании req.query вторым параметром лежит невидимый символ \u3164. Заполнитель, буквально.
То есть:
const { timeout,\u3164} = req.query;
Добавляете символ как параметр запроса с командой на выполнение ну и дальше он передаётся в список ниже. А уж там...
Доклад по методу: https://certitude.consulting/blog/en/invisible-backdoor/
Вообще, таких символов очень много (очень рекомендую почитать статью). Не копируйте все подряд из сети себе.
#node #js #security #unicode
😱10👍5🔥1
#инструмент дня
WebKit strikes back!
Это было вопросм времени, когда же появится что-то подобное node.js и deno, но на JSC aka JavaScriptCore, а не V8.
JSC это JS-движок от, собственно, WebKit’а. Тогда как V8 — Blink (Chrome).
Помимо браузеров Safari и Epiphany, JSC используется в React Native, кстати.
Итак, новая среда выполнения JS: Bun.
Ссылка: https://bun.sh/
Обещается нативная поддержка TS, JSX, ESM и дикая-дикая скорость. Сама среда при этом написана на языке Zig, что бы это ни значило (его компилятор хавает и плюсы, кажется).
Давайте загибать пальцы, какие же серверные среды JS у нас теперь есть:
- Node.js (V8)
- Deno (V8)
- Bun (JSC)
- Google AppsScript (Rhino/V8)
Что забыл?
#js #ts #bun #node #jsc #v8
WebKit strikes back!
Это было вопросм времени, когда же появится что-то подобное node.js и deno, но на JSC aka JavaScriptCore, а не V8.
JSC это JS-движок от, собственно, WebKit’а. Тогда как V8 — Blink (Chrome).
Помимо браузеров Safari и Epiphany, JSC используется в React Native, кстати.
Итак, новая среда выполнения JS: Bun.
Ссылка: https://bun.sh/
Обещается нативная поддержка TS, JSX, ESM и дикая-дикая скорость. Сама среда при этом написана на языке Zig, что бы это ни значило (его компилятор хавает и плюсы, кажется).
Давайте загибать пальцы, какие же серверные среды JS у нас теперь есть:
- Node.js (V8)
- Deno (V8)
- Bun (JSC)
- Google AppsScript (Rhino/V8)
Что забыл?
#js #ts #bun #node #jsc #v8
👍9🔥3❤1🤩1
#статья дня
npm, Yarn 1, Yarn 2 или pnpm?
Знакомые слова? Если нет, это всё — менеджеры пакетов (библиотек и т. п.) node.js. И каждый из них имеет свои особенности и по поводу каждого из них всегда идут баталии.
На чём запускать новый проект? На что переводить старый? Что быстрее? Что меньше места на диске съест? Что безопаснее?
Итого, сегодня тема — сравнение менеджеров пакетов: https://blog.logrocket.com/javascript-package-managers-compared/
Ну и заодно её перевод на русский язык на Medium.
У нас пока Yarn 1 aka Classic, а что у вас, котаны?
#node #npm #yarn #pnpm
npm, Yarn 1, Yarn 2 или pnpm?
Знакомые слова? Если нет, это всё — менеджеры пакетов (библиотек и т. п.) node.js. И каждый из них имеет свои особенности и по поводу каждого из них всегда идут баталии.
На чём запускать новый проект? На что переводить старый? Что быстрее? Что меньше места на диске съест? Что безопаснее?
Итого, сегодня тема — сравнение менеджеров пакетов: https://blog.logrocket.com/javascript-package-managers-compared/
Ну и заодно её перевод на русский язык на Medium.
У нас пока Yarn 1 aka Classic, а что у вас, котаны?
#node #npm #yarn #pnpm
LogRocket Blog
JavaScript package managers compared: npm, Yarn, or pnpm? - LogRocket Blog
With the spate of popular JavaScript package managers reaching relative feature parity, it's time to compare: npm, Yarn, or pnpm?
👍9👎2
#заметка дня
Пожалуйста, прекратите засорять глобальное пространство имён утилитами из npm/yarn.
Это я о чём:
Не надо! Даже если документация говорит вам это сделать. Или, ещё хуже, рандомный ютубер или блогер.
Используйте для ваших локальных задач npm-скрипты:
А для глобальных, скорее всего, есть инструменты получше.
Итак, как же работают npm-скрипты?
Если вы зайдёте в каталог node_modules, со всеми пакетами, там будет вложенный каталог .bin. Но вот исполняемых файлов, бинарников, там нет. А есть т. н. символические ссылки, симлинки. А вот уже они указывают на нужный файл в каком-либо конкретном пакете.
Как они узнают, куда указывать? Всё просто: в package.json нужного пакета будет, опять же, секция bin.
Итого, если node run xxx не нашёл скрипта с нужным именем, он полезет за ним в локальное пространство имён. Не найдя приложения в локальном пространстве имён, он полезет в глобальное и запустит приложение.
Почему это полезно?
Да потому что можно держать миллион разных версий gulp/webpack/vite/далее везде и не страдать по этому поводу. Работать будет всегда и везде. А если сюда приплюсовать nvm… Но об этом потом.
Кому интересны подробности, вот вам баззворд для лучшего понимания проблемы: PATH.
Задавайте ваши ответы, котаны.
P. S. inb4 npx
#js #node #run
Пожалуйста, прекратите засорять глобальное пространство имён утилитами из npm/yarn.
Это я о чём:
$ npm i -g gulp
…bla-bla-bla
$ gulp
Не надо! Даже если документация говорит вам это сделать. Или, ещё хуже, рандомный ютубер или блогер.
Используйте для ваших локальных задач npm-скрипты:
$ npm i gulp
…create your scripts
$ npm run gulp
А для глобальных, скорее всего, есть инструменты получше.
Итак, как же работают npm-скрипты?
Если вы зайдёте в каталог node_modules, со всеми пакетами, там будет вложенный каталог .bin. Но вот исполняемых файлов, бинарников, там нет. А есть т. н. символические ссылки, симлинки. А вот уже они указывают на нужный файл в каком-либо конкретном пакете.
Как они узнают, куда указывать? Всё просто: в package.json нужного пакета будет, опять же, секция bin.
Итого, если node run xxx не нашёл скрипта с нужным именем, он полезет за ним в локальное пространство имён. Не найдя приложения в локальном пространстве имён, он полезет в глобальное и запустит приложение.
Почему это полезно?
Да потому что можно держать миллион разных версий gulp/webpack/vite/далее везде и не страдать по этому поводу. Работать будет всегда и везде. А если сюда приплюсовать nvm… Но об этом потом.
Кому интересны подробности, вот вам баззворд для лучшего понимания проблемы: PATH.
Задавайте ваши ответы, котаны.
P. S. inb4 npx
#js #node #run
👍13😁1
#новость дня
Наконец-то в каталоге npm появилась возможность посмотреть код пакета! Даже с подсветкой.
Да-да, всегда можно было перейти на гитхаб и посмотреть там. Но зачем лишний клик, когда можно детектить говнокод не отходя от кассы?
Впрочем, к библиотеке на скрине понятие «говнокод» неприменимо 😉
#npm #node
Наконец-то в каталоге npm появилась возможность посмотреть код пакета! Даже с подсветкой.
Да-да, всегда можно было перейти на гитхаб и посмотреть там. Но зачем лишний клик, когда можно детектить говнокод не отходя от кассы?
Впрочем, к библиотеке на скрине понятие «говнокод» неприменимо 😉
#npm #node
❤8👍7🔥2😁1
#такое дня
Когда-то давным давно, во времена первых браузеров и изобретения JavaScript, кто-то подумал, что было бы неплохо получать доступ к элементам в глобальном пространстве имён. Речь идёт в том числе об атрибуте
Вам все знакомы якоря вида #cheatsheet в адресной строке браузера. Да-да, хештеги не взялись из ниоткуда.
Так вот, пока браузеры пытались договориться (не пытались), что же должно быть индикатором доступа,
Что это значит? А то, что если вы добавили id элементу, то этот стал доступен как переменная в глобальном пространстве ваших скриптов. Без объявления! Буквально вот так: https://codepen.io/alinaki/pen/zYLJVZN
Если кому интересно подробнее почитать, что куда и как попадает, спецификация ответит на этот вопрос: https://html.spec.whatwg.org/multipage/dom.html#dom-tree-accessors
Но если коротко: не надо это использовать если вы не на хакатоне. Приведёт к таким спагетти, что мало не покажется.
А вот знать надо.
#js #dom #node
Когда-то давным давно, во времена первых браузеров и изобретения 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
🤯19👍10
#инструмент дня
Я много обещал рассказать о сетапе для разработки веба, но руки не доходили. Так что приходится кусочками 🙂
Если кто общался со мной в чате, знает: первая рекомендация для работы — это 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
Я много обещал рассказать о сетапе для разработки веба, но руки не доходили. Так что приходится кусочками 🙂
Если кто общался со мной в чате, знает: первая рекомендация для работы — это 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
❤14👍7🔥4
#инструмент дня
С места в карьер: утилита 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
👍11
#такое дня
Когда-то давным давно, во времена первых браузеров и изобретения JavaScript, кто-то подумал, что было бы неплохо получать доступ к элементам в глобальном пространстве имён. Речь идёт в том числе об атрибуте
Вам все знакомы якоря вида #cheatsheet в адресной строке браузера. Да-да, хештеги не взялись из ниоткуда.
Так вот, пока браузеры пытались договориться (не пытались), что же должно быть индикатором доступа,
Что это значит? А то, что если вы добавили id элементу, то этот самый элемент стал доступен как переменная в глобальном пространстве ваших скриптов. Без объявления! Буквально вот так: https://codepen.io/alinaki/pen/zYLJVZN
Если кому интересно подробнее почитать, что куда и как попадает, спецификация ответит на этот вопрос: https://html.spec.whatwg.org/multipage/dom.html#dom-tree-accessors
Но если коротко: не надо это использовать если вы не на хакатоне. Приведёт к таким спагетти, что мало не покажется.
А вот знать надо.
#js #dom #node #бородач
Когда-то давным давно, во времена первых браузеров и изобретения 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 #бородач
🤯19👍9❤4
#инструмент дня
Я много обещал рассказать о сетапе для разработки веба, но руки не доходили. Так что приходится кусочками 🙂
Если кто общался со мной в чате, знает: первая рекомендация для работы — это 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 #бородач
Я много обещал рассказать о сетапе для разработки веба, но руки не доходили. Так что приходится кусочками 🙂
Если кто общался со мной в чате, знает: первая рекомендация для работы — это 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 #бородач
❤15
#инструмент дня
С места в карьер: утилита 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 #бородач
👍14❤1
#инструмент дня
И снова на связи Глеб, автор extended-fetch. Слово автору.
Недавно потребовалось проанализировать зависимости в проекте (была проблема с транзитивными) и искал удобный инструмент для визуализации дерева зависимостей.
В итоге нашел https://npmgraph.js.org/
Что дает инструмент:
- анализ пакета из репозитория npm
- анализ package.json
- отображение интерактивного графа зависимостей (самое вкусное)
- выделение цветом заивисимостей по степени актуальности / по типу модуля (esm/cjs) / по числу мэйнтейнеров
- для выбранного модуля доступен детальный отчет по клику (на скриншоте пример)
Всем деревьев зависимостей, котаны!
Напоминаю, что кто угодно может выкатить пост на канал, если есть чем поделиться. Не стесняйтесь!
#node #dependencies
И снова на связи Глеб, автор extended-fetch. Слово автору.
Недавно потребовалось проанализировать зависимости в проекте (была проблема с транзитивными) и искал удобный инструмент для визуализации дерева зависимостей.
В итоге нашел https://npmgraph.js.org/
Что дает инструмент:
- анализ пакета из репозитория npm
- анализ package.json
- отображение интерактивного графа зависимостей (самое вкусное)
- выделение цветом заивисимостей по степени актуальности / по типу модуля (esm/cjs) / по числу мэйнтейнеров
- для выбранного модуля доступен детальный отчет по клику (на скриншоте пример)
Всем деревьев зависимостей, котаны!
Напоминаю, что кто угодно может выкатить пост на канал, если есть чем поделиться. Не стесняйтесь!
#node #dependencies
❤16👍8
#релиз дня
Некоторые проекты так быстро несутся вперед, что за, казалось бы, минорным релизом скрывается целый мир.
Итак, встречайте: 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
Некоторые проекты так быстро несутся вперед, что за, казалось бы, минорным релизом скрывается целый мир.
Итак, встречайте: 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
👍14🤩3❤2
#инструмент дня
С места в карьер: утилита 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 #бородач
👍22❤1
#инструмент дня
С места в карьер: утилита 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 #бородач
👍14
#новость дня
В node.js появилась экспериментальная нативная поддержка TypeScript!
Крепко же их bun приложил...
Ссылка на PR: https://github.com/nodejs/node/pull/53725
По факту происходит отбрасывание типов, поэтому средства вроде Enum и namespace не поддерживаются. Инициатива предоставления стабильного API поверх TypeScript получила название amaro и в дальнейшем планируется выделение в отдельный обновляемый модуль. Работает (кто бы сомневался) при помощи swc, собранного в WebAssembly!
Так что никаких больше
...и поехали!
#node #typescript #ts
В 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
GitHub
module: add --experimental-strip-types by marco-ippolito · Pull Request #53725 · nodejs/node
It is possible to execute TypeScript files by setting the experimental flag --experimental-strip-types.
Node.js will transpile TypeScript source code into JavaScript source code.
During the transpi...
Node.js will transpile TypeScript source code into JavaScript source code.
During the transpi...
❤17🤩3👍1🤬1
#статья дня
Мой товарищ, а по совместительству автор библиотеки extended-fetch, принёс довольно интересную тему для обсуждения.
Fetch API давно стал стандартным способом работы с HTTP-запросами в JavaScript, но его реализация в разных рантаймах может отличаться.
Особенно это заметно, когда речь заходит о поддержке HTTP/2: этот протокол позволяет улучшить производительность за счет мультиплексирования запросов.
Когда пишешь код в браузере, fetch воспринимается как что-то само собой разумеющееся. Он просто работает, поддерживает полный спектр HTTP, и никаких проблем не возникает.
Рассмотрим, как обстоят дела с HTTP/2 в популярных JavaScript-рантаймах: Node.js, Deno и Bun.
Спойлер: речь о поддержке HTTP/2 и экзотическом случае, при котором доступно общение с сервером без фоллбэка на HTTP/1.1.
🦕 Победитель — Deno. Этот рантайм обеспечивает полноценную поддержку HTTP/2 в fetch без дополнительных манипуляций.
🩼 Костыльный победитель — Node.js. Здесь fetch основан на библиотеке undici, которая изначально не поддерживает HTTP/2. Однако, можно воспользоваться самим undici, минуя стандартный fetch, и получить желаемый результат.
🌚 Проигравший — Bun. В этом рантайме более года открыто issue о поддержке HTTP/2, но пока что полноценной реализации нет.
Подытожим
Если вам нужна полноценная поддержка HTTP/2 в fetch, лучший выбор — Deno. В Node.js придется использовать обходные пути, а в Bun — просто подождать, пока разработчики добавят эту функциональность.
В общем, даже стандартные API могут работать по-разному в разных окружениях, поэтому всегда стоит проверять их поддержку перед использованием в продакшене.
Собственно, вот и статья: https://blog.disintegrator.dev/posts/http2-support-in-js-runtimes/
Там есть все примеры кода и клиента, и сервера.
Мнения?
#fetch #node #deno #bun
Мой товарищ, а по совместительству автор библиотеки extended-fetch, принёс довольно интересную тему для обсуждения.
Fetch API давно стал стандартным способом работы с HTTP-запросами в JavaScript, но его реализация в разных рантаймах может отличаться.
Особенно это заметно, когда речь заходит о поддержке HTTP/2: этот протокол позволяет улучшить производительность за счет мультиплексирования запросов.
Когда пишешь код в браузере, fetch воспринимается как что-то само собой разумеющееся. Он просто работает, поддерживает полный спектр HTTP, и никаких проблем не возникает.
Рассмотрим, как обстоят дела с HTTP/2 в популярных JavaScript-рантаймах: Node.js, Deno и Bun.
Спойлер: речь о поддержке HTTP/2 и экзотическом случае, при котором доступно общение с сервером без фоллбэка на HTTP/1.1.
🩼 Костыльный победитель — Node.js. Здесь fetch основан на библиотеке undici, которая изначально не поддерживает HTTP/2. Однако, можно воспользоваться самим undici, минуя стандартный fetch, и получить желаемый результат.
Подытожим
Если вам нужна полноценная поддержка HTTP/2 в fetch, лучший выбор — Deno. В Node.js придется использовать обходные пути, а в Bun — просто подождать, пока разработчики добавят эту функциональность.
В общем, даже стандартные API могут работать по-разному в разных окружениях, поэтому всегда стоит проверять их поддержку перед использованием в продакшене.
Собственно, вот и статья: https://blog.disintegrator.dev/posts/http2-support-in-js-runtimes/
Там есть все примеры кода и клиента, и сервера.
Мнения?
#fetch #node #deno #bun
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤3🤩1
#инструмент дня
Volta? nvm? asdf? fnm? n?
Вы же поняли? Да, это всё менеджеры версий node.js.
Ладно-ладно, asdf чуть шире штука.
И хорошо, если нестабильные версии ноды ставишь только ради проверки фишек...
Так вот, к чему это я?
А к тому, что наш любимый pnpm с версии 10.14 тоже стал таким менеджером!
Подробнее: https://pnpm.io/blog/releases/10.14
Поддерживаются Node.js, Deno, и Bun.
За что мы так любим pnpm? За воркспейсы в том числе. Так вот, теперь в разных воркспейсах могут быть и разные версии ноды!
Круто? Не то слово :)
#pnpm #nvm #volta #node #bun
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
1👍14❤4