Существует тенденция для компаний или индивидумов форкать или пересоздавать OSS проекты, вместо работы над существующими в сообществе. Это случается по многим причинам, но это случается чаще чем нужно. Это объясняет, почему появился Yarn.
Панки живы!
По существу нет ничего плохого в DIY(«сделай это сам» прим. пер.) в OSS. Для разрабтчиков — это хороший способ узнать или показать на что ты способен. Пока у тебя нет фан-клуба, это капля в море.
Но если это делает бизнес, который может выделить ресурсы и таланты для проекта, с нужными связями и маркетингом — это сродни пушечному ядру. И действует исключительно в своих интересах, что может причинить вред OSS сообществу.
Я хочу рассказать почему компания может прийти к такому решению (см. также: фатальный недостаток), и какие от этого могут быть последствия.
Благими намерениями вымощена...
Если случается, что OSS проект X может в некоторых сценариях работать для компании, она попробует его использовать.
Но возможно, что она не достаточно хорошо изучила его, или изменились потребности, или поменялась сфера, или баг X все никак не пофиксят или миллион причин. Вместо сотрудничества, компания берет и пишет свою реализацию.
Разработчики в компании понимают, что дешевле будет сделать все самим. Я знаю это, потому что, сам так делал. И в этом есть какой то смысл.
Бизнес любит и соглашается с идеей, что он «может возвращать» сообществу открыв исходники своего нового проекта! Разработчикам в компании это тоже нравится потому, что они пишут код по своим стандартам и практикам. Они больше не зависят от прихотей и временных рамок кого либо еще.
Более внимательный бизнес, сделает более добросовестное решение и вернет вклад в проект X. Пока код вливается в разумное время, все счастливы. Но если PR висит слишком долго или мейнтейнеры не согласны с решением и отклонили запрос, сотрудничество может закончится.
Что выльется в новый проект Z, который приведет к фрагметации на нескольких уровнях:
- Сообщество. Из-за разделения, некоторые пользователи могут переметнуться к Z. Может Z подходит им больше, или они верят, что Z будет развиваться быстрее, или потому что, оно новое и блестит. Вклад в X может снизиться.
- Усилия. Пользователи теперь будут контрибьютить в Z вместо вклада в проект X. Паритет по фичам или совместимости дублирует усилия.
- Экосистема. Проект X хорошо распространен и у него есть плагины, и он предоставляет интеграцию с другими инструментами. Эти инструменты в экосистеме X могут быть или не быть совместимы с Z.
Индивидумы, бизнес и мейнтейнеры проекта могли бы постараться для предотвращения потенциальной фрагментации. Мейнтейнеры слишком завязаны или часто не понимают, что реально нужно пользователм, или у них другая мотивация. Компании думают, что они встречаются с «уникальными проблемами» чаще чем есть на самом деле.
Из перечисленного выше, я хотел бы заострить внимание на фрагментацию экосистемы, поскольку это имеет отношение к недавнему анонсу Yarn.
Одинаковые, но разные
Когда я пытался использовать альтернативы npm cli, у меня просто сломались пакеты. Они сломались, поскольку ожидали, что будут установлены через npm cli. Не слишком очевидно, но все дело в lifecycle scripts и том как cli по особому обрабатывает симлинки директорий.
У меня есть подозрения, что таких пакетов много, и ты используешь по меньшей мере хотя бы один.
Не стоит ожидать, что альтернативы npm cli обеспечивают 100% совместимость с текущей экосистемой. Если бы они делали все тоже, что и npm cli, все бы прекратили пользоваться npm cli, включая сам npm.
Даже если альтернатива cli обеспечивает большую безопасность и производительность, широкое внедрение вызовет некоторый уровень фрагментации экосистемы.
Не так легко быть зеленым
Новенькие в node.js и JS сообществе столкнуться с еще одним выбором, какой инструмент использовать. Для них будет не понятно, почему npm не работает с этой библиотекой, которая была написана с использованием альтернативного cli. Или, почему альтернативный cli не работает с этой библиотекой, ожидающей npm.
Не смотря на все усилия и внимание вложенные в Yarn, он не сможет покрыть все случаи, не каждый будет ожидать 100% совместимости. Ветеран JavaScript экосистемы сможет найти обходные пути, но новичок нет.
Перемножаем матрицу сборки
Ты майнтейнер проекта. Однажды ты получаешь сообщение об ошибке от пользователя:
хей, этот пакет не работает с quuxbaz, новый npm клиент, добавьте поддержку плиз.
Забудь, что ты потратил прошлую неделю на исправление поддержки Windows. Теперь тебе нужно беспокоится о поддержке quuxbaz на Windows.
Ты можешь увидеть, как быстро растет эта проблема. Если ты уже поддерживаешь три (3) версии node.js на Linux, Windows и MacOS (9), то твоя матрица удваивается до восемнадцати (18), если учитывать, что quuxbaz работает на этих девяти конфигурациях. А может и не работает, так что забудь о тех странных багах над которыми ты работал, это на самом деле проблема с node.js 4.x под MacOS используя quuxbaz.
Я такого не ожидаю, но я не хочу больше оверхеда, не то чтобы я хочу сразу взять и отказаться от поддержки quuxbaz. И я заранее извиняюсь перед вами, если я напишу этот вопрос в трекере твоего проекта.
Более конкретный пример: когда появился Browserify, многие пакеты на node.js магическим образом заработали в браузере. Остальные оказались сломаны. Некоторые поправили этот «баг», другие нет. Время прошло и теперь Browserify работает вроде нормально, но не с Webpack. А потом ломается в каком то браузере, или electron, или телефоне или тостере и тд.
Как нам избежать таких проблем?
Командная работа!
Несмотря на причины почему мы здесь, мы все вместе.
Для пользователей
Как потребитель Node.js модулей, ты можешь помочь мейнтейнеру проекта, отправляя более детальные баг репорты, и/или код который исправляет эти баги. Если ты запостил баг, следи за его исправлением. Если ты законтрибьютил код, пожалуйста, помогай его поддерживать. Последняя часть, особенно важная.
Мейнтейнеры
Как мейнтейнер, будь открытым для новых идей и перспектив. Если ты выложил что-то на Github, ты должен ожидать, что кто-то будет это использовать, не так как ты это предполагаешь. Ты будешь удивлен как много разногласий решает «оставить это за флагом».
Бизнес
Для бизнеса — и специально для R&D команд — если проект имеет активное сообщество, присоединяйтесь. Может оказаться, что другой пользователь хочет такую же фичу что и вы. Может вы можете поработать над ней вместе, как например команда Yarn.
Команда Yarn
Ребята, вы приложили невероятные усилия. Наверное существует какое то недопонимание вокруг существования проекта.
Пожалуйста помогите понять сообществу, и особенно новичкам:
- Что такое Yarn и для чего он?
- Почему именно он?
- Что можно ожидать от работы с ним?
Если я завтра увижу новое ишью «не работает с Yarn», хотя я не ожидаю что увижу, я бы хотел вики или документацию с описанием общих проблем, решений и известных несовместимостей, частые ошибки пользователей и тд.
И если вам не сложно, пожалуйста держите 100% совместимость с npm за флагом, спасибо.
Комментарии (75)
IgorPastukhov
17.10.2016 08:24А что за аллегория такая «Это сродни пушечному ядру». Что имеется в виду?
zelenin
17.10.2016 08:30мощь и разрушительность — огромный ресурс большой компании во благо себе, но во вред сообществу
imgen
17.10.2016 09:29-1Yarn использует пакеты из npm registry, а значит Вы можете пользоваться npm и дальше. Не вижу в этом никакой проблемы.
hell0w0rd
17.10.2016 10:21+3Комментарии сообщества в духе "надо было в npm законтрибьютить" забавляют. В OSS никто никому ничего не должен, а конкуренция(форки, аналоги) в итоге, только улучшает конечный продукт для пользователя.
Но странно, что yarn выложили, а registry — нет.
xuexi
17.10.2016 14:47+1Вы тоже заметили, что автор, видимо, не сторонник конкуренции?
Старый Добрый Монополист в стабильных условиях всегда лучше конкуренции. Вот, был один npm и было нормально (но не супер, ведь монополисты, они такие). По идее, монополию должна сменять конкуренция более технологичных продуктов в ситуации отсталости монополиста и/или динамичной смены условий на рынке.
И при этом почти всегда конкуренты новой формации видятся более слабыми и некрутыми. Может, yarn это будущее, а противники yarn превращаются в луддитов с каждым новым комментом.
пикрелейтед
msatersam11
17.10.2016 15:42+1Всему есть своя мера.
Одно дело, когда эти процессы идут годами-десятилетиями и совсем другое, когда каждые неск. месяцев нет-нет, да появится очередной «убийца php/npm/js».
Это дезориентирует( особенно начинающих).
Это приводит к дроблению сообщества и бесполезной трате его ресурсов на изобретение очередных велосипедов, абсолютное большинство из которых загнётся в грязи и тени.
И, что самое главное — это приводит к увеличению расхода времени программиста на что угодно, кроме, собсно, разработки( чтение бесконечной документации очередного пупер-инструмента, попытки выяснить, как он * работает итд итп).
Как итог, в большинстве своём, ничего кроме вреда, подобное не несёт.
В конкуренции, как и во многом остальном, д.б мера, а не нескончаемый поток почти идентичных по своей сути продуктов, цвета уже не столь небесного/радужного, сколь жёлтого или, того хуже, коричневого…hell0w0rd
17.10.2016 16:36+1Никто не призывает новичка использовать yarn. NPM освоит и хорошо.
Тот факт, что каждый месяц что-то выходит — особенность области. Надо учиться различать перспективные новинки, от однодневок.
А что по вашему делать, если npm устанавливает зависимости 5 минут, а yarn — 30сек?
andreysmind
18.10.2016 11:29Если присмотреться к коду основных инструментов, которые использовались\используются в веб-разработке, то там везде торчат одни и те же имена. Yehuda Katz, Paul Irish, James Kyle, ну я только в топ контрибуторов Yarn посмотрел.
Мне кажется, что я слышал эти имена еще когда Руби и Рельсы были мейнстримом.
Складывается впечатление, что есть небольшое сообщество энтузиастов на зарплате, которое задает тон генеральной линии развития JS инфраструктуры. Как только им надоедает очередной фреймворк — они его забрасывают и начинают очень бурно создавать что-нибудь другое.
lookid
17.10.2016 10:44-5Так получается, когда код пишут не инженеры, а олимпиадники и математики. Хотя олимпиадники и математики должны быть на контракте и консультировать, максимум. Самый простой пример — Гугол. Конкуренцию которого выдерживают только Майкрософт и прочие big-4. Отсутствие потолка привело к гипер-росут Гугла и неконкурентноспособности Нокия, Опера, Яндекс и прочие. Закрытию десятков сервисов и превращения IT в какую-то дикую кашу с фреимворками на миллионы строк для создания простого веб-приложения.
zelenin
17.10.2016 12:54+4походу статья прошла мимо вас, а вы запостили заготовку под любую статью о мегакорпорациях
AndreyRubankov
17.10.2016 11:38JS сообщество недовольно новым пакетным менеджером? Взрослеют?))
wing_pin
18.10.2016 12:11Можно ли назвать взрослением точку зрения «у меня все работает, зачем они изобрели очередной велосипед»?
AndreyRubankov
18.10.2016 12:32Обычно сообщество подхватывает каждый новый велосипед от фейсбука или гугла или еще от кого-то известного и сразу пытается затянуть в продакшн. Сразу появляется сотни статей на тему какой классный велосипед. И обычно мало кто думает «зачем еще один?», а вот конкретно в этом случае этот вопрос появился.
По-моему, когда в умах первая мысль «зачем еще один?», а не «вау! нужно перевести на новую технологию!» — это признак взросления.
baka_cirno
17.10.2016 11:41Так нет никакой фрагментации. Yarn несовместим с npm только на клиентской стороне, да и то, частично. В остальном это всего лишь кеширующая прокся для уже существующего репозитория. Все, что вы публикуете в npm, доступно и в yarn (и наоборот, насколько я понимаю).
Это всего лишь еще один инструмент — хотите используйте, хотите — нет.
devlato
17.10.2016 13:36+1Автор так пишет, как будто npm – безупречный и лишённый изъянов продукт, а Facebook вот тут выпустил свою поделку на коленке – yarn – и теперь заставляет лично его ей пользоваться (к тому же, очевидно, угрожая смертью ему и его семье, судя по количеству ненависти и ксенофобии в статье).
Лично мне инициатива нравится, поскольку в при работе с npm иногда возникает великое большое множество проблем – низкая производительность, большой объём зависимостей на диске и т.д., и очевидно, что npm Inc часть этих проблем не решает, и если хотя бы некоторые из них будут качественно решены посредством yarn, это будет замечательно, а поддержка необходимых фичей вроде lifecycle scripts для более качественной совместимости с npm появится со временем, поскольку сообщество этого требует.
Если что, ни в кого ссаными тряпками кидаться не хотел, и всё написанное – лишь моё мнение, которое имеет право на жизнь так же, как и статья автора.
seryh
17.10.2016 14:39Нет у Yarn действительно важных фич, то чего действительно не хватает так это указания версии nodejs в package.json и соответственно работы приложения именно с этой версией вне зависимости от того что стоит непосредственно в окружении.
mayorovp
17.10.2016 15:03Как вы это себе представляете? Фиксация версии ноды — не задача пакетного менеджера.
TargetSan
17.10.2016 15:08На самом деле, это б-м реально.
Если загружать голые рантаймы ноды для каждого пользователя и производить запуск через прокси-executable. Пример — nvm, который просто скрипт.
Проблем тут две
- Рантайм для самого yarn
- Жёсткая обратная совместимость самого yarn.
mayorovp
17.10.2016 15:18Вы забыли третью проблему — что делать, если два разных пакета требуют разные версии рантайма?..
Regis
17.10.2016 15:34+2Ответ очевиден: выдавать сообщение о конфликте и прекращать работу.
mayorovp
17.10.2016 16:04+1Для инструмента — да. Но что делать тому, кто эту радость будет запускать? :)
seryh
17.10.2016 16:55А представьте себе такую жизненную ситуацию, у вас есть сервер на котором работает жирный такой сервис на Nodejs, и ему года 3, и все эти годы никто в него не заглядывает а его разработчик давно уволился, и тут вам нужно задеплоить туда еще один сервис, естественно написанный на куда более свежей ноде, и вот проблема этот древний сервис не запускается на новой версии Nodejs. И решений сейчас тут только два и оба та еще "радость", это ковырять старый сервис решая проблемы совместимости или ковырять что-либо из контейнеризации типа Docker.
mayorovp
17.10.2016 17:08Как человек, который любит копаться в чужом коде, я все-таки попробую поправить старый код. Не настолько все плохо в ноде с обратной совместимостью чтобы можно было серьезно застрять на этой фазе.
Если старый код настолько плох что даже я в нем не смогу разобраться — можно же просто поставить две ноды на сервер… Но вашу проблему я понял. Так вот, через фиксацию версии ноды она не решается.
Потому что старый и новый код в любом случае придется запускать с разными рантаймами. А значит, они должны ставиться как дополнительные пакеты, а не быть атрибутом проекта.
Пакеты же с дополнительными рантаймами можно создать и в рамках текущей функциональности npm. Кажется, я даже видел посвященный этому проект.
Именно поэтому и я говорил что это не задача пакетного менеджера.
seryh
17.10.2016 18:20Мой опыт рефакторинга старого приложения под более свежую версию Nodejs был настолько неудачным, что у меня осталась психологическая травма. Возможно помните что ранняя версия express изначально хранила в себе большую часть модулей, а потом авторы решили вынести их по разным пакетам, и это была проблема только одного из множества пакетов изменивших API. Я отлично понимаю почему зафиксировать версию ноды для приложения проблематично при текущей архитектуре, но уверен что решение в рамках пакетного менеджера придумать возможно, пусть хоть он докер контейнеры разворачивает под капотом, хорошая практика оставить на усмотрение разработчика выбор — лишний оверхед или решать конфликты ручками.
mayorovp
17.10.2016 18:44Даже с докер-контейнерами не получится зафиксировать. Просто из-за постановки задачи. Вам нужны две разные ноды в одном проекте. А вы предлагаете оставить одно свойство для номера версии. Два разных значения в одно никак не залезут.
Просто представьте как вы будете записывать желаемое в файле package.json.
А то, что нужно вам, называется
nvmseryh
18.10.2016 07:19-2Да, действительно
nvm exec 6.8.1 npm install & nvm exec appnameрешают проблему. Это действительно круто, 2 года назад когда я столкнулся с проблемой подобное решение если и было то не гуглилось. Спасибо за наводку. А давайте представим что Yarn красиво интегрировал в себя nvm, и умеет читать изpackage.jsonаттрибут "nodejs-version":"6.8.1". И теперь когда мы делаемyarn install, yarn сам скачает нам нужную версию ноды и npm, аyarn runбудет у нас алиасом дляnvm exec 6.8.1 appname, для зависимых пакетов их локальный атрибут "nodejs-version" будет игнорироваться. И в итоге мы получаем 1. Более user friendly управление версией ноды для проекта 2. можно глобально обновлять ноду и не боятся что остальные сервисы перестанут работать. Вполне достойная как по мне фича, что бы сделать еще один менеджер пакетов (сарказм)
seryh
17.10.2016 15:10Я как пользователь пакетного менеджера не должен себе ничего представлять. У меня тут рядом есть пакетный менеджер из другой оперы — leiningen, там можно указать версию интерпретатора, и могу сказать что это очень удобно. Почему бы мне не хотеть того же от npm или Yarn?
zelenin
18.10.2016 06:46он и не должен фиксировать. Он должен ругнуться, если текущая версия ноды не соответствует требуемой версии ноды зависимости, и соответственно эту зависимость не установить.
zelenin
самая очевидная фича, которой годами не было в npm — это lock-файл. Нет lock-файла — нет фиксирования версий. Нет фиксирования версий — нет одинакового окружения у разработчиков, тестировщиков, деплойщиков. Нет одинакового окружения — дистрибьютим зависимости внутри проекта после установки через git.
Почему эта фича не была добавлена? Наверняка обсуждения уже были, есть сторонние расширения, но нет из коробки. Если ответом было «by design», то очевидно, что единственный вариант — создание форка.
drakmail
Вы про это https://docs.npmjs.com/cli/shrinkwrap?
zelenin
да, похоже на то. тогда был не прав насчет этой фичи.
Dreyk
оно все равно какое-то кривое. нет той легкости использования, как у, к примеру, Bundler'a
grossws
Какое-то время назад он фиксировал версии не во всех случаях и некоторые вещи так же ломались. До bundler'а сильно не дотягивает(
vintage
И что вы этом плохого? Ну кроме того, что "мне не нравится, что в моём репозитории лежит копия чужого кода".
mayorovp
Репозиторий распухает от такого. Недавно в чате ru.SO участник жаловался на медленную работу с полуторагигабайтным репозиторием...
zelenin
и это истинная правда — у меня гигабайтный репо на текущем проекте.
vintage
Думаю у него была проблема не с полуторагигабайтным репозиторием, а с полуторагигабайтной рабочей копией. Потому как история на то и история, что кушать не просит, пока в неё не лезешь. Если же речь о том, что всё это долго выкачивается, то никто не заставляет выкачивать всю историю.
mayorovp
В любом случае, исключение чужого кода из репозитория спасает от обеих проблем.
vintage
А хранение кода в репозитории спасает от проблем по серьёзнее. Например, от вариативности кода в зависимости от инсталляции. При этом делает это гораздо надёжнее, чем lock-файл.
webkumo
Maven смотрит на ваш комментарий со скепсисом…
zelenin
я хочу использовать систему контроля версий для контроля версий своего кода. чужой код я установлю инструментом для этого предназаченным.
Зачем мне хранить в git зависимости, если я знаю, что введя команду npm install получу идентичное окружение? особенно учитывая, что на маленьком проекте node_modules будет превышать размер собственного кода в разы. Пример: установил create-react-app — 80 мб зависимостей, а собственно мой код не весит и 100 кб.
vintage
Сторонний код — такая же часть вашего приложения, как и ваш код. Вы видимо не застали такие эпики как dll-hell, rpm-hell, jar-hell и прочие dependency-hell?
NPM доступен 24/7, пакеты никогда не удаляются, исходники без изменения версии никогда не меняются, бинарные модули не зависят от окружения, где собираются. Классно у вас там, наверно.
Хороший повод не использовать create-react-app и тому подобные монструозные тулзы, которые ставятся по 5 минут, а делают всего ничего.
zelenin
да, но отличие в слове «сторонний» — я могу его получить со стороны другим способом, и то, что он часть моего проекта не есть аргумент в сторону хранения в гите
как только у меня будут с этим какие-то проблемы, отличные от гипотетических, я займусь их решением
это не монструозная тулза, а стандартный набор либ фронтендера на js. Сам я не фронтендер, и меня вполне устраивает подождать 2 минуты и приступить к написанию кода вместо компилирования кусочков знаний из статей в интернете
vintage
Можете до поры до времени. А потом случается казус и уже не можете.
Вы пропустили эпичный эпик с left-pad?
Вас обманули, это ни разу не стандартный набор. В js вообще мало чего стандартного. Я уверен полезной функциональности там на мегабайт максимум.
zelenin
не пропустил. это опять же недостаток npm-инфраструктуры, предусмотренный годы назад например в композере.
отставьте менторский тон. Я хоть и не фронтендер, но в js-инфраструктуре разбираюсь прекрасно.
vintage
И как же он там предусмотрен?
Вы прекрасно разбираетесь лишь в текущем тренде. Это вершина айсберга.
yogurt1
Парсер JS, сборщик JS, компилятор JS, транслятор JS, полифиллы JS, оптимизация JS, минификация JS, украшение JS, сжатие JS
Логирование, работа с сетью, реализация Virtual DOM, библиотека функций Lodas
И еще куча всего, что нужно для работы тех или иных пакетов
Если готов написать свой сборщик JS с HMR и CSS, рад буду использовать
А еще запилил свой аналог React
С Redux можешь не заморачиваться, он мало весит
vintage
Сам по себе парсер бесполезен.
Сборщик JS и CSS. HMR вам не понадобится, ибо приложение загружается мгновенно.
Транспилятор TS.
Лучше понифилы. Грамотные реализации много не едят.
gzip с этим справляется эффективней.
Нафига? Есть подходы по интересней, чем перегенерировать дерево на каждый чих.
Вы бы ещё jQuery вспомнили.
Логировнаие, работа с сетью и всё такое.
Спасибо, ваше высочество :-)
hell0w0rd
толсто.
нет, как и npm, больше такого не повторится с модулями старше 24 часов.
HMR нужен не для быстрого перезапуска, а сохранения текущего стейта приложения. Особенно полезно при отладке большой формы, например.
любая минификация перед сжатием, делает сжатый бандл меньше. А переодически и код ускоряет.
иногда и jquery нужен, если маленький проектик на вечер и сроком жизни пару недель. А lodash все еще must have, особенно fp часть божественна.
vintage
Кто первый обвинит оппонента в толстоте — тот не тролль.
Не повторится потому, что ___.
Для этого есть sessionStorage.
А формы тем более по умолчанию должны выдерживать перезагрузку.
Ага, и стектрейсы с продакшена приходят тоже сильно короче. Профит от минификации минимален, а проблем вызывает море:
В этом случае нужен не jQuery, а тот инструмент, что лучше знаком. Мне проще из реактивных компонент собрать приложение, чем на jQuery вручную манипулировать деревом и ловить кучу багов рассинхронизации состояний.
Особенно божественно заниматься отладкой fp части, ага. Исполнение по шагам, условные точки останова, просмотр результата выполнения функции — всё это так удобно с так называемым fp, который к собственно функциональному программированию не имеет никакого отношения.
yogurt1
Руки просто у вас кривые, раз не осиливаете современный инструментарий JS
vintage
Поможете мне их выпрямить?
babylon
У него руки не кривые. В современном JS нечего осиливать. Перечислите пожалуйста десяток современных JS инструментов, чтобы был какой-то ориентир.
hell0w0rd
Современные инструменты существуют, чтобы решать старые проблемы. Иначе зачем эти новые инструменты нужны?
Regis
grossws
Почти всегда работают, но иногда приходится использовать
maven-shade-pluginили шейдить нужные куски руками. Но с maven'ом куда лучше чем без него ,)raveclassic
А как тогда быть с node-аддонами на сях?
hell0w0rd
на самом деле все ок и с таким подходом. есть npm rebuild.
Правда бывает, что бинарники под разные OS выкачиваются postinstall, так делает electron и nodegit, навскидку. Тут уже ничего не поделаешь с любым подходом.
wing_pin
Именно с этим мы и столкнулись, когда несколько лет назад пытались хранить все зависимости в гите.
SDSWanderer
Это очень плохо. Правда.
Все вышеперечисленное актуально не только для ноды, проблема стара как мир, и правильным перешением является lock-файл.
vintage
Большинство модулей поставляются с пребилдами под популярные оси/архитектуры.
Например? Вообще, на мой взгляд, это дурная практика.
Либо содержимое shrinkwrap.json. Кстати, типичная ситуация — кто-нибудь добавил модуль себе локально, но забыл добавить его в package.json — привет, падение в случайный момент.
Это изначально была фиговая идея — ставить модули внутри, а не на одном уровне. Да, разные версии модулей тоже можно ставить на одном уровне. Пример, адекватной реализации — DUB.
Всё просто — разрешаем в любую сторону, а потом npm install.
SDSWanderer
Те самые пребилды выкачиваются обычно через lifecycle scripts. Можно конечно надеятся что они сложат их в node_modules, но как по мне — очень не надежно.
Примеры: ngrok, phantomjs, electron
А вот пример аддона для ноды, который нужно скомпилить при установке: node-proxy
Конечно, я согласен что стоит по возможности обходится без использования lifecycle scripts где это возможно, но они присутствуют в любом пакетном менеджере вплоть до apt. А вот действиительно плохой практикой является нарушение инкапсуляции работы пакетного менеджера.
Если ее не нарушать — все равно в какие папки и в сколько копий он кладет модули и выкачивает зависимости.
По поводу разрешения конфликтов я не понял. Т.е все равно, нужно хранить в актуальном виде package.json и npm-shrinkwrap.json, что осложеннно тем, что обычно при таком подходе они не используются, НО, если возник конфликт — все что до этого так берегли полетит в топку, и именно они будут определять что в итоге окажеться закоммичено с node_modules в репозитории?
poxu
Так в package.json ведь указываются версии зависимостей. Или я чего-то не так понимаю?
mayorovp
В npm существует возможность указывать не конкретную версию — а диапазон (т.н. "мягкие" зависимости). И если для своего проекта достаточно эту возможность не использовать — то что делать когда эта возможность используется сторонними пакетами?
poxu
То есть lock файл нужен, чтобы фиксировать версии всех зависимостей, а не только тех, которые присуствуют в проекте явно?
Googolplex
Да, всё так. Lock-файл (эта идея пришла, кажется, из Bundler'а и с огромным успехом сейчас используется в Rust'овом Cargo) фиксирует версии всех зависимостей, транзитивных в том числе. Кажется, ещё yarn решает проблему с недетерминированным порядком установки пакетов и их расположению в файловой системе, которая есть у npm.
zelenin
>= 2 у одного разработчика может дать 2.0.1, а на следующий день у другого разработчика 2.1.0, что может повлечь за собой изменение и других версий других либ, а также поломку кода.
Odrin
Если соблюдается semver, то версии 2.X.X не содержат braking changes, а значит поломки кода не будет. Да и нотации вида ">= 2" лучше использовать только в peerDependencies. В целом, все проблемы возникают только из-за не следования рекомендациям и не соблюдения общепринятых правил.
zelenin
а) помимо соблюдения семвера нужно, чтобы новые куски кода не ломали старый по недосмотру — это бывает, но в идеальном мире
б) >=2 — это все же и 3.* тоже
в) все-таки надежда на соблюдение сторонними разработчиками правил — это непозволительная роскошь для продакшна