前回は、TypeScriptで .ts ファイルを .js に変換してNode.jsで実行するまでの流れを学びました。
npx tsc
node src/index.js
ここで、多くの方がこう思うはずです：
「じゃあ、今後は .ts と .js を両方ずっと自分で管理していくの？」
この回では、その疑問に明確に答えながら、出力ファイルの整理方法とバージョン管理（Git）との関係をわかりやすく解説します。
.jsファイルは“成果物”であり、編集や管理の対象ではない
結論から言えば、.js ファイルはTypeScriptが自動で生成する中間成果物であり、自分で管理したり編集する必要はありません。
ポイント：
- 自分で書くのは
.tsファイルのみ .jsファイルはtscコマンドで自動生成される.jsファイルは基本的にGitで管理しない（後述）
出力ファイルの整理：outDirの設定
TypeScriptの設定ファイル tsconfig.json を使うと、変換後の .js ファイルをどこに出力するかを自由に指定できます。
デフォルトでは .ts と同じ場所に .js が出力されますが、それでは整理しづらいため、専用の出力フォルダ（例：dist）を設定するのが一般的です。
設定例（tsconfig.json）
jsonコピーする編集する{
"compilerOptions": {
"outDir": "./dist",
"rootDir": "./src",
"strict": true,
"target": "ES2020",
"module": "commonjs"
},
"include": ["src/**/*"]
}
用語の補足
| 項目 | 意味 |
|---|---|
compilerOptions | TypeScriptの変換（コンパイル）に関する設定項目です |
outDir | 変換後の .js ファイルを保存するフォルダです |
rootDir | .ts ファイルがあるフォルダのルートです |
strict | 型チェックをより厳しくするかどうかの設定です |
target | 出力するJavaScriptのバージョン指定です（ES2020など） |
module | Node.jsの読み込み方式（commonjsが一般的） |
include | どのファイルを変換対象に含めるかを指定します（src配下すべてなど） |
変換後の構成例
pgsqlコピーする編集するmy-ts-app/
├─ src/
│ └─ index.ts
├─ dist/
│ └─ index.js ← 自動生成される
├─ tsconfig.json
└─ package.json
.ts（自分で書くファイル）と.js（変換後の出力）が明確に分かれて、管理がしやすくなります。
.js をGitで管理すべきか？
基本的に管理しません。
Gitとは？
Git（ギット）は、プログラムなどのファイルの変更履歴を記録・共有できるツールです。
「どのファイルがいつ、どのように変更されたか」を追跡・保存できます。
開発の現場では、このGitを使ってソースコードを管理しています。
なぜ .js をGitに含めないのか？
| 理由 | 説明 |
|---|---|
| 自動生成される | .ts さえあれば .js は再生成できるから |
| バージョン管理に意味がない | 同じ内容でも毎回生成されて差分が出やすい |
| コンフリクトの元になる | 他の人と共有した際に、無駄な競合が起こりやすい |
.gitignore を使って除外する
Gitに不要なファイルを「無視」させるためには、.gitignore という特殊なファイルを使います。
例：
/dist
こう書くことで、dist フォルダ以下すべてをGitの管理対象から外すことができます。
.gitignoreファイルがなければ、同じフォルダに新しく作成して問題ありません。
了解しました。
以下に、区切りブロックを完全に排除し、文脈の流れも整理された修正版を提示します。
そのままGutenbergに貼り付け可能です。
.js を Git に含めるべき？
TypeScriptでは、.ts ファイルを編集して .js ファイルを生成します。では、この .js ファイルはGitで管理（＝バージョン管理）すべきでしょうか？
結論としては、通常は .js は Git に含めません。
その理由は次の通りです。
| 理由 | 補足 |
|---|---|
| 自動生成できる | tsc でいつでも .js を再生成できるため、手元に残す必要がない |
| 差分が読みにくい | .ts との違いが多く、レビュー時のノイズになりやすい |
| コンフリクトの原因になる | チーム開発で .js を各自生成すると、内容が食い違って競合しやすい |
このような理由から、通常は出力先フォルダ（例：dist）を .gitignore に登録し、Gitの管理対象から除外します。
# 出力ファイルは管理しない
dist/
では .js はどうやって再生成する？
Gitに含めない以上、.js ファイルは毎回自分で生成する必要があります。ここで使うのが TypeScript のコンパイルコマンド tsc です。
たとえば、次のように実行します。
npx tsc
このコマンドは、.ts ファイルを .js に変換して出力します。もし設定ファイル tsconfig.json が存在すれば、それに従って出力されます。
(補足)npm run build という選択肢
おすすめなのが、npm run build のようにスクリプトとして登録する方法です。
まず、package.json に次のような記述を追加します。
{
"scripts": {
"build": "tsc"
}
}
npm run build
一見すると npx tsc の方が短いように見えますが、「build」という意味のある名前で実行できる点が大きなメリットです。何をしているかがすぐにわかるため、他の人がプロジェクトを見たときにも直感的に理解できます。
また、将来的に次のような複数の処理を含めることもできます。
{
"scripts": {
"build": "tsc && cp config.json dist/"
}
}
このように、npm run build は拡張性にも優れています。
- コマンドの目的が名前から分かる（buildと書かれていれば誰でも意図を理解できる）
- 他の処理と組み合わせやすい（例：コンパイル後にファイルをコピーする等）
- プロジェクトごとに設定を一元管理できる（
package.jsonに記述されるため）
まとめ：.jsファイルは“成果物”と割り切る
| 内容 | 説明 |
|---|---|
.ts を編集 → .js を自動生成 | 書くのは .ts のみでOK |
outDir を使って整理 | 出力専用フォルダにまとめるとスッキリ |
.js はGitで管理しない | .gitignore を使って除外する |
| Gitとは？ | 変更履歴を記録・共有するためのツール |
「成果物は管理しない」という考え方は、今後ReactやNext.jsなどのフレームワークを扱うときにも共通する重要な原則です。
次回予告
次回は、TypeScriptの基本文法──変数、関数、型注釈などを学びながら、JavaScriptとの違いと、TypeScriptの恩恵を実感していきます。
Comment