Yarn: Добавить пакет без сохранения в package.json

Нет, эта функция была упущена намеренно. Считается опасным устанавливать пакет без отражения в package.json. Почему вы хотите, чтобы такая вещь существовала?

Из объявления в

Мы удалили поведение «невидимой зависимости» npm install.и разделите команду. Запуск yarn add <name> эквивалентен запуску npm install --save <name> .

Я довольно часто использовал эту функцию для тестирования. Особенно, когда я работаю с поддерживаемой мной библиотекой и мне нужно установить локальную версию (которая создает file: dep) просто для проверки моих изменений перед созданием выпуска.

Хотя я согласен, что реализация npm для этого по умолчанию была плохим выбором, я думаю, что это то, что может пригодиться при явном использовании.

Да, я думаю, что было бы неплохо иметь возможность делать это с явным флагом, в настоящее время для этого все еще можно использовать npm i =), но просто чтобы избавиться от необходимости npm.

Мы явно не поддерживаем это, поскольку это обязательное изменение в node_module , которое будет стерто с последующими yarn install s, поскольку мы считаем package.json и yarn.lock источник истины.

У нас есть зависимость, которую нелегко установить в Windows (libxslt), поэтому:

• Для Windows: разработчики распаковывают его в свои node_modues
• Для linux: разработчики устанавливают его без сохранения (если он находится в package.json, разработчики, использующие Windows, не могут выполнить установку, потому что сборка завершится ошибкой)

Есть ли чистый способ сделать это с помощью пряжи (или какой-либо лучший способ добиться этого результата)?

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

@GuillaumeLeclerc А как насчет yarn add -D xxx и самому удалить запись из package.json?

Он будет удален при следующем добавлении другого пакета? Не так ли?

@GuillaumeLeclerc К сожалению, да.

@GuillaumeLeclerc Возможно, вы захотите очистить свой комментарий ...

Добавьте аргумент типа yarn add --no-save чтобы я мог установить модуль, не изменяя свой package.json или yarn.lock. Я часто обнаруживаю, что мне нужно протестировать модули, прежде чем переходить к ним.

Я не могу использовать обычный npm install потому что получаю «Превышен максимальный размер стека вызовов». Так что пряжа - единственный реальный способ укладки.

Пожалуйста, не заставляйте меня возвращать изменения в package.json yarn.lock!

Меня это кусает, потому что я пытаюсь установить peerDep. У Yarn нет возможности установить одноранговые депеши во время install поэтому мне приходится делать это вручную. Я не могу yarn add <package> не добавив его в package.json / yarn.lock. Я застрял.

@viveleroi, это звучит совершенно правильно. Зачем вам устанавливать одноранговую зависимость, не добавляя ее в свой package.json ?

@hpurmann Потому что он дублирует мой peerDependencies в dependencies (или devDependencies если я использую --dev ). Если это то, что задумано, то это определенно не интуитивно понятно.

@hpurmann Я хочу опубликовать компонент React, поэтому реагируйте на него как peerDep. Однако мне нужно установить в проект React для его разработки.

просто добавьте --no-save => это так важно
мне нужно пропустить конкретную необязательную зависимость для определенного пакета. Я не могу сделать это с твоей пряжей. может быть с параметром --no-save, я могу работать вокруг

Поскольку yarn link local-pkg не устанавливает зависимости local-pkg в главном приложении, я хотел бы установить их напрямую, но не сохранять их в app package.json, поскольку они будут перенесены local-pkg после его публикации .

Не понимаю, почему владельцы так категорично относятся к этому. Если вы не видите его использования, это не значит, что его нет. Я считаю, что если люди просят об этом, значит, это им нужно, и они не обязательно глупы.
Добавление необязательной опции --no-save решило бы проблему некоторых людей и не принесло бы никаких неудобств.

Я пытаюсь использовать Yarn для проекта NodeJS, работающего на AWS Lambda. Я немного удивлен, почему эта функция не поддерживается. Мой вариант использования заключается в том, что мне нужно установить aws-sdk в моей локальной среде разработки, но я не хочу, чтобы он сохранялся в package.json потому что AWS Lambda уже установила это в своей среде. Включение aws-sdk означает, что наш последний пакет будет раздутым.

звено пряжи и добавление пряжи не могут жить вместе. Добавление пряжи зависит от package.json, в то время как ссылка пряжи просто связывает локальные пакеты с другим местом.

Предположим, вы разрабатываете пакет X, который зависит от Y, вы оба являетесь разработчиком X и Y, поэтому вы сохраняете X и Y локально и связываете Y с каталогом X. Когда вы добавляете пряжу в X, он стирает ссылка на Ю.

Как это обойти?

~ В таких случаях вы можете просто использовать команды npm для установки, не создавая отпечатка на пакете json или yarn.lock: ~

~ npm install [packages ...] --no-save --no-package-lock ~

как указано ниже в @heikomat , поскольку npm5 использует автоматическую обрезку после установки (см. https://github.com/npm/npm/issues/16853 + https://github.com/npm/npm/pull/18921), это не вариант и может полностью сломать вашу папку node_modules.

хорошо, теперь я не могу жить без npm тогда

Я использовал npm install в одном из моих скриптов, который устанавливает зависимости локальных подмодулей для основных node_modules. Это нормально работает с npm4, но полностью не работает с npm5, поскольку npm5 просто решает уничтожить некоторые пакеты во время установки -.- (см. Https://github.com/npm/npm/pull/18921)

По этой причине я пытался заменить npm install в моем сценарии на yarn, но я не могу этого сделать, если yarn всегда касается package.jsons локальных подмодулей во время установки, по крайней мере, без мой сценарий становится беспорядочным и "убирается" после пряжи

У вас уже есть опция --no-lockfile , поэтому папка node_modules перестает думать,
но разработчикам по-прежнему нужны обходные пути для сохранения неизменности package.json.

Спасибо.

Мне нравится, как каждый раз, когда кто-то объясняет свой особый вариант использования для установки модуля, но не записывает его, сопровождающие возвращаются и повторяют свой шибболет. Вам должно быть легче почувствовать уверенность в своем упорстве, если вы можете интерпретировать эту просьбу множества разных людей как исходящую от тех, кто страдает от морального упадка. В качестве компромисса, может быть, мы могли бы назвать переключатель --i-am-a-heritic-and-a-bad-programmer ?

Печально видеть, что один ключевой недостаток, который yarn сохраняет от npm - это его антагонизм по отношению ко всем за пределами своей организации.

И в моем случае я хотел использовать его как обходной путь для проблемы # 4297 :)
Искусственное ограничение действий разработчиков может сделать ваш продукт непригодным для использования в определенных ситуациях.

Подожди, ты издеваешься надо мной? Это пародия. Пожалуйста, перестаньте диктовать, как должен работать каждый рабочий процесс разработчика. Именно поэтому NPM нам не подошел, и мы перешли на Yarn. Эта идеология, согласно которой «package.json и yarn.lock должны быть источником истины», бессмысленна. Пакеты должны быть установлены без изменения исходного кода. Просто как тот.

Давайте, сопровождающие. Очевидно, что это действительно необходимо сообществу. Пожалуйста, перестаньте прерывать интеллектуальный разговор не отфильтрованной и неуместной философией.

Теперь я обнаружил, что yarn нарушает мои тесты, потому что у меня есть модули, в которых мне нужно протестировать require и для проверки требуется, я фиксирую пример модуля в ./node_modules . Yarn удаляет примеры модулей, когда я запускаю yarn install . Я полагаю, что это больше педантизма «источника истины».

Пример использования: для инструмента, который я использую, требуется пакет. Команда не использует этот инструмент. Команда (справедливо) не хочет, чтобы этот пакет был установлен.

Это серьезно расстраивает. Я использую codelyzer для руководства по стилю angular, но остальная часть моей команды этого не делает, и это не влияет на функциональность кода. Единственный способ заставить его работать сейчас - это добавить его в мою пряжу и просто предположить, что моя пряжа на самом деле не изменилась, или использовать npm, даже если моя команда использует пряжу. Оба эти варианта ужасны.

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

Приведу еще один пример, почему это может быть полезно:

У нас есть сценарий, который автоматически обновляет зависимости, устанавливая новую версию, запуская тесты и ЗАТЕМ сохраняя ее в package.json / *.lock и фиксируя это изменение ИЛИ откатывая назад, если произошла ошибка. Намного проще просто запустить yarn снова вместо того, чтобы запоминать старую версию и явно adding это снова.

Более того, кажется более чистым не видоизменить вашу единственную точку истины ( package.json ) до «абсолютной» уверенности в том, что вы действительно можете обновить эту зависимость без нарушения теста. На данный момент вы получаете package.json (даже если он временно), содержащий зависимость, которая нарушает ваш код.

Есть много допустимых вариантов использования этой проблемы. Готовы ли разработчики yarnpkg принять PR, если он будет создан?

pinging @kittens, если вы все еще

А пока я использую следующий сценарий в разделе scripts в package.json :

"scripts": {
  "install-sneaky-package": "npm install -g sneaky-package && cp -r $(npm root -g)/sneaky-package ./node_modules/sneaky-package"
}

Я полагаю, есть альтернатива пряже?

Альтернативы нет, npm5 грязен, как моя жизнь.

И не забудьте скопировать символические ссылки в папку .bin. ;)

Для меня chmod 444 package.json и yarn add XXXX --no-lockfile по крайней мере решают проблему для локальной разработки и тестирования.
Добавление заканчивается (ожидаемой) ошибкой разрешения, но добавленный модуль впоследствии присутствует в node_modules, и я могу протестировать одноранговые зависимости, локально установленные, но не сохраненные в package.json, а как одноранговые зависимости.

Иногда мне временно требуется отладочная библиотека, например why-is-node-running . Я знаю, что хочу избавиться от него после однократного использования, и опция --no-save позволит мне установить и забыть, не рискуя испортить свои зависимости.

Я использую Lerna, и я действительно просто хочу установить _only_ Lerna на одном из моих этапов CI, для этапа публикации, поскольку проект уже построен на предыдущем этапе и артефакты перенесены. Это допустимый сценарий?

Если бы эта функция была доступна, я бы сэкономил на некоторых шагах.
Мой node_modules в любом случае находится в .gitignore.

Вместо:

git clone external-package (needed for temp testing only)
yarn install
yarn link

вернуться к моему исходному репо
yarn link external-package

просто:
исходное репо:
yarn install external-package --no-save

В рамках наших конвейеров сборки нам нужно установить nsp и запустить его, экспортировав файл dependency-check.xml.

Я не понимаю, почему эта простая установка инструмента должна быть отражена в списке пакетов, это просто означает, что мне теперь нужно сделать git checkout ${BRANCH_NAME} чтобы отменить изменения, прежде чем я смогу вставить теги.

Я не пытаюсь изменить источник. Я не хочу, и это не мое дело, это зависит от команд разработчиков в моей организации. Вы немного усложняете мою жизнь какой-то абстрактной философии. Прекрати.

Есть идеи, почему этот вопрос был закрыт? Был ли добавлен переключатель --no-save в PR?

Бывают случаи, когда я хочу изменить версию модуля, полученную из зависимости. Например, @types/sinon введенный другой зависимостью разработчика, недавно нарушил мой tsc. Я не хочу, чтобы @types/sinon в моих зависимостях разработчиков, но я хочу вручную изменить версию с помощью yarn add @types/[email protected] --no-save чтобы я мог продолжать работать. Вместо этого я просто переключаюсь на npm. Очень неприятно.

У меня есть производственная зависимость (appdynamics), которая в значительной степени является взломом двоичных файлов для конкретной платформы. Оказывается, он нам даже не нужен на машинах разработчиков. Добавление yarn add ... --no-save позволило бы нам выполнить развертывание без ошибок, и сценарий не подвергал бы опасности package.json (особенно потому, что package.json, как ни странно, не может иметь комментариев, объясняющих назначение каждого сценария или зависимости)

cc @kittens @hpurmann

Пожалуйста, устраните эту невероятно популярную проблему или заблокируйте ее как решенную. Было бы очень признательно получить конкретный ответ на все критические замечания, поднятые выше.

И сообщество готово предоставить эту функцию, просто сообщите нам, примете ли вы такой запрос на перенос. Спасибо.

ха-ха, все еще не реализовано, niiiiice

Почему вы хотите, чтобы такая вещь существовала?

Было то же самое, что люди говорили о JSX, когда он впервые появился, смешивая шаблоны и логику. Если это возможно и имеет свои варианты использования, правильный вопрос должен быть: почему бы и нет? Я имею в виду, что это флаг, это не поведение по умолчанию, поэтому вы явно указываете пряжу (то есть я знаю, что делаю).

@kittens @hpurmann
У меня есть несколько пакетов на основе реакции, и у них есть зависимости подмодулей друг от друга. поэтому у меня есть react и react-dom как одноранговый депо, но когда мне нужно собрать эти пакеты индивидуально, мне действительно нужно react и react-dom.
Я предполагаю, что это был бы подходящий вариант использования для локальной установки пакетов без их добавления как dep.
Я бы не хотел иметь npm для такого тривиального использования в моем проекте.
Никаких обновлений, ждем чего-то похожего на --no-save .
Я думаю, нет ничего плохого в добавлении функции, если этого требует сообщество, если разработчик знает о ее побочных эффектах (потеря локальных пакетов при запуске yarn install).
благодаря

Удобный трюк - yarn add --dev pkg && yarn remove pkg . То же самое. Файл блокировки остается таким же нетронутым.

Об этом ранее упоминал

В некоторых случаях можно обойтись без установки необходимого пакета в отдельной папке и yarn link необходимого пакета туда, где он иначе был бы добавлен. Это не идеально, но может помочь.

cd /third-party
yarn add foo
cd node_modules/foo
yarn link

cd /my-project
yarn link foo

@silentorb точно не стоит, имхо. add + remove - это именно то, что делается с --no-save в npm. Он не вмешивается в системные ссылки и не затрагивает файл блокировки - то есть то же самое после yarn remove .
Не говоря уже о том, что если вы хотите сделать это программно, то создание каталогов, ссылок и т. Д. - это не выход.

некоторые случаи

Например? Довольно странные?

@hpurmann @kittens

Итак, какова рекомендуемая практика для разработки пакета с одноранговыми зависимостями?

Если у меня есть, например, React как peerDependency в моем пакете, следует ли мне добавить его как devDependency, чтобы разрешить импорт?

Глядя на https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/package.json, я думаю, ответ - да

@ 18steps посетите https://www.npmjs.com/install-peers

Есть несколько ситуаций, в которых можно использовать эту функцию.

Как и в жизненном цикле CI, я добавил репортера покрытия. Но я не могу довести их до package.json затем влияет на публикацию NPM .

Сохранить или нет, я думаю, что этот выбор должен быть за самими разработчиками, а не за инструментом.

Хорошо, давайте попробуем взглянуть на это с точки зрения сопровождающих. Я определенно вижу недостатки наивного решения --no-save . Мы не получили здесь очень подробного объяснения, но я попытаюсь построить стального человека. Может, они меня поправят. Может быть, мы найдем компромисс. @kittens @hpurmann

(К сожалению, это длилось дольше, чем я планировал.)

Управление зависимостями для современных Node- и веб-приложений немного хаотично. И все же нам нужна система, которая дает нам как надежную автоматизацию, так и определенный уровень контроля и предсказуемости, с такими функциями, как дедупликация и воспроизводимые сборки.

Чтобы справиться с этой сложностью, нам нужно знать, что установлено и почему, и нам нужен единый источник правды для устранения любых несоответствий. Рискуя заявить очевидное, node_modules сам по себе не может выполнять ни одну из этих ролей. Он слишком медленный для обхода, слишком большой для передачи, слишком мелкозернистый для управления версиями и не может кодировать аспект «почему». Вот почему у нас есть package.json и yarn.lock .

Yarn инкапсулирует сложность node_modules , предоставляя нам ограниченный доступ через интерфейс. Если мы обещаем не нарушать инкапсуляцию, мы получаем взамен определенные гарантии, такие как дедупликация и воспроизводимые сборки. Если мы устанавливаем что-то в node_modules без соответствующего изменения в package.json и yarn.lock , мы теряем эти гарантии.

Более того, это негласный контракт, о котором многие разработчики явно не знают. Когда они его нарушают, они делают это не сознательно. Поэтому, когда что-то идет не так, можно несправедливо обвинить Yarn. Кроме того, создание инструмента, которым сложно выстрелить себе в ногу, - неплохая философия дизайна.

Однако я вижу несколько причин для компромисса:

• Похоже, здесь есть определенная необходимость. Просто посмотрите на множество вариантов использования, перечисленных в комментариях выше, и на соотношение «большой палец вверх» / «большой палец вниз». Очевидное упорство сопровождающих перед лицом такой односторонней реакции не делает Yarn слишком привлекательной.

• Можно найти решения, которые подходят каждому. Например, представьте новый файл yarn.local.lock . Разработчики помещали его в свои .gitignore , и он сохранял запись всех пакетов, установленных с флагом --no-save и их зависимостей.

  Чтобы изолировать yarn.lock от этого, дедупликация и выравнивание «локального» дерева зависимостей ограничены. Файл локальной блокировки может адаптироваться к версии в основном файле блокировки (и в этом случае выполнять дедупликацию), но не наоборот. В результате многие транзитивные локальные зависимости не могут быть сведены в node_modules .

  С помощью этого решения Yarn может продолжать отслеживать все пакеты, разработчики могут устанавливать что-то, не загрязняя свое репозиторий, и мы сохраняем воспроизводимые сборки. (Также есть место для package.local.json с разделом devDependencies , но я не уверен, что это потребуется.)

• Люди уже используют обходные пути, чтобы в любом случае получить то, что они хотят, по крайней мере, три из них описаны в комментариях выше. Но они неудобны в использовании, не предлагают таких же гарантий и требуют, чтобы разработчики боролись с Yarn, чтобы выяснить их. Это худшее из обоих миров.

Возможно, я что-то упустил, но, похоже, этот разговор стоит того.

У меня есть еще один вариант использования: я бы хотел, чтобы модуль был доступен в REPL, но не собираюсь использовать его в моем коде. В настоящее время мне нужно перейти в другую папку и установить там этот модуль, а затем импортировать некоторые файлы json, используя ../other-project/data/xyz.json .

Но если я хочу импортировать модуль, и эта штука импортирует другие модули, используя относительные пути, что ж, это сломается.

Просто разрешив мне установить модуль в node_modules без сохранения, все будет намного проще.

Я удивлен, насколько специалисты по сопровождению сопротивляются этой идее.

Боже мой, я только что прочитал предыдущие комментарии, и отношение сопровождающих меня разочаровывает. Я разрабатываю множество подключаемых модулей для конкретных фреймворков, которые зависят от библиотек фреймворков, и я не хочу добавлять их в качестве жестких зависимостей в свои плагины.

У меня есть плагин, который полагается на определенные пакеты, определенные в peerDependencies , теперь проблема, как и многие другие люди, уже прокомментировала, как, черт возьми, вы устанавливаете зависимости локально, не добавляя их в package.json файл? Ну не можешь.

Единственное решение, которое я нашел, - это установка peerDepencies как devDependencies что совсем не кажется идеальным, но помогает обойти проблему. По крайней мере, npm в ужасном состоянии устанавливается без изменения вашего файла package.json .

@hpurmann @kittens

Вы перестали отвечать сообществу? Очевидно, что игнорирование этой проблемы не принесет вам пользы и никуда не денется. Какой смысл называть это проектом с открытым исходным кодом, если вы даже не собираетесь отвечать на простой вопрос: если кто-то выполнит работу и отправит PR, вы примете это?

Наверное, мне следовало ответить некоторое время назад, сразу после того, как @viveleroi объяснил свой вполне допустимый вариант использования (который, похоже, у многих из вас есть). Тогда я высоко оценил его ответ, чего явно недостаточно, чтобы его заметили.

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

Но я ничего не могу решить. Я не поддерживаю этот проект.

@Vheissu В чем проблема с yarn add --peer <dep> ?

для меня пряжа добавить --peerработает ДО тех пор, пока вы не добавите другой пакет, после чего существующие одноранговые deps будут удалены из локальной установки, и вам придется вручную прочитать их.

Мне нужна эта функция, потому что сегодня я пишу пример реализации моей библиотеки с помощью express, но ни один из моих кодов не зависит напрямую от express. Я не хочу, чтобы что-либо устанавливалось или зависело от Express, но я хочу установить его в свой текущий каталог.

Как и @ brendan-hurley @suyanhanx , у меня есть зависимости, которые я хочу установить в CI, а не локально.
Я хочу свести количество локальных зависимостей к минимуму, чтобы нам не пришлось раздувать node_modules и терять время и пространство для каждого разработчика, работающего над проектом.

Пакеты, которые нужны в CI, но не локально:

• Специальные инструменты CI: семантический выпуск, файл блокировки-гринкипера
• Инструменты отчетности о покрытии: codacy-охват, комбинезоны
• Инструмент создания отчетов о тестировании для CI: jest-junit и т. Д.

Вот почему нам нужна эта функция:

Использование yarn link приведет к связыванию зависимостей пакета, поэтому вам необходимо установить их в
связанный пункт назначения - добавление этих внешних зависимостей к package.json просто делает его очень неудобным.

Либо yarn link должен добавить зависимости, либо предоставить способ исключения в пункте назначения package.json

У меня довольно эзотерический вариант использования, но он мне пригодится. Я полностью понимаю, почему важно, чтобы yarn.lock и package.json были источником истины, и что если бы я использовал команду --no-save , мои изменения были бы стерты при последующих yarn команд.

Тем не менее, я хочу, чтобы yarn доверял мне знать, что я делаю, и позволял мне передавать флаг --no-save . Если я столкнусь с какой-либо из проблемных ситуаций, я точно буду знать, что пошло не так, и что винить могу только себя. :улыбка:

Мой вариант использования?
Я запускаю 64-битную машину win.
Прод-машина 32-битная.

Зависимость Node-sass, которая у нас есть, поддерживает только 32-разрядную версию, если мы не обновим пакет.

Не изменять зависимости в package.json или yarn.lock для поддержки машины разработчика.
Поэтому хотелось бы локально установить последнюю версию node-sass для поддержки 64-битной версии, но не влиять на package.json и yarn.lock.

Я хотел бы установить пакеты @types/* в проекты, отличные от TypeScript, не испортив package.json / yarn.lock для лучшего автозаполнения в VSCode.

Я использую lerna с рабочим пространством пряжи.
Определение типа Antd не работает из-за обновления @ types / [email protected] .
Antd исправит это на выходных.
Но теперь мне нужно заставить пряжу установить фиксированную версию @ types / [email protected] в workspaceRoot вручную, не затрагивая текущий package.json (поскольку последняя версия будет установлена ​​автоматически).

Сохранение поведения по умолчанию при сохранении в package.json является правильным, но в реальных случаях разработчик должен установить модуль, не затрагивая package.json. Особенно, когда в некоторых пакетах происходят неожиданные критические изменения.

Неявное обновление пакета и неявное сохранение в package.json приводят к конфликту.

Вот еще один вариант использования. Я поддерживаю библиотеку React. Перед публикацией новой версии я хочу провести тесты с несколькими версиями react и react-dom , чтобы убедиться, что мои изменения совместимы в прямом и обратном направлениях ( @next ). Я делал это, используя настройку ниже, но теперь я хочу использовать рабочие области Yarn, поэтому мне нужно перейти на Yarn.

"test:backwards": "npm i [email protected] [email protected] --no-save && npm test",
"test:forwards": "npm i react<strong i="9">@next</strong> react-dom<strong i="10">@next</strong> --no-save && npm test",
"test:latest": "npm i react<strong i="11">@latest</strong> react-dom<strong i="12">@latest</strong> --no-save && npm test",
"test:compat": "npm run test:backwards && npm run test:forwards && npm run test:latest"

Я не могу, чтобы этот сценарий изменил мой package.json как это приведет к сбою моей команды публикации ( pack publish ) из-за неустановленных изменений.

Я хочу добавить дополнительные пакеты в свой конвейер CI для целей тестирования, не касаясь файла package.json (возможно, монтирование файла только для чтения).
Они не являются частью компонентов разработки.
Во время разработки и тестирования на машинах разработчика они не должны устанавливаться, а во время сборки и производства они не должны устанавливаться, они необходимы и приемлемы только на сервере CI во время тестов.

Это работает, просто используя npm, но yarn должна иметь возможность удалить зависимость от npm.
Это вполне может вернуть нас к использованию только npm вместо yarn.

Кроме того, это просто нарушает обещание, что yarn сможет полностью заменить npm, потому что он просто не может делать то, что npm может.

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

ты смеешься ? 3 года добавить простой переключатель?

Другой вариант использования: мы используем пакет npm ( git-hoooks ) для проверок перед фиксацией. Не у всех в команде установлен node, поэтому включение его в package.json может нарушить коммиты для некоторых людей. Итак, я пытаюсь создать сценарии npm для временного включения / отключения хуков, установив / удалив git-hooks. Очень разочарован, узнав, что эту, казалось бы, простую и легкую задачу практически невозможно выполнить с помощью пряжи.

Если вас беспокоит, что yarn.lock больше не будет источником истины для содержимого node_modules, что же в этом плохого? Не могли бы существующие функции просто игнорировать существование неотслеживаемых зависимостей? Yarn - отличный инструмент, и сопровождающие оказали большую услугу сообществу JS, но им нужно пересмотреть это решение.

ты смеешься ? 3 года добавить простой переключатель?

@spanasik и @Ryuurock : будьте вежливы, обсуждая высококачественное программное обеспечение, которое предоставляется вам бесплатно.

Это не заняло «3 лет», потому что переключение слишком сложно реализовать - это потому, что сопровождающие не убеждены, что это принесет чистую выгоду пользователям. Если вы не согласны с этим, приведите аргумент в пользу этой функции.

@NickHeiner вот 10 экранов аргументов. И главное, что вызывает разочарование, заключается не в том, что разработчики не убеждены, а в том, что они игнорируют это, не отвечают на аргументы, когда люди «не согласны с этим, приводят аргументы в пользу функции». А когда люди разочаровываются, они, конечно, оставляют неприятные комментарии. Пожалуйста, не вините во всем пользователей.

Я согласен, что было бы лучше, если бы сопровождающие обратились к обсуждению здесь. Явно проявился интерес со стороны широкого круга людей на протяжении нескольких лет. Так что, возможно, мое предложение о том, чтобы @spanasik и @Ryuurock просто «поспорили», является необоснованным, потому что оно, вероятно, будет проигнорировано, как и все остальное здесь.

А когда люди разочаровываются, они, конечно, оставляют неприятные комментарии. Пожалуйста, не вините во всем пользователей.

Я не согласен. Это грубость по-прежнему не является ни полезным шагом вперед, ни поведением взрослых. Невежливость - отличный способ оправдать дальнейшее игнорирование сопровождающими: «нить - это просто тролли».

Конструктивные пути движения вперед:

1. Обратите внимание сопровождающего на эту ветку на других каналах (возможно, они ее проигнорировали) и попросите их хотя бы признать аргументы здесь, даже если они не согласны.
2. Разветвляйте / заменяйте пряжу и управляйте проектом так, как это нравится людям.

Удобный трюк - yarn add --dev pkg && yarn remove pkg . То же самое. Файл блокировки остается таким же нетронутым.

Проверено - не работает.

Мой вариант использования следующий:
Некоторые пакеты имеют необязательные надстройки, которые загружаются с помощью require. Я не хочу добавлять эти надстройки в раздел devDependencies, поэтому я выполняю команду «yarn add my-add-in» и вручную удаляю ее из файла package.json. В моем облачном конвейере CI я использую npm i add их (для тестирования). В моем локальном конвейере я не хочу использовать npm, потому что он создает дополнительный файл блокировки. Мой лучший вариант сейчас - использовать npm, а затем удалить их файл блокировки (чтобы удалить появляющуюся вторую версию правды).

Итак, после прочтения всего, мой вопрос к сопровождающим таков:

• Почему ты такой непоследовательный?
• Почему бы не реализовать эту философию во всех функциях?
  
  
  
  • То есть: решите, как все должно быть сделано для всех нас, и удалите все другие параметры из всех функций. Придерживайтесь курса! Будь честен с собой!
  
  

Неоспоримым фактом является то, что все хорошее программное обеспечение имеет настройки конфигурации, потому что хорошее программное обеспечение позволит пользователю выбрать то, что лучше всего для его ситуации . И всегда прикасаться к файлу package.json - это хорошая практика, но есть крайние случаи, когда пряжа просто не подходит для задачи из-за этой философии.

Мне очень нравится пряжа, потому что она простая и быстрая . Очень жаль, что сопровождающие ведут битву, которую они обязательно проиграют, потому что сообщество вынуждено вернуться к медленному и надежному npm, чтобы все работало.

Давай немного снизим температуру. Никто не должен испытывать отвращение к
часть программного обеспечения, которое им разрешено использовать бесплатно.

В среду, 15 января 2020 г., в 23:17 Хаджиме Ямасаки Вукелич <
[email protected]> написал:

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

Верить в совершенные правила и в то, что никогда не будет повода
ломать их наивно. Есть разница между "лучшими практиками" и
"сделай или умри". Как выразился Оливер Венделл Холмс-старший:

Молодой человек знает правила, но старик знает исключения.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/yarnpkg/yarn/issues/1743?email_source=notifications&email_token=AAGKTAZRWD3XJQEGH5N5RL3Q6ACZNA5CNFSM4CVUKFMKYY3PNVWWK3TUL52-52HS4DFVREXG43WWWWK3TUL52HS4DFVREXG43
или отписаться
https://github.com/notifications/unsubscribe-auth/AAGKTAZSB4FNAIFLZIL547LQ6ACZNANCNFSM4CVUKFMA
.

Сделайте свой собственный менеджер пакетов, никто ничего не заставит вас делать.

Совсем не злюсь, просто указав на ошибку в вашей логике:

пряжа заставляет меня работать определенным образом.

Пряжа ничего не заставляет вас делать, они сделали инструмент (бесплатно), и он работает определенным образом. Если вам это не нравится, используйте что-нибудь другое.

@foxbunny Спасибо, что разъяснили свое отвращение. :)

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

@whitecolor команда попала в точку. Этот вариант --save - глупый. Yarn гарантирует равновесие между node_modules, package.json и файлом блокировки, и это здорово. Так безопаснее .... npm --save опасен. Это подводило меня много раз

Пожалуйста, прекрати

Или как насчет того, чтобы все просто использовали инструмент, который работает так, как они думают, и успокойтесь.

Мой вариант использования

Я хочу обновить подчиненную зависимость нашего приложения
Я связываю эту зависимость с yarn link
Затем я использую связанный в нашем приложении
Я добавляю зависимость в нашу библиотеку
Добавленная зависимость lib не устанавливается в основном приложении после yarn install (wtf no.1)
Тогда я думаю, хорошо, давайте просто добавим его быстро, не сохраняя в приложении, чтобы я мог просто проверить, работает ли что-то, прежде чем опубликую обновление в нашей библиотеке.
Но - нет.

благодаря

Сожалеем, что авторы игнорируют сообщество.

Как доброволец с открытым исходным кодом, нужно иметь последовательную философию или
проект превратится в комок грязи. Это означает иногда говорить
люди «нет». Если вы не согласны, вы можете создать свой собственный пакет
менеджер, прямо как пряжу заменил npm.

Во вторник, 3 марта 2020 г., в 03:53 Артур Квятковски [email protected]
написал:

Сожалеем, что авторы игнорируют сообщество.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/yarnpkg/yarn/issues/1743?email_source=notifications&email_token=AAGKTA4K3STUMXFRUDMPJU3RFTVTLA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVREXG63V2HS4DFVREXG63V2HS4DFVREXG43V2
или отписаться
https://github.com/notifications/unsubscribe-auth/AAGKTA7WL4R3R47HBU6EPI3RFTVTLANCNFSM4CVUKFMA
.

Я использую Lerna, и я действительно просто хочу установить _only_ Lerna на одном из моих этапов CI, для этапа публикации, поскольку проект уже построен на предыдущем этапе и артефакты перенесены. Это допустимый сценарий?

^ мой первоначальный комментарий - я, честно говоря, не знаю, зачем мне это нужно, и я не знал, что эта ветка взорвется так ужасно - но забавно видеть электронные письма об этом спустя годы.

Я склонен согласиться с сопровождающими здесь:

1. Меня не убеждают мои собственные доводы. Я предполагаю, что сопровождающие были вежливы, не называя это глупым аргументом.
2. Даже если кто-то _поднимет_ PR, это будет означать, что текущее обслуживание функции станет дополнительным бременем для сопровождающих, не позволяя им поддерживать основной продукт.
3. Этот вид функции может быть неправильно использован непритязательными новичками и / или относительно неквалифицированными потребителями пряжи, что еще больше увековечит пункт 2.

В любом случае, вероятно, есть лучший, более архитектурно обоснованный способ уменьшить потребность в этой функции.

Я создал yarn-add-no-save для достижения этой функциональности. Его можно установить локально в вашем проекте или глобально:

$ yarn add yarn-add-no-save --dev
# or
$ yarn global add yarn-add-no-save

После установки вы можете просто запустить:

$ yarn add-no-save <packages> # (yarn-add-no-save when installed globally)

Мой вариант использования - тестировать модули, которые объявляют peerDependencies поэтому у инструмента есть несколько параметров для их автоматической установки, чтобы увидеть, как работают все параметры:

$yarn add-no-save --help

ПРИМЕЧАНИЕ. Я знаю, что сохранение пакета для установки пакетов без их сохранения - это ирония и в основном противоречит цели, но это лучшее, что я мог придумать, и оно соответствует моим потребностям.

Это очень полезно, особенно поддержка peerDeps. Спасибо.

В пользу этой возможности есть несколько веских аргументов. Это не похоже на то, чтобы делать это по умолчанию, люди просят, чтобы это было за четким флагом, что только люди, которые в этом нуждаются, будут использовать его. В настоящее время, как и некоторым другим, мне нужно провести некоторое тестирование во время CI с другими версиями библиотек, которые я не хочу сохранять . Я не могу понять, что здесь так сложно понять.

Мне нужно yarn install xxx затем yarn remove xxx .

Не уверен, обсуждался ли когда-либо этот вариант использования. Позвольте мне попытаться объяснить свою ситуацию - у меня есть куча взаимозависимых пакетов в одном репо. Все они используют одни и те же внешние зависимости с общим пакетом в подпроектах корневого обслуживания ниже, каждый локальный пакет должен быть построен в том порядке, в котором он будет использоваться следующим. Я пытаюсь использовать для этого рабочие места пряжи. Для начала у меня нет локальных пакетов, определенных в моем корневом package.json. После одного полного цикла сборки всех компонентов я получаю полностью обновленный корневой package.json с этими локальными зависимостями. Теперь, когда этот обновленный пакет будет построен на CI - все эти добавленные локальные пакеты выйдут из строя из-за недоступности. Мы должны удалить эти недавно добавленные записи, чтобы они работали в CI.

Мне нужно yarn install xxx затем yarn remove xxx .

тот же самый

Вот пример использования, чтобы иметь возможность это сделать:

Мы создаем инструмент с модульной экосистемой для «устройств» внутри инструмента, и мы планируем настроить локальный экземпляр с этими устройствами и активировать их динамически через конфигурацию. Устройства публикуются в npm (и могут быть вызваны вне нашей структуры, если кто-то захочет).

Ванильный проект НЕ зависит от этих пакетов, поэтому сохранение в package.json было бы неуместным. Конфигурация конкретного экземпляра может требовать локальной установки одного из пакетов.

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

Прежде чем я прочитал здесь ответ «сопровождающих», я думал, что был самым упрямым человеком на свете.

Почти 4 года ... 🤦

«Упрямство» - это не то же самое, что «иметь дизайнерское видение и не реализовывать все, о чем кто-либо просит».

«Упрямство» - это не то же самое, что «иметь дизайнерское видение и не реализовывать все, о чем кто-либо просит».

Видение дизайна описывает счастливый путь, а эвакуационные выходы, запрошенные здесь, добавляют полезности для более широкого сообщества.

Почему бы просто не добавить раздел в файл блокировки, который отслеживает установки в произвольной форме и дополнительные снимки статус-кво (в node_modules ), чтобы сделать их безопасными обратимыми? Или, может быть, поместите зависимости в папку, отдельную от node_modules, и используйте node_modules только для того, чтобы ссылки были открыты для своего пакета, чтобы Yarn действительно мог управлять вещами самостоятельно и не беспокоиться о том, что невидимые установки перезаписывают и ломают материал.

Git решил эту проблему за десятилетия до вас, догоняйте! Просто придумайте что-нибудь! Вот что такое дизайн - обход ограничений, а не борьба с ними (или уступка им).

Туннельное видение с обеих сторон здесь порождено невежеством, чрезмерным мышлением и ненужной поляризацией. Нет ни боевых искусств, ни философии, ни революции, ни политики; есть только инструмент, набор кода и работа, которую нужно выполнить. Если инструмент не может помочь выполнить работу, значит, он не подходит для этого конкретного сценария. А для инструмента, претендующего на замену универсального инструмента, такого как Yarn, существует так много распространенных сценариев, которыми здесь пренебрегают, что он просто роет себе могилу.

Я чувствую, что все толкаются друг против друга на узком холме, когда мы могли просто обойти его.