TypeScript 6.0で非推奨化されるオプションたち

2025-11-23 TSKaigi Hokuriku 2025

Transcript

1. TypeScript 6.0で非推奨化され るオプションたち 2025-11-23 TSKaigi Hokuriku
2. 発表者紹介 uhyo 株式会社カオナビ フロントエンドエキスパート TypeScriptにtype宣言が無かったころから 使っている。 2
3. TypeScriptの最近の動き TypeScriptのネイティブ版（tsgo）の準備は 着々と進んでいる。 ネイティブ版はバージョン7.0としてリリース される見込み。 3
4. 次のTypeScriptバージョン 7.0とは別に、次期バージョンとして6.0も準備 されている。 （現在の最新版は5.9） 6.0は、ネイティブ版に向けた準備のための バージョンという側面が大きく、機能追加などは 限定的。 4
5. 次のTypeScriptバージョン 最新情報では、6.0は2026年1月～2月リリースを 目指しており、7.0はその約1か月後。 参考: https://github.com/microsoft/TypeScript/issues/62785 5
6. This Talk 6.0ではネイティブ版への準備として、 古いオプションの非推奨化が予定されている。 6.0で非推奨化されたオプションは、7.0では実装 されない（廃止）。 今回は、そんな将来廃止予定のオプションを 解説します。 6
7. でもその前に…… TypeScriptのバージョニング の歴史 7
8. 大前提 TypeScriptはセマンティックバージョニング ではない。 5.0はなぜ5.0なのか？ 4.9の次のバージョンだから。 8
9. 大前提 「あ～TypeScript 5系が出たのか。 うちは4.9だから破壊的変更チェックしなきゃ」 → 違います。4.8→4.9と同じ感覚でアップデート していいです。 9
10. 初期のX.0の扱い 初期では、X.0を「大きめの特別なリリース」とし て扱っていた。 2.0はstrictNullChecksなど大きな改善があり、 1.9を飛ばして1.8→2.0となった。 10
11. 3.0以降は完全に普通のバージョン TypeScript 2.xの間に現在に近いリリースサイクル が確立。 リリースも定期的（3ヶ月に1回）になり、 X.0は単なる桁の繰り上がりでしかなくなった。 11
12. 5.0: deprecationの登場 TypeScript 5.0は、deprecationサイクルの概念が 登場したリリース。 古いオプションの廃止が始まった。 サイクルの開始バージョンという若干の特別性。 参考: https://github.com/microsoft/TypeScript/issues/51000 12
13. 5.0のdeprecationサイクル 5.0: 指定すると警告が発生。警告を無視するため にignoreDeprecationsを指定可能 5.5: 指定しても何も起きない（エラーにならないが、 オプションの効果はない） 6.0: 完全廃止（存在しないオプションを指定するとエ ラー） 13
14. そして6.0 6.0は、5.0のサイクルを完遂して次のサイクルが 始まるバージョン。 完遂は7.0となり、一応このサイクルに則って行う ことになっている。 （ただ、6.1～6.9を律儀に全部リリースするのかは不明。 しばらく6系もメンテするという情報はある） 14
15. 本題: 6.0で非推奨化される オプションたち 15
16. なぜ非推奨化するのか もう需要がない古いオプションを非推奨化すると いう方針は変わらない。 さらに、ネイティブ版に移植するコードを減らす という意図もありそう。 参考: https://github.com/microsoft/TypeScript/issues/54500 16
17. ご注意 このトークの情報は、GitHubのissue等から得ら れる公式情報をもとにまとめています。 あくまで予定のため、実際のリリース時には内容 が変化する可能性があります。 17
18. ①target: es5 •ES5へトランスパイルする機能の廃止 •型定義としての lib: [“es5”] は存続らしい •最小ターゲットはes2015に変更 18
19. target: es5 why? ES2015をサポートしていない環境はもうあまり 実用されていない。 どうしてもES5が必要なら他のツールもある。 19
20. ES5へのトランスパイルは大変 最近の構文に比べると、ES2015は大がかりな トランスパイルが必要になる機能が多め。 （最近でもusingとかはトランスパイルが大変だが……） 20
21. ES5へのトランスパイルは大変 トランスパイル前: function sum(nums: readonly number[]) { let sum = 0; for (const v of nums) { sum += v; } return sum; } 21
22. ES5へのトランスパイルは大変 トランスパイル後: function sum(nums) { var e_1, _a; var sum = 0; try { for (var nums_1 = __values(nums), nums_1_1 = nums_1.next(); !nums_1_1.done; nums_1_1 = nums_1.next()) { var v = nums_1_1.value; sum += v; } } catch (e_1_1) { e_1 = { error: e_1_1 }; } finally { try { if (nums_1_1 && !nums_1_1.done && (_a = nums_1.return)) _a.call(nums_1); } 22
23. ES5へのトランスパイルは大変 トランスパイル前: function* getMenuItems(user: User) { yield "Home"; yield "Search"; if (user.isAdmin) { yield "Admin"; } yield "Settings"; } 23
24. ES5へのトランスパイルは大変 トランスパイル後: function getMenuItems(user) { return __generator(this, function (_a) { switch (_a.label) { case 0: return [4 /*yield*/, "Home"]; case 1: _a.sent(); return [4 /*yield*/, "Search"]; case 2: _a.sent(); if (!user.isAdmin) return [3 /*break*/, 4]; return [4 /*yield*/, "Admin"]; case 3: _a.sent(); _a.label = 4; case 4: return [4 /*yield*/, "Settings"]; case 5: _a.sent(); return [2 /*return*/]; } }); 24
25. target: es5に関連するオプション downlevelIteratorもあわせて非推奨化。 （ES5へのトランスパイル時の動作を指定する オプションのため） 25
26. targetの新しいデフォルト値 従来のデフォルト値もes5だったが、 リリース時点の最新版が新しいデフォルト値に。 （今リリースしたらes2025） ただし、tsc --initで作成されるtsconfig.jsonの初期状 態は”target”: “esnext”になっている。 26
27. domとdom.iterable lib target: es5の廃止に合わせ、libで指定される domとdom.iterableは実質的に統合される。 （dom.iterable: DOMの型定義のうち、 イテレータ関連のものを抜き出したもの） 27
28. ②outFile •outDirではなくoutFileを指定すると、ファイル ごとに.jsを出力するのではなくプロジェクトの ファイルを1つに統合した.jsを出力する。 •原始的なバンドラみたいな機能 •CommonJSやESMとは組み合わせられない 28
29. outFile why? バンドラでいい。 CommonJSやESMと組み合わせられない時点で、 需要もあまり無い。 実装も削減できる。 29
30. ③いくつかのmodule値 •module: amd, umd, systemjs •ES Modulesの記法をこれらのモジュールシステ ムに変換して出力する 引き続き指定できる値: none, commonjs, es2015, es2020, es2022, esnext, node16, node18, node20, nodenext, preserve 30
31. いくつかのmodule値 why? TypeScriptの開発当初に比べてAMDやSystemJS 自体の需要が減少している。 変換先が減ることはやはり実装の削減に貢献。 31
32. ④moduleResolution: classic •モジュール解決の方式を指定する。 •classicはCommonJSより前の何か 引き続き指定できる値: node10 (node), node16, nodenext, bundler 32
33. moduleResolution: classic why? npm文化となり、大体のランタイムがNode.jsと同様の モジュール解決をするようになった。 （“react” → ./node_modules/react のような基本ルール、 package.jsonのexports フィールドのサポートなど） ただ、Node.jsのESMは拡張子が必要でNode.js 以外と異なるので、そちらに合わせたbundlerが 登場している。 33
34. ⑤esModuleInterop, allowSyntheticDefaltImports •__esModuleに対応したemitをするオプション • ESMからトランスパイルされたCommonJSモジュー ルを示すマーカー •esModuleInterop: true の挙動に統一され、 オプションは廃止 34
35. esModuleInterop why? •__esModuleが十分にデファクトスタンダードに なったから •デメリット（余計なランタイムコード）の減少 • ネイティブESMの利用拡大 • TS側でmodule: nodenext等によるCJS/ESM サポートの解像度が上がった 35
36. ⑥alwaysStrict: false （？） •“use strict” と書かなくてもソースコードを常に strict modeとして扱うオプション •今はデフォルトfalseだが、“strict”: true に含ま れるのでtrueにしているプロジェクトが多い （デフォルト値をtrueにするだけなのか、alwaysStrict オプション自体を消すのかははっきり決まっていないが、 多分オプションを消す） 36
37. alwaysStrict: false why? パフォーマンス上の理由が説明されている。 • falseだとパース時の先読みが必要なケースが増える • ASTのキャッシュを阻害する要因になる 元々Module形式のファイルでは全てstrict modeなので、 非strict modeの挙動は混乱の元になるという事情もあ るか。 37
38. オプションではないけど 非推奨化されるものたち 38
39. ⑦一部のmodule構文 •namespaceは昔moduleという構文だった •その名残で今でもmoduleと書くことができたが、 ついに非推奨化 39 module Foo { export type Bar = number; export const bar: Bar = 0; } namespace Foo { export type Bar = number; export const bar: Bar = 0; }
40. 一部のmodule構文: 注意 引き続きmoduleを使う場面もある。 （アンビエントモジュール宣言） 40 declare module “my-foo-module” { type Bar = number; const bar: Bar; }
41. 一部のmodule構文 why? そもそもかなり昔にもうnamespaceに変えていた。 加えて、JavaScript側で似たようなmodule構文を 追加する機運がある。 その際TSの独自構文が邪魔にならないように、 独自構文は廃止したい。 41
42. ⑧import … asserts •Import AssertionsとしてassertsがTypeScriptなど に実装された後、仕様がwithに変更された •assertsの使用は非推奨に 42 import json from “./foo.json” asserts { type: “json” }; import json from “./foo.json” with { type: “json” };
43. import … asserts why? 仕様上非推奨になったとはいえ一度実装したもの なので互換性が大丈夫か危惧されていたが、 Google ChromeやNode.jsからも実装が削除され、 仕様からもassertsが消されることになり、 さすがに大丈夫そうなので削除される見通し。 43
44. もはや非推奨化でもないけど 挙動が変わるオプションたち 44
45. ⑨typesのデフォルト挙動 • “types”: [“node”] のようにどの@typesパッケージを 自動で読み込むか決めるオプション •デフォルトでは「@typesパッケージ全て」 •新しいデフォルトは [] 45
46. typesのデフォルト挙動 why? 本当に全てを読み込む必要のあるプロジェクトは まず無い。大抵はnodeを読み込めば十分。 （あとはjestとか） 気付かないうちにパフォーマンスが落ちることを 防ぐためにデフォルトを変える。 46
47. typesのデフォルト挙動 補足 「型定義の無いパッケージの型定義を補う」系の @typesパッケージはそもそもtypesオプションで 指定する必要がない。（importすれば自動で読み込まれる） typesオプションで指定すべきなのは、主にグロー バル変数を生やす系。 47
48. ⑩rootDirのデフォルト値 •プロジェクトのルートディレクトリを決めるオプ ション（outDirがどこからの相対パスになるか等に影響） •従来は「全てのソースファイルを内包するディレク トリ」 •新デフォルトは「tsconfig.jsonがあるディレクトリ」 48
49. rootDirのデフォルト値 why? 全てのソースファイルを列挙しないとrootDirが定まら ないのはパフォーマンスに悪影響だから。 ソースファイルの列挙はimportを辿ることも含むので わりと大変。 49
50. ⑪tscにファイル名を渡したときの挙動 • tsc foo.ts のようにすると…… • 従来挙動: tsconfig.jsonを無視してデフォルト設定 で実行 • 新挙動: tsconfig.jsonがある場合はエラーが発生。 --ignoreConfig（仮）を指定すると従来挙動 50
51. tscにファイル名を渡したときの挙動 why? 従来挙動は分かりにくく、意図が不明瞭で需要も ない。 AIがtsc foo.tsを実行して大量のエラーを発生させて 混乱することが多すぎるので、この修正はとても ありがたい…… 51
52. ⑫それ以外のオプション修正 •libReplacementのデフォルト値がtrue→falseに • better-typescript-libを使う人は設定が必要（宣伝） •noUncheckedSideEffectImportsのデフォルト 値がfalse→trueに 52
53. もはや非推奨化でもオプショ ンでもないけど挙動が変わる やつら 53
54. ⑬enum merging •実は同じファイル内で同じenumを複数回定義す るとマージされた •使われていないので廃止 54 enum E { Foo = 1 } enum E { Bar = 2 }
55. ⑭複数namespace間での変数参照 •依然として複数のnamespace定義をマージする ことは可能 •しかし、他のnamespace定義内で定義された変 数を参照している場合の挙動が変わる 55
56. 複数namespace間での変数参照: 例 namespace Tax { export const rate = 0.1; } const rate = 0.05; namespace Tax { function applyTax(price: number) { return price * rate; } } 56 このrateは何を指す？
57. 複数namespace間での変数参照: 例 namespace Tax { export const rate = 0.1; } const rate = 0.05; namespace Tax { function applyTax(price: number) { return price * rate; } } 57 従来挙動: このrateを指す （別ファイルだとしても！）
58. 複数namespace間での変数参照: 例 namespace Tax { export const rate = 0.1; } const rate = 0.05; namespace Tax { function applyTax(price: number) { return price * rate; } } 58 新挙動: このrateを指す
59. 複数namespace間での変数参照 why? 変数が暗黙のうちに他のnamespaceの変数を参照 できる仕様だと、namespaceの全ての定義箇所を 調べないと変数参照を解決できない。 しかも、非モジュールでは同じnamespace定義が 他のファイルにある可能性がある。 パフォーマンス的な問題が大きい。 59
60. まとめ 60
61. 非推奨化や挙動変更の傾向 •実装の削減（需要が少なくなった機能） •パフォーマンス 特に、「全ファイル見ないと決まらない系」の挙動が 複数廃止されている。 並列処理の妨げになるからかも？ 61
62. 今後の流れ TypeScript 6.0がリリース予定の数ヶ月後には、 このような非推奨化が来ることが予想される。 しばらくは「6系」のメンテナンスを継続すると されており、今回の非推奨化は6.5まで猶予がある。 ただし、Go版の速さを享受したければより素早い 対応が必要。 62
63. まとめ 対応が必要とはいっても、そんなに激しい破壊的 変更はなく、あくまでもう必要がない機能の 非推奨化にとどまる。 この辺りは互換性を重視するMicrosoftらしい ですね。 63