контекст
Рабочие пространства пряжи обеспечивают удобный способ зависеть от пакетов в моно-репо. Когда пакет A зависит от пакета B, интерфейсы и т.д., Определенные в пакете B, соответствующим образом разрешаются в пакете A.
проблема
Я столкнулся с проблемой, если пакет B зависит от внешней библиотеки, но в этой внешней библиотеке отсутствуют типизации, и поэтому пакет B создал свой собственный файл some-library.d.ts
. При использовании tslint
to lint package A этот файл настраиваемого определения правильно разрешен для выражений в пакете B, но не для выражений в пакете A, которые работают с типами из пакета B.
Я привел упрощенный пример этой проблемы:
https://github.com/tommedema/tslint-yarn-workspaces
Ядро этого заключается в следующем.
пакеты/а /SRC/index.ts
// tslint:disable:no-console
import { someDependedFn } from 'b'
export const someDependingFn = (): void => {
const someNr = someDependedFn('pascal-case-me')
console.log(someNr)
}
пакеты/б /SRC/index.ts
import camelCase from 'camelcase'
export const someDependedFn = (str: string): string => {
const camelStr = camelCase(str, { pascalCase: true })
return camelStr
}
пакеты/B/SRC/типизация /CamelCase/index.d.ts
// Type definitions for camelcase 5.0
// Project: https://github.com/sindresorhus/camelcase
// tslint:disable only-arrow-functions completed-docs
declare module 'camelcase' {
export default function camelCase(
strs: string | string[],
options: {
pascalCase?: boolean
}
): string
}
Теперь, если вы меняете каталог на пакет a
и запускаете yarn build
, это работает отлично. Но если вы запустите yarn lint
, это бросит:
$ tslint -p tsconfig.json
ERROR: packages/b/src/index.ts[4, 20]: Unsafe use of expression of type 'any'.
ERROR: packages/b/src/index.ts[6, 10]: Unsafe use of expression of type 'any'.
TSLint не распознает типизацию, зависящую от пакета B, но она только жалуется на это при запуске tslint из пакета A (не ожидалось). Внутри пакета B, tslint не жалуется (как и ожидалось).
Вопрос
Разумеется, я мог бы вручную добавить типовые camelcase
верблюжьей camelcase
внутри пакета A, но это похоже на очевидное нарушение разделения проблем: пакет A не должен знать, что пакет B зависит от упаковки на камбеле или X или Y. Предполагается, знать о публичном API пакета B, т.е. dependedFn
.
Как настроить tslint таким образом, чтобы он правильно разрешал эти косвенные определения ввода при использовании рабочих областей пряжи?