推論された型の移植性エラーTS2742に挑む

推論された型の移植性エラー TS2742 に挑む TSKaigi 2025 LT @elecdeer | 1 of
20

elecdeer @elecdeerdev @elecdeer チームラボフロントエンド班 | 2 of 20

TS2742エラー見たことありますか？ | 3 of 20

The inferred type of 'returnValue' cannot be named without a
reference to ''../../middle-lib/node_modules/base-lib/dist/index.js'. This is likely not portable. A type annotation is necessary. ts(2742) 'returnValue' の推論された型には、'../../middle-lib/node_modules/base- lib/dist/index.js' への参照なしで名前を付けることはできません。これは、移植性がない可能性があります。型の注釈が必要です。ts(2742) ? | 4 of 20

実際の開発で見た例 -> 'meta'の推論された型には、'.pnpm/[email protected]/node_modules/csstype'への参照なしで名前を付けることはできません。 SomeComponent.stories.tsx で発生 | 5 of 20

どういうエラーなのか？ | 6 of 20

このエラーは何なのか https://github.com/microsoft/TypeScript/pull/58176#issuecomment-2052698294 が詳しい。 TypeScriptがd.tsファイルを生成する際に、間接的に参照される型を解決できない場合に発生する。 | 7 of 20

tscのd.ts出力を考える main middle-lib base-lib mainはbase-libには直接依存していない。いわゆる推移的依存関係（transitive dependency）パッケージの依存関係は以下のようになっているとする。 | 8
of 20

base-libとmiddle-libのd.ts base-lib/index.d.ts middle-lib/index.d.ts base-lib に依存している base-lib index.d.ts index.js middle-lib index.d.ts
index.js main index.ts export type SomeComplexType = { // （中身は余り関係無いが、単純すぎるとインライン化されるみたい） num: number; nest?: SomeComplexType; }; export declare const returnsInferredSomeComplexType: () => SomeComplexType; export declare const wrappedReturnsInferredSomeComplexType: () => import("base-lib").SomeComplexType; | 9 of 20

mainパッケージでの問題このコードをコンパイルしたとき、d.tsはどのように出力すべきか？ base-lib index.d.ts index.js middle-lib index.d.ts index.js main index.ts
index.d.ts mainパッケージで以下の様なコードを書いたとする。 import { wrappedReturnsInferredSomeComplexType } from "middle-lib"; export const mainValue = wrappedReturnsInferredSomeComplexType(); // ^| base-libの型SomeComplexTypeに推論されるが... import { wrappedReturnsInferredSomeComplexType } from "middle-lib"; export const mainValue: ???; | 10 of 20

ダメな例 mainパッケージ基準の相対パスで指定 middle-libの内部ディレクトリを参照 -> node_modulesの構造はパッケージマネージャによって異なるのでNG 大まかには、hoistingするかどうかで変わる import { getBaseLibValue }
from "middle-lib"; import type { SomeComplexType } from "../node_modules/middle-lib/node_modules/base-lib/index.js"; export const mainValue: SomeComplexType; import { getBaseLibValue } from "middle-lib"; import type { SomeComplexType } from "middle-lib/node_modules/base-lib/index.js"; export const mainValue: SomeComplexType; | 11 of 20

これは…? 一見よさそうに見えるが、middle-lib --> base-libとmain --> base-libの指す先が同じとは限らない別のバージョンに依存していた場合は、実装と型が乖離して壊れる可能性がある main middle-lib
base-lib@1 base-lib@2 -> 移植性がないとして TS2742 エラーを発生させる import { getBaseLibValue } from "middle-lib"; import type { SomeComplexType } from "base-lib"; export const mainValue: SomeComplexType; import { wrappedReturnsInferredSomeComplexType } from "middle-lib"; import type { SomeComplexType } from "???"; // 無理！！！ export const mainValue: ???; // 無理！！！ | 12 of 20

どうするべきなのか | 13 of 20

ユーザ側（main）の対策エラーの言うとおり、型注釈を明示的に書く … 型の注釈が必要です。ts(2742) これで解決!..🤔 型推論が便利なときは書きたくない… あと単に冗長 import { wrappedReturnsInferredSomeComplexType
} from "ref"; export const returnValue: ReturnType< typeof wrappedReturnsInferredSomeComplexType > = wrappedReturnsInferredSomeComplexType(); const validator: () => { name: string } = createValidator( // ^ ここは書きたくないわけで z.object({ name: z.string() }), ); | 14 of 20

ユーザ側（main）のworkaround tsconfigの declaration を false にする有効なd.tsを出力できないからエラーになっているので、そもそも出力しなければエラーにならない直接依存に追加してimportする import type
{} from "base-lib" をmainのどこかに書くコンパイル対象のどこかに base-lib への参照があれば、それと同じ先に解決されるライブラリ側が依存しているバージョンと別のバージョンに解決してしまう可能性があるので要注意 TS5.5以上に上げてみる Consulting package.json Dependencies for Declaration File Generation TS5.4以前でTS2742エラーが発生している場合、偽陽性かもしれない後述の対策をpnpm patch | 15 of 20

ライブラリ側の修正の方が望ましい | 16 of 20

そもそもとして mainのd.ts出力で、こうできれば万事解決である -> middle-libからSomeComplexTypeが再exportされていればよい 😸 import { getBaseLibValue, SomeComplexType }
from "middle-lib"; export const mainValue: SomeComplexType; | 17 of 20

ライブラリ側の実装で事前に気づくことはできるのか tsconfigの isolatedDeclarations を有効にするダメなパターンを実装しにくくなる全てのパターンを防げるわけでは無さそう？明示的な型指定が強制されるので、大抵の場合はライブラリ側でエラーになる不適切なビルドを修正する本来ライブラリ側でTS2742エラー（あるいはTS4023）が出るはずなのに、すり抜ける事がある package.jsonのexportsやesm/cjs問題も影響していそうだが、正直よく分からない
tscの出力をそのままpublishしていないライブラリでありがち？ arethetypeswrong でチェックしてみる https://github.com/microsoft/TypeScript/issues/47663#issuecomment-1519138189 も参考に -> TS5.8時点では完全なチェックはできないが、ある程度防ぐ方法はある | 18 of 20

まとめ TS2742 は間接的な依存関係の型を解決できないときに発生するライブラリ側で再exportするのが望ましいユーザ側でのworkaroundもあるが、その方が健全 TS2742が出る再現例 https://github.com/elecdeer/ts2742-error 参考になるissueとか https://github.com/microsoft/TypeScript/pull/58176#issuecomment-2052698294 https://github.com/microsoft/TypeScript/issues/47663#issuecomment-1519138189
https://github.com/microsoft/TypeScript/issues/48212 | 19 of 20

We’re Hiring! TypeScriptを共に書いてくれるメンバーを募集中です！サマーインターンシップも応募受付中！ www.team-lab.com/recruit | 20 of 20

推論された型の移植性エラーTS2742に挑む

推論された型の移植性エラーTS2742に挑む

teamLab PRO

More Decks by teamLab

Other Decks in Programming

Featured

Transcript