Yarn: Не предупреждать о несовместимых необязательных зависимостях

Мне кажется, что это уместное использование предупреждения.

Не лучше ли исправить то, что выдает предупреждение, а не просто скрывать его?

@wtgtybhertgeghgtwtg

Что вы имеете в виду под «исправлением»? Как объясняется в https://github.com/npm/npm/issues/11632 , все работает по назначению. Некоторые пакеты зависят от fsevents особенно в macOS (потому что он предлагает превосходный опыт), но возвращаются к другому поведению в Windows / Linux. Тот факт, что fsevents несовместим с Windows, не должен открываться пользователям: это просто детали реализации зависимости для конкретной платформы. Там нет ничего полезного для пользователей (и не о чем беспокоиться).

Я бы сказал, что требование зависимости и добавление двоичных файлов для конкретной ОС не должно быть таким, как это работает.
Я уверен, что есть и другие пакеты, которые вызывают появление этой проблемы, но fsevents является наиболее распространенным, проблемы возникают в babel , webpack , вашем create-react-app , и я уверен, что очень скоро sane и jest . Я думаю, что было бы продуктивнее найти лучшее решение для просмотра файлов, чем изменять поведение диспетчера пакетов из-за недостатков одного пакета.

Если у вас есть альтернативное предложение о том, что могут делать пакеты, использующие fsevents (или сам fsevents ), я бы хотел это услышать! Я не думаю, что есть что-то "неправильное" в том, что пакет зависит от ОС. Это решает реальную проблему, и некоторые проблемы зависят от платформы.

Похоже, мнения разделились.
Я полагаю, что предупреждение о бездействии может раздражать.
С другой стороны, подобные предупреждения, например, «этот модуль не работает на Node.js <4», весьма полезны.
Есть ли настройки, которые люди могут включить, чтобы отключить предупреждения?

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

@jhabdas

как насчет PR, чтобы добавить флаг CLI для подавления по уровню журнала

Я бы с удовольствием отправил PR, но, как и

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

Я не понимаю этого комментария. Я не предлагаю «заморачиваться по второстепенным вопросам». fsevents не делает ничего плохого. Он хочет заявить, что это полезно только в macOS, но не существует в других системах. Другие пакеты, такие как webpack , хотят указать, что они хотели бы использовать fsevents в macOS, но не хотели бы использовать его в других системах. И это именно то, что делают и yarn, и npm.

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

Извините, если я не очень понятен. Теперь я вижу, что это более спорным, чем я ожидал. Тогда давайте не будем этого делать. Я не умру на этом холме. 😛

С другой стороны, подобные предупреждения, например, «этот модуль не работает на Node.js <4», весьма полезны.

... но это действенно - вы можете обновить свою версию Node.js.

... но это действенно - вы можете обновить свою версию Node.js.

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

Открою еще раз, вроде стоит подробнее обсудить.

Мы могли бы, вероятно, понизить его до уровня журнала «info» (и ввести концепцию уровней журнала, как у npm).

@gearon Не могли бы вы предоставить два бесплатных тестовых

У меня примерно аналогичная ситуация, описанная @gaearon : я получаю предупреждения о зависимостях, которые сами используют старые зависимости, и я думаю, они просто не обновились?

Когда я запускаю yarn upgrade я сразу получаю следующее:

warning gulp > vinyl-fs > glob-stream > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected] ...

Но когда я смотрю на следующий список, эти зависимости актуальны.

Я согласен с @gaearon , видеть предупреждение немного страшно, особенно для меня, поскольку я относительно новичок в использовании Node и перешел с использования npm на Yarn. Но это также немного сбивает с толку - видеть предупреждающее сообщение, поскольку оно подразумевает, что это то, что я могу исправить.

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

Однако использование небезопасных зависимостей должно вызывать предупреждение.

Почему мы говорим о _scary_. Это разработка программного обеспечения, а не детский сад.

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

Хорошая идея сначала улучшить сообщение, отправьте PR

7 июля 2017 года в 14:08 Дэниел Блейк [email protected] написал:

@wtgtybhertgeghgtwtg https://github.com/wtgtybhertgeghgtwtg Что кидает
меня в том, что предупреждение просит меня обновить то, что я не могу обновить.
Хотя в данном случае я не использую небезопасную зависимость (я
думаю, что Glob), я понимаю вашу точку зрения и согласен, что это должно быть предупреждением; но я
думаю, его можно сформулировать более информативным. Что-то простое, как
"[dependency_A] использует устаревшую [dependency_B]" - я сразу узнаю
летучая мышь, что а) это не моя вина, ошибка не на моей стороне, и
б) куда обратиться, чтобы узнать, решена ли проблема. Такого рода
информация может спасти пользователей от того, чтобы они спустились в кроличью нору в попытках выяснить
что не так с их стороны.

-
Вы получаете это, потому что изменили состояние открытия / закрытия.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/yarnpkg/yarn/issues/3738#issuecomment-313793331 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ACBdWI1Ks6bSYH_BStzm_b3-ne3bUMT3ks5sLp5PgaJpZM4OGrsi
.

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

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

Хотя я бы сказал, что

warning gulp > vinyl-fs > glob-stream > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected] ...

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

Можем ли мы сосредоточить этот вопрос на одном конкретном случае, пожалуйста? Я не хочу, чтобы это превратилось в велосипедную беседу по поводу всех возможных предупреждений.

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

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

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

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

Звучит неплохо. Я откажусь от подписки, но надеюсь, что эта дискуссия останется в центре внимания в будущем. Спасибо за участие!

Сопровождающие, пожалуйста, закройте это. Некому довести дело до конца.

Не могли бы вы предоставить два дополнительных тестовых примера?

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

Обратите внимание на количество открытых проблем и то, что это запрос на улучшение, а не ошибка.

Сопровождающие, пожалуйста, закройте это.

@jhabdas , я ценю ваши усилия, направленные на то, чтобы побудить меня решению этой проблемы, и указываю, что у команды Yarn достаточно возможностей, но нет необходимости повторять это снова и снова. Это не очень дружелюбное поведение.

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

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

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

При установке create-react-app и последующем запуске create-react-app myapp в ходе установки будет выдано предупреждение:

warning [email protected]: The platform "win32" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.

Предупреждение npm еще страшнее:

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/react-scripts/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules/react-scripts/node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

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

Почему это предупреждение является проблемой?

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

Они не знают, что такое fsevents . Сообщение гласит, что приложение Create React несовместимо с Windows. Это их вывод. Хорошо, если все работает позже, но если что-то ломается, они не всегда сообщают о проблеме, потому что благодаря этим предупреждениям они понимают, что это не должно работать. Я пытаюсь бороться с этим впечатлением этим предложением.

Почему мы говорим о страшном. Это разработка программного обеспечения, а не детский сад.

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

Это может показаться не связанным с инструментами JavaScript, но на самом деле это не так. Здесь есть две отдельные проблемы:

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

2. Из-за бездействия предупреждающего шума у ​​людей появляется слепая зона для предупреждений. Люди учатся игнорировать их. Каждое недействительное предупреждение увеличивает эту стоимость. Мы много раз видели, как это происходило с разными инструментами, не только с Yarn. Сценарий «Мальчик, который плакал волком». В результате в будущем люди не смогут диагностировать проблемы и тратить свое время и время обслуживающего персонала, потому что они пропустили важное предупреждение в море неважных.

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

Это глубина информации, которую я надеялся получить от @gaearon. Спасибо, что нашли время объяснить, поскольку кажется, что ваше сочувствие к ученику сияет, и это похвально.

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

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

Например, быстрый поиск в Stack Overflow предлагает следующее решение для обработки описанного предупреждающего сообщения: https://stackoverflow.com/a/42938398/712334.

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

@ glen-84 не хотите ли вы поделиться своим мнением или просто бегаете по столу?

Конечно.

• Отображение предупреждения о том, что не требует действий и не вызывает никаких проблем, приводит к:
  
  
  
  • Потраченное впустую время разработчиками, которые сначала должны выяснить, почему это происходит, а затем каждый раз игнорировать это (а игнорирование предупреждений - это плохо)
  
  
  • Потраченное время разработчиками Yarn / npm, необходимость объяснять, почему это происходит
  
  
  • Ошибки последующего инструмента
  
  
  • и т.п.
  
  
• Если объединить голоса по проблеме npm, почти 150 пользователей согласятся.
• Теоретически разработчики npm уже приняли изменение.

Я проголосовал против двух ваших комментариев, потому что ИМО они не добавляют ценности этому обсуждению.

Я согласен с тем, что предупреждения, которые не требуют действий, бесполезны, а также могут быть излишне пугающими / шумными /. Давайте с @dmbdesignpdx «s предложение как предложено @bestander?

Добро пожаловать в PR.

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

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

Потраченное время разработчиками Yarn / npm, необходимость объяснять, почему это происходит

Yarn не несет ответственности за решение проблем из отдельных репозиториев или менеджеров пакетов. И NPM - не единственный упаковщик. И лично я бы предпочел, чтобы Yarn выросла, чтобы заменить Composer и заполнить пустоту, которую только что покинул Bower, а не отвлекаться на отвлекающие маневры.

Если объединить голоса по проблеме npm, почти 150 пользователей согласятся.

Это argumentsum ad populum. Дизайн комитетом никогда никому не подходит.

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

@jhabdas Я думаю, что мы согласны в yarn или нет. На данный момент я думаю, что чем полезнее пряжа для пользователей, тем она лучше. Тем не менее, я бы не стал отдавать этому высокий приоритет, чтобы отвлечь ресурсы от более важных исправлений и обновлений, поэтому мы обращаемся к сообществу за PR.

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

Вы узнаете, почему это происходит, и принимаете меры

Что мы должны предпринять?

Yarn не несет ответственности за решение проблем из отдельных репозиториев или менеджеров пакетов.

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

Это argumentsum ad populum. Дизайн комитетом никогда никому не подходит.

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

Хорошо, @ glen-84 любезно напомнил мне, что исходная проблема заключалась не в зависимостях и информационных сообщениях, а просто в предупреждении о пакете, который нельзя установить на определенной платформе.

Итак, теперь действие для этого конкретного билета - просто понизить его с предупреждения до информации или отладки, поскольку это не добавляет ценности. Возражения? Другая часть перенесена в # 3869.

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

@jhabdas Я уже ответил в PR. Это моя философия qaru.site/questions/535 / ... откройте пул реквест и заранее спасибо :)

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

@jhabdas, насколько я ценю ваш вклад, я хотел бы напомнить вам наш кодекс поведения , в частности следующие пункты:

• Использование приветливого и инклюзивного языка
• С уважением относиться к различным точкам зрения и опыту
• Проявление сочувствия к другим членам сообщества

Мои искренние извинения. Я пересмотрю кодекс поведения и постараюсь стать хорошим гражданином сообщества. Спасибо, что указали мне правильное направление, @BYK.

Спасибо, что исправили это. 😍 🙇

Он был лучшие признан вопрос в НОМ с большим отрывом и вызвали реальные проблемы, но после 1,5 лет не ее решения их бота просто автоматически закрыл его за то , что слишком стар!

Такое управление проектами - одна из причин, по которой я перешел на Yarn.

Видя, насколько легко это исправить, мучительно, как много времени и усилий было потрачено на это. 😢

Благодаря!

Привет, спасибо за все усилия по этому поводу. Намного лучше, что теперь он будет на моем стандартном выводе вместо stderror;). Но все же даже информационный уровень приведет сюда массу людей. И единственный вывод, который они получат после одного часа чтения проблем, связанных с чтением, - это то, что им нужно жить с этим на данный момент (кто не использует babel), и что оптимизация платформы с помощью дополнительных зависимостей возможна, но с затратами предупреждения менеджеров пакетов для пользователя. Я за то, чтобы это выводилось только на уровне отладки.

@kubino , отличный отзыв, спасибо! Мы знаем, что перевод на info не исправит это раз и навсегда. Для этого @jhabdas фактически потратил некоторое время на то, чтобы сделать его еще лучше и универсальным, и представил RFC . Хотели бы вы оставить отзыв и сообщить нам, решит ли этот RFC вашу озабоченность?

@BYK, спасибо, что все еще интересуетесь этим. Я далек от того, чтобы быть экспертом, и, возможно, я ошибся. Вы указываете мне на RFC, где заголовок гласит: «Сделать предупреждения об устаревших подпакетах более информативными». Я думаю, что отправка пользователям УСТАРЕВШИХ предупреждений по умолчанию является правильной (хотя, вероятно, было бы неплохо иметь способ подавить определенные предупреждения пакета).
Меня беспокоили ДОПОЛНИТЕЛЬНЫЕ зависимости, которые служат просто оптимизацией для какой-то конкретной платформы, там я не вижу очень мало пользы от загрязнения окружающей среды, в противном случае такой прекрасный чистый результат Yarn. Но, как я уже сказал, я не эксперт и не уверен, всегда ли это так ясно, чтобы определить

@kubino не нужно быть экспертом. Вы знаете, что мир полон самопровозглашенных экспертов, поэтому лучше заявить, что вы не являетесь экспертом, и, возможно, вы в конечном итоге им станете 😀

В любом случае, у меня еще не было времени полностью прочитать этот RFC, но я думаю, что он попадает в раздел label = "Interoperability" . Тем не менее, возможно, нам следует добавить раздел optimization для этих случаев. Тем не менее, давайте продолжим обсуждение этого PR, и я думаю, вам следует сделать это предложение и посмотреть, что @jhabdas думает по этому поводу.

@kubino Я обновил описание

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

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

@BYK Я знаю, на что вы указываете;) Конечно, мне нужно согласиться с вами обоими @jhabdas , универсальное решение - единственный выход из этого обсуждения. Категоризация сообщений - это первый шаг, который позволит реализовать все остальное ... давайте продолжим обсуждение в соответствующем RFC. Благодаря!

Если это необязательно «для целевой ОС», то это не должно быть даже уровня WARN. Автор говорит: «Если MacOS использует FSEvents, иначе не используйте». Итак, если вы устанавливаете на ОС, отличную от Mac, зачем вообще предупреждать? Это больше похоже на информацию / отладку.

@robertjchristian Я думаю, здесь есть два аспекта:

1. fsevents Сам по себе должно выводиться предупреждение или ошибка. Некоторые пакеты, использующие fsevents могут зависеть от его API универсально (неправильно), не зная, что они предназначены только для macOS и нарушают работу других ОС в процессе.
2. Если fsevents предназначен для некоторых пакетов, необходимых только для macOS, эти пакеты должны иметь возможность помечать fsevents как не устанавливаемые вне macOS. Если не установить fsevents в macOS, это приведет к сбою, но в других ОС даже не будет попытки установить.

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

Да, это несколько раз объяснялось в исходной ветке, кажется, никто не слушал:

https://github.com/npm/npm/issues/11632#issuecomment -238217690

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

https://github.com/npm/npm/issues/11632#issuecomment -257214969

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

https://github.com/npm/npm/issues/11632#issuecomment -300804918

Вот что может сделать npm:

1. Измените необязательные зависимости и неподдерживаемые сообщения с WARN на INFO (чего хочет большинство людей).
2. Реализуйте зависимости от платформы (правильное решение)

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

  "conditionalDependencies": {
    {
      "condition": { "platform": "darwin" }, // 'darwin', 'freebsd', 'linux', 'sunos' or 'win32'
      "packages": { "fsevents": "^1.0.0" }
    }
  },

Другой вариант - для авторов нескольких событий:

Сделайте так, чтобы он не выходил из строя на платформах, отличных от OSX, без каких-либо предупреждений, просто сообщение INFO о платформе, не поддерживаемой

Но это не сильно отличается от скрытия предупреждения на уровне npm.

Все еще нет ответа? Это предупреждение так раздражает.

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

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

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

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

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

Это как если бы ваш партнер говорил вам, что он голоден, вы как готовите для себя, они не будут этого делать, вы готовите, они не будут есть, но продолжаете беспокоить вас, я голоден. Каждый раз, когда вы говорите привет (npm install / yarn), они говорят, что я голоден (WARN WARN WARN) .. Мне это кажется бессмысленным.

На этом этапе у меня возникает соблазн купить Mac с единственной целью - не видеть этого

Вы хотите сказать, что не увидите этого на Mac?
Что ж, вы этого не сделаете, если не воспользуетесь докером:

MacbookPro $ docker run -ti --rm node yarn add [email protected]
yarn add v1.13.0
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.

Думаю, вам больше повезет, если вы разветвите chokidar и удалите оттуда fsevents .
Недавний узел имеет большие улучшения по сравнению с встроенной поддержкой fs.watch в OS X.

Конечно, вам также придется форкнуть десятки пакетов в зависимости от chokidar.

Попробуйте пожаловаться здесь для разнообразия:
https://github.com/paulmillr/chokidar/issues

Думаю, вам больше повезет, если вы разветвите chokidar и удалите оттуда fsevents .
Недавний узел имеет большие улучшения по сравнению с встроенной поддержкой fs.watch в OS X.

Похоже, мы все- таки на

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

@Vanuan недавняя поддержка node.js для fs.watch все еще дерьмо. Попробуйте использовать его на разных платформах.

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

Это просто никогда не будет исправлено?