<p>yarn, вероятно, не должен кэшировать пакеты, разрешенные с помощью пути к файлу</p>

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

Я думаю, что есть три способа сделать пряжу пригодной для этого случая:

1. Предложение @donaldpipowitch игнорировать все локальные зависимости.
2. Переустановка локальных зависимостей, если файл там был изменен позже, чем когда он был кэширован. Это потребует от нас сохранить эти метаданные. Для локальных зависимостей мы можем вставить такие строки в столбец «Решено»: file://<path>@<cache_timestamp>
3. Игнорирование пакетов по именам пакетов с такими командами, как yarn cache rm <package> и yarn cache add <package> . Для всех зависимостей.

Я бы хотел, чтобы второе предложение было реализовано. Разве что третий вариант может быть полезен и для других случаев. Например, yarn cache add <package> можно использовать для обновления кеша для уже кэшированных зависимостей на случай, если что-то может пойти не так при загрузке зависимости.

@hantuzun, зачем

@ satya164 ты прав. Хотя, я больше склоняюсь к третьему подходу, который поможет, если зависимость от сети будет изменена намеренно.

Что-то вроде yarn cache ignore <package> будет полезно. Но я думаю, что они не должны быть взаимоисключающими. Игнорирование пакета полезно, но требует ручной работы. Файловые зависимости можно было бы заставить работать без каких-либо дополнительных усилий, если бы они игнорировались по умолчанию.

Может кто-нибудь объяснить мне внутреннюю логику?

Мое понимание:
Когда встречается зависимость с file: включается file-resolver.js . В нем говорится, что зависимость должна быть скопирована и не хешируется . Разве отсутствие хэша не означает, что его уже не следует кэшировать ...? Но copy-fetcher.js похоже, устанавливает хеш в пустую строку вместо сохранения null ... Это проблема?

@bestander или @kittens Может быть, вы могли бы объяснить это немного подробнее ...? Хотел бы получить небольшую помощь в создании пиара ♥

Хеш означает, например, хеш md5, который используется для сборщика архивов.
Затем этот хеш добавляется в файл yarn.lock для будущих проверок, а также добавляется к имени папки при сохранении распакованной папки в кеше.
Вы копаете в правильном направлении, спасибо, что разобрались, пиар очень приветствуется.
Вероятно, вы можете начать с PR, который добавляет неработающие модульные тесты

Вероятно, вы можете начать с PR, который добавляет неработающие модульные тесты

Хорошо, спасибо за ответ. Должен ли я пинговать вас как рецензента в PR или я должен пинговать кого-то еще (или никого) ...?

Да, пинги меня

@bestander, наверное, эту проблему не следует закрывать, так как она еще не исправлена?

Да, его нужно снова открыть. Он был закрыт, потому что я написал «fixes # 2165» в заголовке своего PR. Вначале я думал, что это будет постоянный PR, но, чтобы исправить эту ошибку, нам нужны два PR: первый добавляет модульный тест (утверждение, которое не сработает, на самом деле не активно, поэтому CI не взрывается) и второй действительно исправит это.

Извините, github закрывает проблемы при объединении PR

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

редактирование содержимого моего пакета eslint-config-base-eslint

yarn cache clean && rm -rf node_modules/eslint-config-base-eslint && yarn install --force && yarn lint

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

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

К вашему сведению: Возможно, эта проблема также актуальна для медленных шагов linking dependencies . Смотрите мой комментарий здесь: https://github.com/yarnpkg/yarn/issues/1496#issuecomment -282688818.

Сожалею. У меня не было времени создать еще один пиар по этой проблеме :( Я был (и остаюсь) очень занят.

@bestander Это довольно большой блокировщик для меня, работая над многомодульным проектом. Если я правильно читаю ссылки и комментарии кода hash (вместо null) каждый раз, когда он пытается разрешить, чтобы принудительно выполнить переустановку? Назовите UUID или текущую отметку времени? Простите, если я что-то упускаю, я не знаком с тем, как работает код.

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

Во вторник, 7 марта 2017 года, в 03:38, Мэтт Трейнхэм [email protected] написал:

@bestander https://github.com/bestander Это довольно большой блокировщик
для меня работа над многомодульным проектом. Если я читаю @donaldpipowitch
Ссылки и комментарии кода https://github.com/donaldpipowitch
правильно, может ли файловый преобразователь создать новый хеш (вместо
null) каждый раз, когда он пытается разрешить, поэтому он вызывает переустановку? Произнесите UUID
или текущая отметка времени? Простите, если я что-то упускаю, я не знаком
с тем, как работает код.

-
Вы получаете это, потому что вас упомянули.

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

@bestander Относительно вашего последнего комментария: разве не было бы больше смысла использовать символическую ссылку вместо копирования файлов? Или есть причина не делать этого?

Окна @danrot, похоже, требуют от администратора символической ссылки.
также он мешает рекурсивному поиску узловых модулей

Symlink также игнорирует .npmignore и тому подобное. (Что в настоящее время, похоже, тоже игнорируется. Что может быть проблематичным: https://github.com/yarnpkg/yarn/issues/1496#issuecomment-282688818)

Есть ли какое-либо обходное решение для этого запрета на очистку всего кеша? К сожалению, похоже, что нет команды yarn cache rm package kind-of.

@ rhys-e Я использую этот небольшой скрипт:

#!/bin/sh
if [ $# != 1 ]
then
   echo Usage $0 package-name
   exit 1
else
    echo Reinstalling $1
fi

dir="node_modules/$1"

if [ -d $dir ]
then
    rm -fr $dir
fi

cache=`yarn cache dir`/npm-${1}*
#        echo $cache
rm -fr $cache && yarn install --force

Кто-нибудь пробовал просто yarn link все локальные зависимости от postinstall ? Похоже, подходящее решение, пока не появится правильное решение.

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

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

Ссылка @lucdew в основном создаст символическую ссылку под капотом, что означает, что будет использоваться последняя локальная версия. Но я думаю, что наличие скрипта, который перед установкой очищает кеш от определенных deps, является правильным решением прямо сейчас.

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

yarn cache clean; yarn upgrade file:../<package>

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

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

Для # 2860 и последующего коммита слияния https://github.com/yarnpkg/yarn/commit/7241de13bb236526fa439a2528fbed319f60ef24 теперь вы можете «обновить» зависимости протокола file: с помощью

yarn install --force

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

yarn upgrade [file protocol package name]

Изменение PR сделает недействительной зависимость в кеше и переустановит ее локально. yarn install также будет работать, если версия зависимостей изменилась, что делает недействительным файл yarn.lock. Вам больше не нужно ни очищать кеш, ни удалять модуль из локальной установки.

Мне также стало очевидно, что существует активный RFC для связывания зависимостей, возможно, с протоколом link: . За этим можно следить здесь, https://github.com/yarnpkg/rfcs/pull/34.

@mtraynham Спасибо за ваш запрос на --force ? В настоящее время я даже не знаю, что именно он делает прямо сейчас, не глядя :) Просто спрашиваю, потому что npm не нужен флаг --force и было бы неплохо вести себя как npm.

Изменить Похоже, что yarn upgrade [dependency] тоже работает. Хочу отметить, что это не всегда меняет файл блокировки, который должен отражать только изменения версии package.json. Я обновил свой исходный пост, так как обновление, вероятно, более уместно.

Краткая версия: Yarn ничего не сделает с распознавателями кеша, если файл блокировки не изменился, поэтому нам нужно пропустить проверку файла блокировки и спросить кеш, есть ли более новая версия. Это можно сделать с помощью upgrade или install --force

За yarn install --force документацию

«обновляет все пакеты, даже те, которые были ранее установлены».

Это действительно означает, что он пропустит проверку целостности файла блокировки. Проверка целостности файла блокировки обычно проходит, если вы не изменяете файл package.json и не выполняете аварийную остановку. Пропуск этого требует, чтобы кеш проверил отсутствующие / несовпадающие зависимости с файлом блокировки, загрузил их, если они отсутствуют, и скопировал обратно любые новые / отсутствующие зависимости локально. Затем он запускает сценарии npm install / postInstall .

Изменение PR теперь аннулирует зависимость file: в кэше и копирует новую версию локально. До этого он никогда не отменял бы зависимость file: . Для других протоколов, если вы не меняли файл package.json, они останутся без изменений (в кеше и локально).

Так что это значит для нас? У меня около 60 зависимостей от проекта (от Angular до Webpack) с одной зависимостью file: . Во втором install --force , где я хочу обновить только локальную зависимость, это занимает около ~ 5 секунд (по сравнению с ~ 1.5 секунды для yarn install ). Для меня это довольно незначительно, и я на самом деле очень впечатлен тем, как мало работы Yarn пытается выполнить на протяжении всего процесса.

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

Как бы то ни было, я бы назвал это пластырем. Его можно заменить лучшим решением, например link: ; Я не думаю, что кому-то действительно нужно кешировать локальные зависимости. По крайней мере, дополнительные накладные расходы при использовании install --force или upgrade в основном являются небрежными, и вам больше не нужно yarn cache clean; mv node_modules /tmp/ .

Отличный ответ. 👏 Спасибо, что записали это.

Записывает ли yarn локальные файлы проекта с символической ссылкой на файлы из кеша yarn? (потому что похоже, что это происходит)

Изменение PR теперь аннулирует зависимость file: в кэше и копирует новую версию локально.

Означает ли это, что всякий раз, когда я вызываю $ yarn внутри пакета, который имеет "foo": "file:../" в качестве зависимости, будет создана новая копия "file:../" ?

Например, у меня есть пакет с несколькими примерами, которые также являются пакетами:

foo/
foo/examples/
foo/examples/example-1/
foo/examples/example-2/
foo/examples/example-3/
...
foo/examples/example-10/

И похоже, что у меня foo 10 раз в кеше пряжи. Я также тестирую свои примеры при каждом изменении версии foo (и у меня есть несколько модулей, настроенных таким образом, а не только foo ), поэтому похоже, что мой кеш пряжи в настоящее время растет _ действительно_ быстро.

Это правильное поведение?

Я думаю, что это лучшая альтернатива, чем наличие устаревшей версии в вашем кеше.
С yarn 0.26 вы можете использовать link: для создания символических ссылок вместо копирования файлов.
Также мы работаем над рабочими пространствами, которые автоматизируют создание символических ссылок, https://github.com/yarnpkg/yarn/issues/3294

Да, с нетерпением жду рабочих мест 👍

link: еще не работает с npm, верно? (Потому что https://github.com/npm/npm/pull/15900 все еще открыт.)

Начиная с патча npm 5 , файлы теперь автоматически связываются символическими ссылками с синтаксисом file: :

npm install ./packages/subdir теперь будет создавать символическую ссылку вместо обычной установки. file: //path/to/tarball.tgz не изменится - только каталоги имеют символические ссылки. (# 15900)

Так что да, с npm нет link .

npm install ./packages/subdir теперь будет создавать символическую ссылку вместо обычной установки

Довольно прискорбно. File deps никогда не вел себя одинаково из-за копирования всего (включая node_modules ) и несоблюдения поля .npmignore или files . Теперь с символической ссылкой хуже.

Я думаю, что file: и link: можно было бы еще улучшить, существуют разные стратегии, у которых есть свои ЗА и ПРОТИВ, и Yarn должна позволить людям выбрать один.
Например, knit RFC может быть реализован как одна из стратегий https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-yarn-knit.md

@bestander

Я думаю, что это лучшая альтернатива, чем наличие устаревшей версии в вашем кеше.

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

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

@nikdojo Используйте link: для зависимостей вместо file: , он использует символические ссылки. Он был представлен в версии 0.26 .

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

@mtraynham Спасибо за подсказку, я пытался найти какую-либо информацию о протоколе link: в официальных документах, но, похоже, ее там нет. Сейчас экспериментируем с рабочими пространствами.

@bestander Кстати, как вы знаете,

Это так и не было решено, не так ли? Вы должны использовать linklocal (пакеты NPM) для связывания локальных пакетов (что должно быть стандартным способом работы yarn при использовании пакетов из локальной файловой системы - с использованием соединений или символических ссылок в Windows вместо кеширования). Новый yarn install затем перезаписывает все старым материалом из кеша, и вам придется снова начинать связывание.

Можем ли мы быть менее архитектурным астронавтом и просто не кэшировать локальные пакеты? Этой проблеме уже 1,5 года, и я устал запускать yarn add ../<another-local-package> каждый раз, когда что-то меняю в another-local-package .

Привет @fungilation
Я открыл еще одну связанную проблему: # 6037

не работает
Я положил в файл App.js
console.log («вот и мы»), и он не выводился.
затем удалите все файлы, и он все равно будет выводить данные из кеша.
Как этого избежать?

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

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

Я пытался:

1. Очистка кеша пряжи ( yarn cache clean package-name )
2. yarn add 'с --force
3. Повторное удаление node_modules/package-name и yarn add ing
4. Обновление номера версии и имени файла локального пакета ( yarn по-прежнему устанавливает содержимое старой версии , хотя сообщает об установке более новой)
5. Комбинации всего вышеперечисленного

Это смешно, и я потратил на это почти 4 часа в день.

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

@ Yarn Developers: можете ли вы установить локальный пакет, внести изменения в этот локальный пакет, а затем отразить эти изменения путем повторной установки?

@gregjacobs Я добился успеха с yarn install --force

@jonathantorley Я просто попробовал еще раз с --force но он все еще не работает с пряжей 1.12.3

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

yarn определенно не требует этого обходного пути при установке локальных пакетов

Я добавил yarn upgrade MY_PACKAGE_NAME в сценарий preinstall , и он хорошо обновляется до последней версии NPM. (Тем не менее, мне нужно вручную поднять версию NPM).

Кажется, yarn add file:PATH теперь всегда обновляют новый контент в пряжи 1.13.0.
yarn install прежнему нет.

@leavesster По-прежнему не для меня.

Мне нужно переименовать tgz, чтобы он обновился

Попробуйте использовать команду link : https://yarnpkg.com/lang/en/docs/cli/link/

yarn add file:PATH не обновлял для меня новый контент. Более того, файлы в package.json и .npmignore не соблюдаются.

Это работает, если вы измените версию вашего пакета.

Если вы хотите, чтобы yarn add file:PATH уважал файлы в package.json и .npmignore, вы должны запустить yarn pack в зависимости вашего локального пакета, а затем, где вы хотите его установить, запустите yarn add file:path-to-local-pacckage.tgz

Попробуйте использовать команду link : https://yarnpkg.com/lang/en/docs/cli/link/

yarn link не предназначен для решения той же проблемы. Это нехорошо, если кому-то нужен пакет npm, как если бы он был опубликован с учетом файлов в package.json и .npmignore

@leavesster По-прежнему не для меня.

Мне нужно переименовать tgz, чтобы он обновился

У меня нет tgz в моем пакете, который я использую yarn add file: PACKAGE_PAH чтобы добавить его в текущий проект. У меня в пакете есть только js-код. Может, тгз все-таки ошибается?

у меня тоже не работает

@bestander, почему этот вопрос закрыт? Пряжа все еще кеширует локальные файлы и пакеты tgz. Рабочие области не являются решением в некоторых случаях, например, если один пакет имеет зависимости с определенными версиями, а другой пакет имеет devDeps те же пакеты, что и первый, но с другими версиями, и если вы связываете один пакет с другим, ваш проект не работает .

У меня такая же проблема, как у @gregjacobs. yarn cache clean package не помогло. Но я понял, что если вы установите yarn add path/to/package.tgz а затем замените архив на другой, вы можете установить новую версию, просто изменив путь, например yarn add path/to/../to/package.tgz , поэтому абсолютный путь такой же, но для пряжи его другой .

Я не понимаю, где еще пряжа хранит кешированные пакеты по пути разрешения, даже yarn cache list --pattern package пуст.

Я думаю, проблема где-то здесь https://github.com/yarnpkg/yarn/blob/eb2b565bb9b948e87b11119482ebc184a9d66141/src/resolvers/exotics/tarball-resolver.js#L58 -L63

Что творится:

• Из url path/to/package.tgz генерирует хеш (поэтому path/to/package.tgz и path/to/../to/package.tgz результаты в разные хеши)
• С помощью этого хеша создается временный каталог для пакета (например, этот /Users/kich/Library/Caches/Yarn/v4/.tmp/c019816ee7d10ed5e1fef4072e8cc617 )
• При первом запуске isValidModuleDest return false и все идет хорошо
• Пакеты tarball, извлеченные в этот каталог
• Файлы из этого каталога, установленные в проект
• Вы изменяете исходники проекта разработки и собираете / упаковываете новый архив пакета с тем же именем и расположением, что и предыдущий.
• И вы пытаетесь установить новый архив, но сгенерированный хэш такой же, как и раньше, а временный каталог не был очищен после первого запуска
• Итак, в этот раз isValidModuleDest return true
• И пряжа установить старую версию вашего пакета
• Вы запускаете yarn cache clean package , но временный каталог остается нетронутым

@bestander, можем ли мы просто удалить временный каталог здесь https://github.com/yarnpkg/yarn/blob/master/src/config.js#L431 ?

Столкнувшись с той же проблемой, кеш в папке temp занимает 10 ГБ после того, как я работаю на моем локальном пакете всего один день!

Можем ли мы снова открыть эту проблему? Мы сталкиваемся с той же проблемой. Два проекта ссылаются на другой пакет через файл:. После некоторых сборок на нашем CI / CD-сервере папка кэша начинает занимать много места.

Я думаю, что протокол связи - лучшее решение для этого, file: // не работает, так как он по-прежнему требует ручной очистки кешей и принудительной установки

https://github.com/yarnpkg/yarn/issues/2165#issuecomment -345825904

просто сделайте свою зависимость примерно такой

"<package>": "link:./libs/<package>"

@alxtz работает ли протокол ссылок с пакетами в tgz?

Я думаю, что протокол связи - лучшее решение для этого, file: // не работает, так как он по-прежнему требует ручной очистки кешей и принудительной установки

# 2165 (комментарий)

просто сделайте свою зависимость примерно такой

"<package>": "link:./libs/<package>"

Спасибо за это, это повторяет поведение NPM, который будет символизировать ссылки file:.. в node_modules . Похоже, что это не задокументировано, по крайней мере, не здесь, где я ожидал бы найти его: https://yarnpkg.com/lang/en/docs/package-json/

К сожалению, link нельзя использовать во всех случаях.

Например, мне нужна общая / одноранговая зависимость от моего пакета SDK, который, когда я вношу изменения, я буду ссылаться на работу локального разработчика.
С link yarn не понимает, что зависимость является общей / одноранговой зависимостью, и использует локальный пакет, где находится символическая ссылка, что неверно.

Я использовал yarn pack вместе с yarn add file:<path_to_packed_tgz> чтобы обойти это.
Хотя я могу продолжать переименовывать пакет каждый раз, когда упаковываю его и вставляю в свое репо, чтобы не генерировать тот же хеш, согласно фантастической находке @wKich , это чертовски раздражает.

Я раздвоил репо и добавил в оператор if дополнительное предложение, чтобы yarn никогда не загружала локальный пакет .tgz из своего кеша, если он указан с помощью yarn add file:<path> .

const dest = this.config.getTemp(crypto.hash(url));
// If specified using file: never load from cache
if (!url.match(/file:/) && (await this.config.isValidModuleDest(dest))) {
  // load from local cache
} else {
  // continue as if it's a new package
}

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

@ojboj сейчас, yalc может помочь, пока это не будет исправлено. Мне очень хорошо удалось протестировать пакеты локально перед публикацией.

@souporserious Это именно то, что мне нужно / хотелось, спасибо вам большое!

Безумие, это все еще проблема после стольких лет.

Это исправлено в [email protected]?

@wKich Я так считаю! Я лично не тестировал его, но похоже, что они решают локальную разработку через новый протокол портала .

Я по-прежнему получаю ошибку «распаковать в том же месте назначения», используя протокол link: , и он ссылается на мой каталог кеша, поэтому мне кажется, что yarn все еще кэширует зависимости link: . Я ссылаюсь на 2 копии одного и того же локального пакета, скопированные в папку .deps/ каждого приложения, которое его использует - front-end и renderer в приведенной ниже ошибке. (Не могу ссылаться на оригинал по не связанным причинам)

warning Pattern ["@horizon/common<strong i="11">@link</strong>:packages/front-end/.deps/@horizon/common"] is trying to unpack in the same destination "/home/garyo/.cache/yarn/v6/[email protected]/node_modules/@horizon/common" as pattern ["@horizon/common<strong i="12">@link</strong>:packages/renderer/.deps/@horizon/common"]. This could result in non-deterministic behavior, skipping.