У меня есть следующая структура каталогов, использующая рабочие области пряжи :
package.json
tsconfig.json
packages/
a/
package.json // contains "name": "a" & "version": "1.0.0"
index.d.ts
b/
package.json
tsconfig.json
src/
index.ts
Внутри packages/b/tsconfig.json
некоторые очень основные правила:
{
extends:
compilerOptions: {
rootDir: src,
outDir: build
},
include: [ **/*.ts ]
}
Что я 'я пытаюсь выполнить импортирование определений, объявленных в packages/a/index.d.ts
в packages/b/src/index.ts
с помощью оператора, подобного import { Foo } from 'a';
.Я хочу сохранить index.d.ts
в своем собственном пакете, потому что у меня также есть пакет c
, использующий те же определения.
Без каких-либо изменений вышеприведенный запрос выдаст «Модуль не найден: Ошибка: не могу»устранить ошибку «а».Поэтому я попытался сделать следующее:
- Добавить
baseUrl: .
и paths: { a: [ ../a/index.d.ts ] }
, который теперь завершается с ошибкой «Ошибка сборки модуля: Ошибка: /path/to/packages/a/index.d.tsотсутствует в компиляции TypeScript. " - Do
yarn workspace b add a@1.0.0
, символьная ссылка node_modules/a -> packages/a
.Интересно, что это также привело к появлению «Модуль не найден: ошибка: невозможно разрешить« a »», пока я не добавил main: index.d.ts
к packages/a/package.json
, после чего я снова получил «Ошибка сборки модуля: Ошибка: / путь /в / packages / a / index.d.ts отсутствует в компиляции TypeScript. " - Добавьте
../../a/index.d.ts
к include
в packages/b/tsconfig.json
после выполнения 2., что приводит к тому же результату.Я предполагаю, что это потому, что на файлы вне rootDir
нельзя ссылаться в includes
. - Заменить
rootDir: src
на rootDirs: [ src, ../a ]
в packages/b/tsconfig.json
.Тот же результат.
У кого-нибудь есть идеи о том, как решить эти ошибки компиляции или полностью их избежать?Единственная стратегия, которая приходит мне в голову, - это создать запись .js в пакете a
, которая реализует интерфейсы index.d.ts
и экспортирует их как модуль, тогда как index.d.ts
объявляет определения для этого модуля.Но я бы предпочел оставить только общие интерфейсы, а не детали реализации, которые могут отличаться от пакета к пакету.