<section><div><div><div><a><div><img></div><div>TypeScript</div></a><a><div><img></div><div>ECMAScript</div></a><a><div><img></div><div>tech</div></a></div><div><div><p>TypeScriptのコードでは、<code>export {};</code> という記述を見かけることがあります。これはECMAScriptの構文ではあるものの、これが使われる背景にはTypeScript特有の事情があります。この記事では、<code>export {};</code> がなぜ使われるのか、どのような効果があるのかを解説します。</p>
<h2>
<a aria-hidden="true"></a> <code>export {};</code> とは</h2>
<p>この構文は、<code>export</code>というキーワードから分かるように、モジュールに関連する構文です。</p>
<p>一般に、<code>export { ... };</code>という構文は、既存の変数をモジュールからエクスポートするために使われます。例えば、次のようなコードが考えられます。</p>
<div><pre><code>const foo = 42;
const bar = "hello";
const banana = "banana";

export {
  foo,
  bar as hello,
  banana as "🍌",
};
</code></pre></div><p>変数をエクスポートする場合は<code>export const foo = 42;</code>のように書くこともできますが、<code>export</code>を付けずに宣言された既存の変数をエクスポートする場合は、<code>export { ... };</code>を使います。この構文は、複数の変数を一度にエクスポートする場合に便利なほか、<code>as</code>キーワードを使ってエクスポート名を変更することもできます。</p>
<p>さて、<code>export {};</code>もこの構文の一種です。つまり、0個の変数をエクスポートするという意味になっています。</p>
<div><pre><code>export {};
</code></pre></div><p>0個の変数をエクスポートするというのは、何もエクスポートしないということです。つまり、この<code>export</code>宣言はあっても無くても変わりません。ECMAScript的には書く意味が無いことになります。</p>
<h2>
<a aria-hidden="true"></a> TypeScriptで<code>export {};</code>が使われる理由</h2>
<p>以上の説明から、<code>export {};</code>は何もしない構文であることが分かりました。では、なぜTypeScriptのコードでこの構文が使われるのでしょうか。ここにはTypeScript特有の事情があります。実は、その事情はTypeScriptにおける<strong>モジュール</strong>の判定に関係しています。</p>
<h3>
<a aria-hidden="true"></a> ECMAScriptにおけるスクリプトとモジュール</h3>
<p>ECMAScriptには、スクリプトとモジュールという2つの概念があります。スクリプトは従来のコードで、モジュールはES2015から導入されました。モジュールの特徴は<code>import</code>と<code>export</code>が使えることです。一方、スクリプトは<code>import</code>と<code>export</code>が使えません（他にもモジュールは常にstrict modeで実行されるなどの違いがあります）。</p>
<p>あるJavaScriptコードがスクリプトなのかモジュールなのかの判別方法は、実は仕様で定められていません。そのコードがスクリプトなのかモジュールなのかは、そのコードを実行する環境に依存します。</p>
<p>例えば、HTML（ブラウザ上）では<code><script></script></code>で読み込まれたコードはスクリプトとして扱われ、<code><script type="module"></script></code>で読み込まれたコードはモジュールとして扱われます。もし、<code><script></script></code>で読み込まれたコードに<code>import</code>や<code>export</code>が含まれていた場合、そのコードは構文エラーとなります。</p>
<p>また、Node.jsの場合はファイルの拡張子が<code>.cjs</code>であればスクリプト、<code>.mjs</code>であればモジュールとして扱われます。</p>
<h3>
<a aria-hidden="true"></a> TypeScriptにおけるモジュールの判定</h3>
<p>TypeScriptは独自にモジュールとスクリプトの判定を行います。問題となるのは、基本的にTypeScriptコンパイラからはそのコードがどのように使われるのかは分からないということです。そのため、実際の実行環境のように、使われ方によってスクリプトかモジュールかを判定することはできません。</p>
<p>TypeScriptは、コード中で<code>import</code>や<code>export</code>が使われているかどうかで、そのコードをモジュールとして扱うかスクリプトとして扱うかを判定します。もし、<code>import</code>や<code>export</code>が使われていない場合、そのコードはスクリプトとして扱われます。</p>
<p>これは、普通の実行環境がコードをパースする前にもうモジュールかスクリプトかを判定しているのと比べて特殊です。TypeScriptでは、コードをパースしてからそのコードがモジュールかスクリプトかを判定します。</p>
<h3>
<a aria-hidden="true"></a> <code>export {};</code>の効果</h3>
<p>これで、<code>export {};</code>がどのような効果を持つのかが分かりますね。何も<code>import</code>も<code>export</code>もしないけどモジュールとして扱いたい場合、<code>export {};</code>を使うことで、TypeScriptコンパイラにそのコードをモジュールとして扱うように指示することができるのです。</p>
<p>TypeScript以外ではコードを見る前にモジュールかスクリプトかを判定するので、<code>export {};</code>を書く必要はありません。その点で、このような<code>export {};</code>の使い方はTypeScriptに特有のものと言えます。</p>
<h3>
<a aria-hidden="true"></a> なぜコードをモジュールとして扱いたいのか</h3>
<p>ところで、インポートもエクスポートもしないファイルをモジュールとして扱いたいのはどうしてでしょうか。</p>
<p>これは、スクリプトとモジュールの違いによるものです。特に、スクリプトにおいて<code>var</code>で宣言された変数はグローバルスコープになりますが、モジュールではモジュールスコープになります。</p>
<div><pre><code><script>
  var foo = 42;
</script>
<script type="module">
  var bar = 42;
</script>
<script>
  console.log(foo); // 42
  console.log(bar); // ReferenceError: bar is not defined
</script>
</code></pre></div><p>TypeScriptもこの挙動をサポートしています。特に、スクリプト内で定義された変数や型はグローバルな定義となり、プロジェクト内の他のファイルからも参照できます。逆に、モジュール内で定義された変数や型は、そのモジュール内でのみ参照できます（他のモジュールから参照するためにはエクスポートする必要があります）。</p>
<p>今どきのプロジェクトは、モジュールを使ってコードを書くことが一般的です。しかし、TypeScriptにおいては敢えてスクリプトとしたファイルに型定義を書くことでグローバルな型定義を用意する手法もあります。TypeScript初心者の方がはまりがちな罠として、そのようなファイルでうっかり<code>import</code>を書いてしまい、モジュールになってしまって他のファイルから型定義が参照できなくなってしまうことがあります（ちなみに、そのような場合は<code>declare global</code>を使えばモジュールの中からグローバルな型定義を書くこともできます）。</p>
<p>逆に、スクリプトとして扱ってほしくないファイルに<code>export {};</code>を書くことで、そのファイルをモジュールとして扱うことができます。これにより、そのファイル内の定義がグローバルなスコープに漏れることを防ぐことができます。</p>
<p>実際のコードではモジュールは何かしらをエクスポートすることが多く、<code>export {};</code>を使うことはあまりないかもしれません。しかし、開発途中でまだエクスポートするものがない場合などに一時的に<code>export {};</code>を使うことがあるかもしれません。</p>
<h3>
<a aria-hidden="true"></a> TypeScriptの型定義における具体例</h3>
<p>TypeScriptの型定義ファイル（<code>.d.ts</code>）においても、スクリプトかモジュールかという区別は以上の説明がそのまま当てはまります。実は、<code>export {};</code>のテクニックがTypeScriptの標準ライブラリ（組み込みの型定義）でも使われています。</p>
<p>TypeScript 5.6 Beta向けに書かれた <code>lib.esnext.iterator.d.ts</code> という<a>型定義ファイル</a>を見てみましょう。</p>
<div>
<div><span>lib.esnext.iterator.d.tsから抜粋</span></div>
<pre><code>// NOTE: This is specified as what is essentially an unreachable module. All actual global declarations can be found
//       in the `declare global` section, below. This is necessary as there is currently no way to declare an `abstract`
//       member without declaring a `class`, but declaring `class Iterator<T>` globally would conflict with TypeScript's
//       general purpose `Iterator<T>` interface.
export {};

// Abstract type that allows us to mark `next` as `abstract`
declare abstract class Iterator</T> { // eslint-disable-line @typescript-eslint/no-unsafe-declaration-merging
    abstract next(value?: unknown): IteratorResult<T, undefined>;
}

// Merge all members of `BuiltinIterator<T>` into `Iterator</T>`
interface Iterator<T> extends globalThis.BuiltinIterator<T, undefined, unknown> {}

// Capture the `Iterator` constructor in a type we can use in the `extends` clause of `IteratorConstructor`.
type BuiltinIteratorConstructor = typeof Iterator;

declare global {
    // Global `BuiltinIterator</T>` interface that can be augmented by polyfills
    interface BuiltinIterator<T, TReturn, TNext> {
// 以下略
</T></code></pre>
</div><p>このファイルでは前述の<code>declare global</code>が使われています。これまでTypeScriptの組み込み型定義は基本的にスクリプトとして書かれていたため、ファイル内に書かれた定義が全て自動的にプロジェクト全体で利用可能でした。しかし、このファイルでは″内部実装”を<code>export {};</code>で隠蔽し、外に公開する型定義だけを<code>declare global</code>で書いています。</p>
<p>標準ライブラリに限らず、このようなパターンはプロジェクト内で共有される型定義を書くときにも使えるテクニックです。</p>
<h2>
<a aria-hidden="true"></a> 余談: <code>moduleDetection</code>コンパイラオプション</h2>
<p>実は、ここまで説明した内容は今でも有効ではあるものの、少し古くなりつつあります。それは、TypeScript 4.7で導入された<code>moduleDetection</code>コンパイラオプションにより、スクリプトかモジュール化の判定方法が変わるためです。</p>
<p>このオプションは以下の3つの値を取ります。</p>
<ul>
<li>
<code>auto</code>（デフォルト）: コード内の<code>import</code>や<code>export</code>の有無に基づいてスクリプトかモジュールかを判定する。しかし、<code>module</code>オプションが<code>node16</code>または<code>nodenext</code>の場合、拡張子（<code>.mts</code>）や<code>package.json</code>の<code>type</code>フィールドの設定に従う<sup><a>[1]</a></sup>。</li>
<li>
<code>legacy</code>: コード内の<code>import</code>や<code>export</code>の有無のみを見る（TS 4.6以前と同じ）。</li>
<li>
<code>force</code>: 全てモジュールとして扱う。</li>
</ul>
<p>TS 4.7は<code>module</code>: <code>node16</code>などのNode.jsのESMサポートが追加されたバージョンです。それにより、従来TypeScriptでは内的要因（ファイルの中身）によってスクリプトかモジュールかを判定していたところ、Node.jsと同じような外的要因（拡張子や<code>package.json</code>の<code>type</code>フィールド）によって判定する仕組みも追加されました。</p>
<p><code>force</code>はもはやスクリプトという概念を消し去り、全てのファイルがモジュールになります。今どきのTypeScriptプロジェクトはモジュールしか使わないからという理由の他にも、<a>逆に独立したファイルの寄せ集めのプロジェクトで勝手にグローバルスコープになってほしくない</a>という需要もあったようです。</p>
<p>ただし、<code>auto</code>や<code>force</code>の挙動は型定義ファイル（<code>.d.ts</code>など）には当てはまらないことに注意してください。型定義ファイルは従来通りのルール（<code>import</code>/<code>export</code>があるか）で判定されるので、<code>export {};</code>のテクニックは有効です。上で紹介した標準ライブラリの例も型定義ファイルですね。</p>
<p>このように普通のファイルと型定義ファイルでルールが分かれるのは、スクリプト内で定義された変数がグローバル変数になっても嬉しい場面はとくに無い一方、型定義ファイル内で定義された型をプロジェクト全体で利用するというニーズはあるからなのでしょう。</p>
<h2>
<a aria-hidden="true"></a> まとめ</h2>
<p>TypeScriptのコードで<code>export {};</code>という構文を見かけることがありますが、これは何もエクスポートしないという意味です。TypeScriptのコードをモジュールとして扱いたい場合に使われるテクニックで、特に型定義ファイルなどで使われることがあります。</p>
<section>
<span>脚注</span>
<ol>
<li>
<p>他に<code>.tsx</code>ファイルの取り扱いの変化などもありますが省略。 <a>↩︎</a></p>
</li>
</ol>
</section>
</div></div><span></span><a><span><svg x="0px" y="0px" viewBox="0 0 27 27" xml:space="preserve" height="20" width="20"><path fill="currentColor" d="M13.4,1.2C7,1,1.8,6,1.7,12.4c0,0.1,0,0.4,0,0.5c0,5.1,3.2,9.8,8.2,11.5c0.6,0.1,0.7-0.2,0.7-0.6s0-1.8,0-2.9 c0,0-3.3,0.6-4-1.5c0,0-0.6-1.3-1.3-1.8c0,0-1.1-0.7,0.1-0.7c0.7,0.1,1.5,0.6,1.8,1.2c0.6,1.2,2.2,1.7,3.4,1h0.1 c0.1-0.6,0.4-1.2,0.7-1.6C8.7,17.1,6,16.9,6,12.3c0-1.1,0.5-2.1,1.2-2.8c0-1.1,0-2.2,0.3-3.2c1-0.4,3.3,1.3,3.3,1.3c2-0.6,4-0.6,6,0 c0,0,2.2-1.6,3.2-1.2c0.5,1,0.5,2.2,0.1,3.2c0.7,0.7,1.2,1.8,1.2,2.8c0,4.5-2.8,5-5.5,5.2c0.6,0.6,0.9,1.3,0.7,2.2c0,1.7,0,3.5,0,4 s0.2,0.6,0.7,0.6c4.9-1.7,8.2-6.2,8-11.5c0.1-6.4-5.1-11.6-11.6-11.6C13.5,1.2,13.4,1.2,13.4,1.2z"></path></svg></span>GitHubで編集を提案</a><span></span><aside><div><a><img alt="uhyo" height="80" referrerPolicy="no-referrer" width="80"></a><div><a>uhyo</a></div><div><p><span>Metcha zakoi software engineer （本物）</span></p><div><span></span><a aria-label="@uhyo" data-tooltip-for-desktop="true" data-tooltip-position="bottom" role="tooltip"><svg x="0px" y="0px" viewBox="0 0 27 27" xml:space="preserve" aria-label="GitHub"><path fill="currentColor" d="M13.4,1.2C7,1,1.8,6,1.7,12.4c0,0.1,0,0.4,0,0.5c0,5.1,3.2,9.8,8.2,11.5c0.6,0.1,0.7-0.2,0.7-0.6s0-1.8,0-2.9 c0,0-3.3,0.6-4-1.5c0,0-0.6-1.3-1.3-1.8c0,0-1.1-0.7,0.1-0.7c0.7,0.1,1.5,0.6,1.8,1.2c0.6,1.2,2.2,1.7,3.4,1h0.1 c0.1-0.6,0.4-1.2,0.7-1.6C8.7,17.1,6,16.9,6,12.3c0-1.1,0.5-2.1,1.2-2.8c0-1.1,0-2.2,0.3-3.2c1-0.4,3.3,1.3,3.3,1.3c2-0.6,4-0.6,6,0 c0,0,2.2-1.6,3.2-1.2c0.5,1,0.5,2.2,0.1,3.2c0.7,0.7,1.2,1.8,1.2,2.8c0,4.5-2.8,5-5.5,5.2c0.6,0.6,0.9,1.3,0.7,2.2c0,1.7,0,3.5,0,4 s0.2,0.6,0.7,0.6c4.9-1.7,8.2-6.2,8-11.5c0.1-6.4-5.1-11.6-11.6-11.6C13.5,1.2,13.4,1.2,13.4,1.2z"></path></svg></a><a aria-label="@uhyo_" data-tooltip-for-desktop="true" data-tooltip-position="bottom" role="tooltip"><svg width="27" height="28" viewBox="0 0 27 28" fill="none" aria-label="X(Twitter)"><g clip-path="url(#clip0_1_18)"><path d="M16.0687 11.7356L26.12 0H23.7382L15.0106 10.1899L8.03988 0H0L10.5411 15.4089L0 27.7155H2.38199L11.5985 16.9546L18.9601 27.7155H27L16.0681 11.7356H16.0687ZM12.8062 15.5447L11.7382 14.0103L3.24025 1.80106H6.89884L13.7568 11.6543L14.8248 13.1887L23.7393 25.9963H20.0807L12.8062 15.5452V15.5447Z" fill="currentColor"></path></g><defs><clipPath><rect width="27" height="27.7297" fill="white"></rect></clipPath></defs></svg></a><a aria-label="uhy.ooo" data-tooltip-for-desktop="true" data-tooltip-position="bottom" role="tooltip"><svg x="0px" y="0px" viewBox="0 0 27 27" xml:space="preserve" aria-label="リンク"><path fill="currentColor" d="M9.6,23.9c-3.6,0-6.5-3-6.5-6.6c0-1.7,0.7-3.4,1.9-4.6l2.3-2.3c0.5-0.4,1.2-0.4,1.6,0.1c0.4,0.4,0.4,1,0,1.5l-2.3,2.3 c-1.7,1.7-1.7,4.4,0,6.1s4.4,1.7,6.1,0l2.3-2.3c0.5-0.4,1.2-0.4,1.6,0.1c0.4,0.4,0.4,1,0,1.5L14.3,22C13,23.2,11.4,23.9,9.6,23.9z  M10.6,17.5c-0.6,0-1.1-0.5-1.1-1.1c0-0.3,0.1-0.6,0.3-0.8l5.8-5.8c0.4-0.4,1.1-0.4,1.6,0c0.4,0.4,0.4,1.1,0,1.6l-5.8,5.8 C11.2,17.4,10.9,17.5,10.6,17.5z M18.9,16.9c-0.3,0-0.6-0.1-0.8-0.3c-0.4-0.4-0.4-1.1,0-1.6l2.3-2.3c1.7-1.7,1.7-4.4,0-6.1 c-1.7-1.7-4.4-1.7-6.1,0L12,8.9c-0.5,0.4-1.2,0.4-1.6-0.1c-0.4-0.4-0.4-1,0-1.5L12.7,5c2.6-2.6,6.7-2.6,9.2,0s2.6,6.7,0,9.2 l-2.3,2.4C19.4,16.8,19.1,16.9,18.9,16.9z"></path></svg></a></div></div></div></aside><span></span></div></div><div><div></div></div></section>

TypeScriptコンパイラにそのコードをモジュールとして扱うように指示するため

コードが必ずエクスポートされることを示すため

スクリプトとして扱うための構文であるため

ECMAScriptの標準構文として必須であるため

コード内で<code>import</code>や<code>export</code>が使われているかどうか

コードの内容に基づいて自動的に判定される

モジュールとして扱うことができる

グローバルスコープに変数が定義される

エクスポートされる変数を増やすことができる

スクリプトでは<code>var</code>で宣言された変数はグローバルスコープになる

モジュールでは<code>var</code>で宣言された変数はグローバルスコープになる

スクリプトでは<code>import</code>と<code>export</code>が使える

モジュールは常にstrict modeで実行されない

ファイル内の定義を外部に公開しないため

型定義を強制的にエクスポートするため

グローバルスコープに変数を定義するため

TypeScriptの型チェックを無効にするため