Использование разных версий зависимости в разных пакетах Yarn Workspace

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

Я хотел бы знать, можно ли использовать две разные версии зависимости (в моем случае TypeScript) в разных пакетах и ​​как это сделать.

Моя цель - заблокировать версию TypeScript (3.4.5) в пакете A и использовать корневую package.json версию TypeScript (3.5.0) для всех других пакетов в этом монорепозитории.

Это структура папок. В идеале PackageA будет использовать 3.4.5, а PackageB / PackageC будет использовать любую версию, определенную в корне package.json

|-- packages
    |-- packageA
    |-- packageB 
    |-- packageC
|-- package.json

Вот что я пробовал до сих пор:

Я попытался добавить nohoist в параметры моей рабочей области в конфигурации веб-пакета, но я не верю, что пакет A использует TypeScript 3.4.5, поскольку я не получаю ожидаемого результата. Когда я изменяю требование к корневой версии package.json TypeScript на 3.4.5, то есть когда я получаю правильный результат, было бы наилучшим сценарием, если бы я мог продолжать использовать последнюю версию TS для всех других пакетов, но сохранил более низкую версию для пакета A.

Я также пробовал добавить package.json в папку PackageA, где он определяет "typescript": "3.4.5" как devDependency. Yarn устанавливает нужную версию в папку PackageA, но, похоже, не использует ее.

Я также почти уверен, что Yarn resolutions также не подходит для этой ситуации, поскольку мои пакеты не определены как зависимости в моем package.json.

snippet of package.json
  "devDependenices: {
    ...,
    "webpack": "^4.34.0",
    "typescript": "3.5.0-rc",
    "yarn": "^1.15.2"
  },
  "workspaces": {
    "packages": [
      "packages/*"
    ],
    "nohoist": [
      "packageA/typescript"
    ]
  }

Если кому-то интересно, PackageA должен использовать TypeScript 3.4.5, потому что мне нужно react-docgen-typescript для анализа значений Prop, которые существуют в Prop, а не его родителя (т.е. атрибуты HTML на кнопке будут отображаться как prop). Вот ссылка на эту проблему.

Пожалуйста, дайте мне знать, если потребуется дополнительная информация для конфигурации моего проекта! Оцените понимание и советы :)


person Sherman Hui    schedule 09.07.2019    source источник
comment
Yarn installs the right version in the PackageA folder, but it doesn't seem to use it - значит, что касается пряжи, она выполнила то, о чем ее просили. Теперь вопрос в том, почему он, похоже, не использует его, то есть почему PackageA не использует машинописный текст, установленный в его собственном локальном node_modules, а вместо этого использует какую-то другую версию. Это похоже на вопрос о PackageA или другом инструменте, использующем машинописный текст в источниках PackageA, а не о рабочих пространствах yarn.   -  person artem    schedule 09.07.2019
comment
@artem я ценю комментарий! Знаете ли вы, есть ли способ подтвердить, какая версия зависимости запускается при запуске сценариев в корне проекта, определенного в корне package.json?   -  person Sherman Hui    schedule 09.07.2019
comment
Для машинописного текста использование параметра командной строки -v заставит его распечатать его версию, но больше ничего делать не будет. По другим скриптам - не знаю. В общем, если вы запускаете сценарий в корневом каталоге, он должен выбирать свои зависимости только из корневого node_modules. Если вам нужно запустить сценарий в контексте определенного пакета (рабочая область в терминологии пряжи), существует yarn workspace для этого.   -  person artem    schedule 09.07.2019
comment
Мне нравится, как все учебники похожи на ... просто используйте рабочие пространства пряжи! Но весь смысл настройки монорепозитория в том, что вам нужно поддерживать создание разных подпроектов с разными версиями зависимостей, но ни один из этих руководств не расскажет вам, как это сделать! Ха   -  person Otto    schedule 25.11.2020
comment
@ShermanHui Вы придумали решение?   -  person Praveen Alluri    schedule 30.11.2020


Ответы (1)


Согласно документации, вы должны добавить ** рядом с именем пакета, чтобы избежать подъема пакета. Ссылка на документацию здесь.
Чтобы избежать подъема только для машинопись:

"workspaces": {
"packages": [
  "packages/*"
],
"nohoist": [
  "packageA/typescript/**"
]

}

Чтобы избежать подъема для машинописного текста и его зависимостей:

"workspaces": {
"packages": [
  "packages/*"
],
"nohoist": [
  "packageA/typescript/**/**"
]

}

person ashr81    schedule 04.08.2020