Рабочие области пряжи - псевдоним пакета

Question

TL; DR Как я могу создать псевдоним для зависимости локальной рабочей области пряжи?

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

Я установил "workspaces": ["packages/*"] в package.json.

Для каждого пакета я решил использовать соглашение об именах @-/package-name, чтобы предотвратить конфликты имен и не беспокоясь о пространствах имен для внутренние пакеты.

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

"dependencies": {
  "my-interface-name": "file:some/path/to/packages/some-concrete-implementation"
}

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

Однако я не могу понять, как sh это сделать с помощью рабочих пространств yarn. Как создать псевдоним для моего пакета рабочих областей пряжи @-/some-concrete-implementation с именем my-interface-name?

То, что я уже пробовал безуспешно:

• Определение зависимости, например "my-interface-name": "@-/some-concrete-implementation"} - по какой-то причине yarn ищет @-/some-concrete-implementation в реестре npm, а не в локальной рабочей области
• Я также пробовал использовать протокол рабочей области: "my-interface-name": "workspace:@-/some-concrete-implementation"}, но он все равно выглядит для пакета в реестре npm!

То, что я еще не пробовал и может сработать, но устраняет преимущества использования рабочих пространств пряжи в первую очередь:

• "dependencies": {"my-interface-name": "file:../../node_modules/@-/some-concrete-implementation"}"

Answer 1

Вы видели пакет resolutions. json ключ ? Это то, что вам нужно?

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

Разрешения

Позволяет переопределить версию конкретной вложенной зависимости. См. Выборочные версии Разрешения RF C для получения полной спецификации c.

{
  "resolutions": {
    "transitive-package-1": "0.0.29",
    "transitive-package-2": "file:./local-forks/transitive-package-2",
    "dependencies-package-1/transitive-package-3": "^2.1.1"
  }
}

Из RF C:

«** / a» обозначает все вложенные зависимости a проекта.

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

Итак, я считаю, что правило need is:

"**/my-interface-name": "file:some/path/to/packages/some-concrete-implementation"

// OR equivalent

"my-interface-name": "file:some/path/to/packages/some-concrete-implementation"

Я считаю, что он работает в пакете package. json. В худшем случае вы можете поднять его в рабочую область root и сделать указанное правило c в рабочей области, например, «a / b».