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

Комментарии 21

НЛО прилетело и опубликовало эту надпись здесь
Я очень сильно на это надеюсь но в отношении нового установщика, а не самого списка вендоров. А то существующий невероятно упорот со своими рекурсивными зависимостями, когда вендор ставится внутрь вендора, который ставится внутрь вендора и так до бесконечности до тех пор, пока длина пути превысит возможности файловой системы так, что потом эту папку невозможно удалить (вылетает соответствующая ошибка — длина пути велика и не поддерживается ФС).

Если по-хорошему — имена пакетов стоит переделать на вид "юзер/название" — это показало себя с хорошей стороны в composer (php), что позволит исключить всем известную проблему с kik. Зависимости стоит ставить в одну единственную папку с путями вида: "node_modules/username/package/{version}/..." — подобный способ показал себя с хорошей стороны в бандлере (ruby) и исключает рекурсию в зависимостях.
Как такой пакет с версией подключается в коде?
В случае бандлера — есть некоторый конфиг, генерируемый после установки, который знает о версии, которая требуется для нужного пакета и обычный require('some') должен подключать именно её, а для другой зависимости свою версию. В случае языков с наличием модулей и манки-патчингом такие операции не представляют сложностей.
Зря снимаете :) Случаев, когда версия модуля-зависимости не совпадает и потому ставится не в корень, а в node_modules модуля, объявившего зависимость — может оказаться субъективно больше (на моем проекте это так, например).
Кроме того, я в упор не понимаю, как оно решает, какую версию поставить в корень, похоже оно туда тащит первую попавшуюся в списке зависимостей.
Мдэ. Я ещё не успел ничего проверить и порадоваться как всё стало замечательно, а тут уже такой облом :)
НЛО прилетело и опубликовало эту надпись здесь
Мои студенты не дадут соврать, я 3 недели назад на лекции в КПИ рассказывал, что NPM имеет много проблем, а 99% модулей — полоный треш, ничего не тестируется на совместимость, и что нам нужен новый менеджер пакетов в ноде с новой стратегией, ибо так не может быть дальше.
Как минимум стоит автоматически прогонять все публикуемые модули через модульные тесты и требовать 90% покрытия.
И тестировать модули нужно группами, они же часто формируют технологические стеки, и что ломается, так это совместимость модуля в стеке, потому, что его автор не формировал стек, а его модуль взяли в стек, о чем он даже не задумывается. И такой стек должен тестироваться целиком (много модулей), перед выкладыванием в репозиторий каждого модуля, в него входящего.
А почему бы им (ну, и вам) не взять, repository manager? Artifactory какой-нибудь? Это решает проблему и не требует пере-изобретать велосипед. Потому что "скачайте наш uber-jar" мы проходили 12 лет назад и благополучно забыли как страшный сон.
Ха, а когда я оправдывал такой подход (предполагая такую ситуацию) меня заминусовали ;)
https://habrahabr.ru/post/268871/
Потому что "скачайте наш uber-jar" мы проходили 12 лет назад и благополучно забыли как страшный сон.
А есть ли ссылка? А то утверждение выглядит несколько голословным:
По сути данный подход несколько противоречит идеям NPM, ведь опция bundledDependencies была придумана для того, чтобы включать в архив те зависимости, которые не опубликованы в реестре NPM
ESLint выпустили патч v2.5.3 в котором отказались от bundledDependencies из-за появившихся проблем github.com/eslint/eslint/issues/5687.
Ого, интересный поворот :)
Я всегда утверждал, что нужно бороться с количеством зависимостей. Ни в коем случае нельзя допускать "двух-килобайтные" зависимости. Да и, если используешь не всю мощь пакета, со временем надо щипать необходимый код зависимости и вставлять в свой, со своими тестами.
Ни раз меня ругали за это. А потом удивляются, как так получается, что сайт работает на expressjs, а в папке node_modules поиском можно найти три разные версии connect.
На сегодняшний момент ~10% кода вручную копирую из старых проектов в свежесозданные. По крайней мере, за пару лет, я переписал все middleware (и еще некоторые модули), которые использую в разработке и продакшене. Что я там только не находил, left-pad — это еще цветочки! В каком-то из пакетов видел реализацию урезанной версии util.inspect().
По началу было тяжело, приходилось самому следить за обновлениями зависимостей и внедрять их вручную. Но, чем дольше живет npm-пакет, тем реже в него вносятся обновления (да и сами обновления все меньше и меньше). Последние пол года уже за ними не слежу. Все костыли, которые вносят в старые пакеты, к моему коду уже почти отношения не имеют.
Единственное, в одном я упростил себе задачу — не заморачиваюсь с кроссплатформенностью. Так уж получилось, что работаю и развертываю код на Linux, мне не важно как код работает в Windows или в браузере.
НЛО прилетело и опубликовало эту надпись здесь
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.