Как стать автором
Обновить
0
0

Пользователь

Отправить сообщение
Почему такой флаг до сих пор не введён — неясно.

npm install --ignore-scripts


Как подобные проблемы решаются в других языках, в частности, в Ruby и Python?

Насколько я знаю — да никак. Мир не идеален, дерьмо случается, но в данном случае не так уж часто. Честно говоря и ни разу не столкнулся с вредоносным модулем на практике, хотя уже лет 5 как использую npm. Повышенное внимание к npm в этом контексте обусловленно в первую очередь, его популярностью. Тем не меннее, считаю что автор предложил неплохое решение.

Статья в двух словах:


Ей, вы там, js разработчики, да, я не спец в этом вашем js, но слушайте меня, я вам сейчас поставлю диагноз!

И не лень же людям столько текста писать!

Костыль и велосипед!

Да уж, еще один инструмент который стал не актуален (с релизом новой версии webpack) быстрее чем о нем перевели статью на хабре)

Всем кто вбрасывает нечто подобное кидаю эту ссылку — https://geektimes.ru/post/259096/

Ждем статей про обьекты в PHP на примере отношений Гитлера и Муссолини!

разработчиков внешних приложений к БД

Не обратил внимание, да, это про меня

Не смотря на то что я разработчик мне этот функционал обычно вообще не нужен, мне бы просто в пару кликов смотреть\редактировать содержимое и структуру таблиц. Не могу ничего сказать по поводу удобства встроенного редактора, итд так как редко им пользуюсь.

Postico весьма удобный клиент под мак. Бесплатная версия довольно обрезанная.

На правах изврата:


const win = ({ my, others }) => my > others
const firstResult = scores.findIndex(win)
const secondResult = firstResult + 1 + scores.slice(firstResult + 1).findIndex(win)

В реальном проекте я бы конечно использовал первый или второй вариант.

Ну, это просто значит что понятие «архитектура БД» для Вас мало что значит.

Ничего себе вывод. А как это получилось из того что я плохо помню синтаксис SQL? Я уж молчу что понятие «архитектура БД» включает в себя не только реляционные БД.


ORM решения универсальны, но не оптимальны, годятся только для проектов где производительность (по каким-то причинам) не важна вообще.

От 90% запросов в обычном проекте (где производительность вообще-то важна) будут одинаковыми по производительности (да и вообще различия будут чисто синтаксические) если их писать руками или с помощью ORM. Для остальных я знаю чего мне нужно добиться и пишу SQL если приходится. Вот тут то и приходится гуглить. И кстати, не считаю что это «Грязный костыль», даже в кавычках (при условии что не нарушена инкапсуляция итд).

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

Интересный опыт, как насчет опубликовать это как npm пакет?

Серьезно? Вот это лучше промисов?
Буду этим джунов пугать!

Огромное спасибо за ссылку, после Perl'овых тестовых фреймворков не покидало ощущение ушербности тестовых инстрементариев других языков, а вот это похоже то что надо!

Те самые пребилды выкачиваются обычно через lifecycle scripts. Можно конечно надеятся что они сложат их в node_modules, но как по мне — очень не надежно.
Примеры: ngrok, phantomjs, electron
А вот пример аддона для ноды, который нужно скомпилить при установке: node-proxy
Конечно, я согласен что стоит по возможности обходится без использования lifecycle scripts где это возможно, но они присутствуют в любом пакетном менеджере вплоть до apt. А вот действиительно плохой практикой является нарушение инкапсуляции работы пакетного менеджера.
Если ее не нарушать — все равно в какие папки и в сколько копий он кладет модули и выкачивает зависимости.
По поводу разрешения конфликтов я не понял. Т.е все равно, нужно хранить в актуальном виде package.json и npm-shrinkwrap.json, что осложеннно тем, что обычно при таком подходе они не используются, НО, если возник конфликт — все что до этого так берегли полетит в топку, и именно они будут определять что в итоге окажеться закоммичено с node_modules в репозитории?

Это очень плохо. Правда.


  • Не все зависимости могут быть перенесены простым копированием папки node_modules, так как многие написаны например на С++, и требуют сборки. При этом, у разных разработчиков может быть не совместимое по ABI окружение или просто разные ОС.
  • Многие пакеты при установке требуют выполнения lifecycle scripts про которые упоминается в статье. Естественно при копировании node_modules они не будут выполненны.
  • package.json больше не является источником информации о действительно нужных зависимостях, все решает содержимое папки
  • Учитывая все вышеперечисленное, а текже применяемую в npm методику дедупликации пакетов (когда вместо копирования одного и тогоже пакета, который является не прямой зависимостью он ложится в корень node_modules один раз) разрешение конфликтов в случае когда в одной версии модуль a удален, в другой модуль b обновлен или перемещен будет весьма веселым занятием
  • Уже упомянутое распухание репозитория

Все вышеперечисленное актуально не только для ноды, проблема стара как мир, и правильным перешением является lock-файл.

Пример который по середине, только по людски:


Promise.all(urls.map(url => fetch(url)))
.then(texts => console.log(texts.join('')))

Вобщем, не пытайтесь придумать велосипед, учите лучше современный javascript, все уже за вас придумали.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность