#тред дня
Задержался с постом, релизил обновление продукта. Ух у юзеров будет бомбить, изменение уровня 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 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
#инструмент дня
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👍12❤4