meteor-typescript

Meteor アプリケーションでの TypeScript

エディターとチェッカーが意図した Meteor の宣言を解決し、アプリケーションのソースを実際に検査するようにします。タスクに変更が含まれない限り、動作中のプロバイダーの選択は維持してください。ランタイムやバンドラーのアップグレードは、宣言の移行を意味するものではありません。

ランタイムの移行やバンドラーの設定を依頼された場合は、移行手順やビルド設定を提案する前に、該当するスキルを読み込んでください。このスキルの宣言に関するガイダンスでは、その手順は扱いません。該当するスキルが利用できない場合に、一般的な TypeScript/Rspack の手順で代用しないでください。

レイヤーを特定する

レイヤー	根拠と対応
コンパイル	Atmosphere の typescript パッケージまたは Rspack/SWC が型を除去します。構文変換、ローダー、バンドルについてはビルドを担当するスキルを使ってください。
宣言プロバイダー	.meteor/packages、.meteor/versions、npm／ワークスペースのマニフェスト、ロックファイルを調べ、zodern:types、@types/meteor が直接指定されているか、ネイティブをオプトインしているかを確認します。
解決	有効な tsconfig.json／jsconfig.json、extends、files、include、exclude、paths、types を調べます。エディターが意図したプロジェクト／コンパイラーを使っていることを確認してください。
チェック	インストール済みの npm typescript とスクリプトを調べます。これは Atmosphere のコンパイラーとは別です。TsCheckerRspackPlugin など、設定済みのチェッカーを維持してください。

meteor run や meteor build が成功したからといって、アプリがチェックされていると判断しないでください。逆に、SWC 自体はトランスパイルしか行わないという理由だけで、明示的に設定されたチェッカーが実行されないと主張しないでください。

プロバイダーを選ぶ

ネイティブ宣言は 3.6-beta.1 から利用できます。このワークフローは 3.6-beta.3 まで、および 3.6-rc.0 のソースに対して検証済みです。Beta.3 では、以下にリンクされている宣言の修正が追加されました。RC でも、明示的な生成とプロバイダーの選択が維持されています。

対象と意図	判断
3.6-beta.1 より前の Meteor 3	ネイティブの meteor types は利用できません。動作中の従来型プロバイダーを維持してください。宣言が不足している場合は、プロバイダーのリファレンスにある旧リリース向けの項目を使ってください。
3.6 のネイティブ型に対応した新規または既存のアプリで、従来型の型定義が動作中	ネイティブへの移行が要求されない限り、現状を維持してください。Beta.1 の TypeScript テンプレートでは、zodern:types と @types/meteor が引き続き直接インストールされます。ネイティブへのフォールバック経路はオプトインではありません。
3.6-beta.1 から beta.3、または 3.6-rc.0 で明示的にネイティブを採用する場合	ルート設定が必要です。プロバイダーと設定の状態をチェックポイントに保存し、直接指定された zodern:types を削除して、生成が成功することを確認してから、ネイティブの解決設定をマージし、重複するアンビエント型を削除してください。
IntelliSense を利用したい JavaScript のみの 3.6 ベータアプリ	jsconfig.json と同じプロバイダー選択を使ってください。TypeScript ソースへの変換やバンドラーの切り替えは必要ありません。

切り替え手順、ネイティブアダプターとバレルの違い、継承された設定、TypeScript 7 との互換性、旧プロバイダー、ロールバックについては、宣言プロバイダーを参照してください。JavaScript アプリについては、JavaScript IntelliSenseを参照してください。

プロジェクトの有効な状態を確認する

1. 生成が実際に実行されたことを確認します。zodern:types が直接指定されていると、meteor types は終了コード 0 でスキップされます。ベータ 1 からベータ 3 および RC では、通常の Meteor コマンドはネイティブ宣言を選択したり再生成したりしません。
2. アプリのローカルコンパイラーを使用します。ネイティブ宣言を使用する場合は、パッケージスクリプトで meteor types && tsc --noEmit を実行します。アプリに複数のプロジェクトがある場合は、意図した設定を明示的に選択してください。
3. tsc --listFiles --noEmit にアプリケーションのソースが含まれていることを確認します。files にバレルファイルを追加すると、暗黙的なファイルの取り込みが無効になることがあります。既存のソースパターンと除外設定は維持してください。意図的に一時的な型エラーを発生させて、失敗することを確認します。確認用のコードを削除してから再実行してください。JavaScript の IntelliSense だけでは checkJs は有効になりません。必要に応じて、JS のチェックを別途選択してください。
4. 設定を変更した後は、エディターの TypeScript サーバーを再起動します。CLI とエディターの結果が一致しない場合は、Meteor の状態を消去したりプロバイダーを再インストールしたりする前に、選択されている設定とコンパイラーを比較してください。
5. 生成された .meteor/types/ は追跡も編集もしないでください。any や新しい skipLibCheck による回避策で隠すのではなく、表面化したアプリのエラーを修正してください。

境界を診断する

症状	最初に確認する項目
ネイティブコマンドが「処理するものがない」と報告する	ルートの tsconfig.json または jsconfig.json。ネイティブのみの新しいセットアップでは、存在しない出力先を指すエントリーを追加する前に、ルート設定で生成してください。
生成に失敗する	エラーを確認してください。ローカルパッケージの修正が必要な場合があります。プロバイダーの切り替えを中止し、設定と以前の出力を保持して、ロールバックのために以前のプロバイダーを復元してください。
通常のインポートは動作するが、スコープ付き／サブパスのインポートは失敗する	files に明示的なネイティブバレルを指定し、ワイルドカードマッピングの参照先をバレルではなくパッケージごとのアダプターにします。
識別子が重複する	プロバイダーの重複、継承された types: ["meteor"]、シンボリックリンク前のアプリのアンビエント宣言を確認してください。
Meteor のパッケージストア内でピア型が失敗する	その特定の境界で preserveSymlinks の使用を検討してください。ただし、重複したプロバイダーは解消できません。
コミュニティパッケージの型付けが 1 つだけ残っている	インストール済みのパッケージが宣言を公開しているか確認してください。Atmosphere のあらゆるパッケージを網羅できると保証するジェネレーターはありません。
生成された相対インポートまたはサブスクリプションハンドルの型が実行時と一致しない	プロバイダーのガイダンスにあるベータ 3 の宣言修正を確認してから、再生成して型チェックしてください。生成ファイルは編集せず、構造的なハンドルを使用可能な状態に保ってください。

実際の作業がパッケージ宣言の公開である場合は、公式の Atmosphere パッケージの型に関するドキュメントを参照してください。 パッケージ作成の解決策として、生成されたアプリケーションアダプターを編集しないでください。