А теперь представьте такое будущее — у парня с окраины не хватает денег на брендовые цифровые кроссовки, он скачивает себе виртуальный ТЦ «Садовод» и там покупает контрафактные цифровые кроссовки, которые ничем не хуже оригинальных, зато в 5 раз дешевле
Рискну нарваться на критику.
Я тоже большой фанат NestJS. И PostgresQL. Выскажу непопулярную мысль — транзакции на сервере приложений не нужны. Я думаю, отчасти поэтому разработчики NestJS не сильно заморачивались над тем, чтобы сделать их удобными. Транзакции должны быть на сервере баз данных, а с сервера приложений они должны запускаться одним запросом, который триггерит все сайд-эффекты.
нпм инсталл занимает десятки секунд-и с этим сложно что-то сделать
Yarn 2 Berry уже сделали с этим что-то. PnP называется, почитайте. Выглядит довольно дико на первый взгляд, с непривычки. Но я уже пользуюсь этим и доволен как слон — зависимости хранятся прямо в репе, никакого npm install при деплое.
Но зачем мне создавать и публиковать заново то, что уже сделал кто-то за меня?
Если я так буду распыляться, то я проекты буду делать раза в два дольше, а если каждый так делать будет, то в NPM будут тысячи одинаковых библиотек от разных разработчиков.
У NPM и так есть эта проблема, только в гораздо меньшем масштабе. Зачем раздувать её ещё сильнее?
Всегда приходится чем-то жертвовать ради чего-то. В данном случае разработчики пожертвовали стабильностью ради того, что бы сэкономить 3-4 часа жизни, а то и все 8. И это только ради одной библиотеки is-promise. А вообще подобных мелких библиотек множество, и каждый день разработчики устанавливают разные мелкие библиотеки, экономя время до выхода на рынок. И то, что в одном из миллиона случаев это привело к краху, причём совершенно не критичному, не значит, что надо отказываться от этого подхода и срочно всем клепать по своей собственной библиотеке с блэкджеком.
Прикол в том, что на деле-то ничего страшного не произошло. Да, масштабно, по всему миру прокатилось, но никаких последствий от этого не было. А раздули будто бы банковскую систему положили на несколько недель.
Пожалуйста, ради любви ко всему, что представляет собой программирование, самостоятельно напишите проклятые базовые функции
Уважаемый Девид Хейни по-моему слишком много на себя берёт. Он говорит так, будто бы единственная проблема, которую решает установка сторонних модулей — это нежелание написать простой код. А помимо этого модули также решают как минимум проблему поддержки и повторного использования кода. Ну вот нужна мне функция isPromise. Причём нужна мне она в паре десятков проектов. Мне что, в каждом из них создавать, простигосподи, папку utils? И из проекта в проект копипастить эту одну строчку кода? Конечно нет. Да я как только поймаю себя на мысли о том, что я собираюсь создать папку utils, тут же либо полезу искать готовый npm модуль, либо, если не найду его, создам его сам и опубликую в npm, что бы во следующем проекте установить его же. Это нормальный эволюционный путь.
А Девид Хейни, вроде взрослый человек, ведущий инженер StackOverflow, а как ребёнок рассуждает.
Вы не можете (и не должны) знать, во что ваш код превращается внутри движка JavaScript. Движков, как минимум, несколько, они между собой конкурируют производительностью и микрооптимизациями, и каждая новая версия оптимизирует один и тот же код по-разному. В настоящее время методы .reduce, .filter, .map могут работать быстрее ванильного цикла for, хотя, казалось бы, вызывая три этих метода, мы запускаем три цикла. Но движок преобразовывает его в один.
Вы должны просто писать чистый и понятный код, а оптимизацию предоставить интерпретатору.
Вот бы вы ещё когда-нибудь типизацию в Angular шаблонах починили. Постоянно отваливается и превращается в any. Во вложенных конструкциях RxJS такая же проблема.
В примере с browserRedirect вам необходимо убедить жертву использовать ваш middleware. Дело нехитрое.
Но вот как сделать npm бэкдор, который будет работать просто по факту require?
У меня к вам серьёзный фича-реквест.
Подход monorepo уже набрал свою критическую массу, не позволяющую его игнорировать. Сделайте удобную работу с монорепами в проекте, пожалуйста. А то просто открывать проект с проектами немного не удобно :)
Как человек, поработавший 2 года с проектом на Sails.js, я вас умоляю: никогда не пытайтесь использовать этот горе-фреймворк в своих проектах, тем более рекомендовать его другим :) Про адонис сказать ничего не могу — не работал, да и не собираюсь.
Кстати, для ноды сейчас назревает действительно универсальный и очень хороший фреймворк — NestJS.
А какая выборка у этого статистического вывода? Мне вот, например, понравился.
Я тоже большой фанат NestJS. И PostgresQL. Выскажу непопулярную мысль — транзакции на сервере приложений не нужны. Я думаю, отчасти поэтому разработчики NestJS не сильно заморачивались над тем, чтобы сделать их удобными. Транзакции должны быть на сервере баз данных, а с сервера приложений они должны запускаться одним запросом, который триггерит все сайд-эффекты.
А что происходит после того, как сайт был определён как вредоносный?
Yarn 2 Berry уже сделали с этим что-то. PnP называется, почитайте. Выглядит довольно дико на первый взгляд, с непривычки. Но я уже пользуюсь этим и доволен как слон — зависимости хранятся прямо в репе, никакого npm install при деплое.
Если я так буду распыляться, то я проекты буду делать раза в два дольше, а если каждый так делать будет, то в NPM будут тысячи одинаковых библиотек от разных разработчиков.
У NPM и так есть эта проблема, только в гораздо меньшем масштабе. Зачем раздувать её ещё сильнее?
Всегда приходится чем-то жертвовать ради чего-то. В данном случае разработчики пожертвовали стабильностью ради того, что бы сэкономить 3-4 часа жизни, а то и все 8. И это только ради одной библиотеки is-promise. А вообще подобных мелких библиотек множество, и каждый день разработчики устанавливают разные мелкие библиотеки, экономя время до выхода на рынок. И то, что в одном из миллиона случаев это привело к краху, причём совершенно не критичному, не значит, что надо отказываться от этого подхода и срочно всем клепать по своей собственной библиотеке с блэкджеком.
Прикол в том, что на деле-то ничего страшного не произошло. Да, масштабно, по всему миру прокатилось, но никаких последствий от этого не было. А раздули будто бы банковскую систему положили на несколько недель.
Уважаемый Девид Хейни по-моему слишком много на себя берёт. Он говорит так, будто бы единственная проблема, которую решает установка сторонних модулей — это нежелание написать простой код. А помимо этого модули также решают как минимум проблему поддержки и повторного использования кода. Ну вот нужна мне функция isPromise. Причём нужна мне она в паре десятков проектов. Мне что, в каждом из них создавать, простигосподи, папку utils? И из проекта в проект копипастить эту одну строчку кода? Конечно нет. Да я как только поймаю себя на мысли о том, что я собираюсь создать папку utils, тут же либо полезу искать готовый npm модуль, либо, если не найду его, создам его сам и опубликую в npm, что бы во следующем проекте установить его же. Это нормальный эволюционный путь.
А Девид Хейни, вроде взрослый человек, ведущий инженер StackOverflow, а как ребёнок рассуждает.
Вы должны просто писать чистый и понятный код, а оптимизацию предоставить интерпретатору.
Но вот как сделать npm бэкдор, который будет работать просто по факту require?
Подход monorepo уже набрал свою критическую массу, не позволяющую его игнорировать. Сделайте удобную работу с монорепами в проекте, пожалуйста. А то просто открывать проект с проектами немного не удобно :)
Кстати, для ноды сейчас назревает действительно универсальный и очень хороший фреймворк — NestJS.