完全なツールチェーンの導入
=============

* 前のページ
* Overview: Understanding client-side tools
* 次のページ

シリーズの最後の 2 つの記事ではケーススタディのツールチェインサンプルを構築するプロセスを通して、ツールに関する知識を理解していきます。理にかなった開発環境のセットアップと変換ツールの配置から、実際にNetlifyにアプリをデプロイするまでの全過程を説明します。この記事では、ケーススタディの紹介、開発環境のセットアップ、コード変換ツールのセットアップを行います。

|  |  |
| --- | --- |
| 前提条件： | 主要な HTML、CSS、と JavaScript 言語 |
| 目的： | ツールチェーンのケーススタディの演習を完了して、これまでに学んだことを確実に理解します。 |

ツールとその使用方法の組み合わせは実際に無限にあります。この記事と次の記事で説明したことは、プロジェクトで注目のツールを使用できる *1つの* 方法にすぎません。

**メモ:** これらのツールのすべてをコマンドラインで実行する必要があるわけではないことも繰り返し述べておきます。 現在のコードエディター (VS Code や Atom など) の *多く* は、プラグインを介して多数のツールの統合をサポートしています。

ツールチェーンのケーススタディの事例紹介
--------------------

この記事で作成しているツールチェーンは、地球上の私たちの存在を脅かす潜在的に危険な宇宙物体に関するデータ (NASA's open APIs の 1 つから取得) をリストするミニサイトを構築して展開するために使用されます。次のようになります。

![screenshot of the sample will it miss website](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Introducing_complete_toolchain/will-it-miss-screenshot.png)

このサイトのライブバージョンは、near-misses.netlify.com でご覧いただけます。

ツールチェーンで使用されるツール
----------------

この記事では、次のツールと機能を使用します。

* JSXは React に関連する構文拡張のセットで、 JavaScript 内でコンポーネント構造を定義するなどの作業を可能にします。このチュートリアルに行うのに React を理解する必要はありませんが、非ネイティブウェブ言語をツールチェーンに統合する方法を理解するためにこれを含めました。
* `import` などの最新の組み込み JavaScript 機能（執筆時点）です。
* フォーマット用の Prettier や lint 用の ESLint などの便利な開発ツール。
* PostCSS は、 CSS のネスティング機能を提供します。
* Parcel コードをビルドして縮小し、多数の構成ファイルのコンテンツを自動的に書き込みます。
* GitHub を使ってソースコードを管理しています。
* Netlify を使ってデプロイプロセスを自動化します。

上記の機能やツールが何をするものなのか、よく知らないかもしれないがパニックにならないでください。この記事を進めながら各部分について説明します。

ツールチェーンとその固有の複雑さ
----------------

他のチェーンと同様にツールチェーン内のリンクが増えるほどツールチェーンはより複雑になり脆弱になる可能性があります。たとえば構成がより複雑になり、壊れやすくなる可能性があります。 逆にリンクが少ないほど、ツールチェーンは壊れにくくなる可能性があります。

すべてのウェブプロジェクトは異なるためツールチェーンのどの部分が必要かを検討し、それぞれの部分を慎重に検討する必要があります。

最小のツールチェーンは、リンクがまったくないツールチェーンです。 HTML を手動でコーディングし、「 vanilla JavaScript 」(フレームワークや中間言語を使用しないことを意味します) を使用し、それをすべて手動でサーバーにアップロードしてホスティングします。

しかし、より複雑なソフトウェア要件の場合は開発プロセスを簡素化するツールを使用することで恩恵を得られる可能性があります。 さらに、本番サーバーにデプロイする前にソフトウェアが意図したとおりに動作することを確認するテストを含める必要があります。これはすでに必要なツールチェーンのように思えます。

サンプルプロジェクトではソフトウェア開発を支援し、ソフトウェア設計段階での技術的選択をサポートするために特別に設計されたツールチェーンを使用します。 ただし、複雑さを最小限に抑えることを目的としてて余計なツールは使わないようにします。

例えば、ビルド中に SVG ファイルサイズを最小化するツールを組み込むこともできたかもしれません。 しかし、このプロジェクトには SVG 画像が 4 つしかなくプロジェクトに追加する前に SVGO を使用して手動で縮小 しました。

いくつかの前提条件
---------

ツールチェーンに貢献するこれからインストールするツールの他に、上記のツールのリストで 2 つのウェブサービスを紹介しました。先に進む前にこの機会を利用して、セットアップが完了していることを確認しましょう。 チュートリアルを完了するには、GitHub と Netlify のアカウントを作成する必要があります。

* 前述したように、GitHub はソースコードリポジトリーサービスであり、課題の追跡やプロジェクトのリリースのフォローなどのコミュニティ機能を追加しています。次の章では、 GitHub のコードリポジトリーにプッシュして、すべてのソフトウェアをウェブ上のホームにデプロイする（はずの）カスケード効果を引き起こします。
* Netlify は、静的ウェブサイト (つまり、リアルタイムでは変更されないファイルで完全に構成されているウェブサイト) 用のホスティングサービスです。これにより、1 日に何度もデプロイすることができ、あらゆる種類の静的サイトを自由にホストできます。 Netlify は前述の「ウェブ上のホーム」、つまりテスト アプリをデプロイするための無料のホスティングを提供するものです。

GitHub にサインアップすると（まだアカウントをお持ちでない場合はホームページの *Sign Up* リンクをクリックし、指示に従ってください）、 Netlify での認証に GitHub アカウントを使用できるようになる(*Sign Up* をクリックし、[次のいずれかでサインアップ] リストから *GitHub* を選択してください)ので技術的には新しいアカウントを1つ作るだけで済みます。

後で、このプロジェクトをデプロイするために Netlify アカウントを GitHub リポジトリーに接続する必要があります。 その方法については次の章で説明します。

3 段階のツール
--------

クライアントサイドツールの概要で説明したようにツールチェーンは次のフェーズで構成されます。

* **セーフティネット**: ソフトウェア開発体験を安定させ、より効率的にします。 これを開発環境と呼ぶこともあります。
* **トランスフォーメーション**: 開発プロセスにおいて、ある言語 (JavaScript など) または別の言語全体 (JSX や TypeScript など) の最新機能を使用できるようにし、製品版がモダンなものから古いものまで様々なブラウザーで動作するようにコードを変換します。
* **ポスト開発**: 開発本体が終了後に、ソフトウェアがウェブに公開され、実行され続けることを保証するために使用するツールです。このケーススタディではコードにテストを追加し Netlify を使用してアプリをデプロイし、ウェブ上で利用できるようにします。

開発環境から始めて、これらに取り組みましょう。

開発環境の構築
-------

ツールチェーンのこの部分が実際の作業を遅らせているように見えることがあります。環境を「適切な」状態にするために多くの時間を費やすという、ツールの「ウサギの穴」にはまりやすい可能性があります。

しかし、これは物理的な作業環境を整えるのと同じように考えることができます。 椅子は快適であり、姿勢を助けるために適切な位置に設置されている必要があります。 電源、 Wi-Fi 、 USB ポートが必要です。あなたの精神状態を助ける重要な装飾や音楽があるかもしれません。これらはすべて可能な限り最高の仕事をするために重要であり適切に行われれば、セットアップは 1 回だけで済みます。

同様に開発環境のセットアップはうまくいけば一度だけ行えばよく、将来の多くのプロジェクトで再利用できるはずです。 おそらくツールチェーンのこの部分を半定期的に確認し、導入すべきアップグレードや変更があるかどうかを検討することをお勧めしますが、これはあまり頻繁に行う必要はありません。

ツールチェーンはユーザー自身のニーズによって異なりますがこの (可能な) 完全なツールチェーンの例では、事前にインストールされるツールは次のとおりです。

* ライブラリーインストールツール — 依存関係を追加するためのツール
* コードリビジョン管理
* コード整理ツール — JavaScript、CSS、HTML の整理
* コード lint ツール — コードを lint するためのツール
### ライブラリーインストールツール

第 2 章で初めて説明した npm を使用してツールをインストールします。Node.js と npm がすでにインストールされている必要がありますが、インストールされていない場合は、そのセクションを参照してください。

**メモ:** インストールプロセスから分かりませんが、 npm をインストールすると、 npx と呼ばれる補完ツールもインストールされます。 この章の後半では、プロジェクトのローカル依存関係としてインストールされているツールの実行に役立つ npx を使用します。

npm は、ツールチェーンの後続の部分をインストールするために使用されます。 ただし、まず最初に、リビジョン管理を支援するために git をインストールします。

### コードリビジョン管理

「 git 」について聞いたことがあるかもしれません。 Git は現在、開発者が利用できる最も人気のあるソースコードのリビジョン管理ツールです。リビジョン管理には作業内容を遠隔地にバックアップする方法や互いのコードを上書きすることを恐れずに同じプロジェクトでチームで作業するメカニズムなど、多くの利点があります。

当たり前のことかもしれないが、繰り返す伝える必要があります。Git は GitHub と同じではありません。 Git はリビジョン管理ツールですが、 GitHub は git リポジトリー (およびそれらを操作するための便利なツール)のオンラインストアです。この章では GitHub を使用していますが、 GitLab や Bitbucket などの代替手段がいくつかあり、独自の Git リポジトリーをホストすることもできます。

プロジェクトでリビジョン管理を使用し、ツールチェーンの一部として組み込むことはコードの進化を管理するのに役立ちます。 これは「 X 個の新機能が実装されました」または「 Y 個の変更によりバグ Z が修正されました」などのコメントとともに、作業の進行に合わせて作業ブロックを「コミット」する方法を提供します。

リビジョン管理を使用すると変更が元のコードに影響を与えることなく、プロジェクトコードを「分岐」して別のバージョンを作成し、新しい機能を試すこともできます。

最後にどこかに間違いが生じて修正が困難な場合に、変更を元に戻したり、コードを「動作していたとき」の状態に戻したりするのに役立ちます。これはすべての開発者が時々行う必要があります。

Git は git-scm をウェブサイトからダウンロードしてインストールすることができます。あなたのシステムに合ったインストーラーをダウンロードして実行し、画面の指示に従ってください。今のところ、必要なことはこれだけです。

コマンドラインを使ってコマンドを発行したり、git GUIアプリ を使ってボタンを押すことで同じコマンドを発行したり、あるいは以下の Visual Studio Code の例にあるように、コードエディターの中から直接操作したりと、さまざまな方法でgitと対話することができます。

![GitHub integration shown in VS Code](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Introducing_complete_toolchain/vscode-git.png)

とにかく、今のところやるべきことは git をインストールすることだけです。次へ移りましょう。

### コード整理ツール

このプロジェクトでは、第 2 章で最初に説明した Prettier を使用してコードを整形します。 Prettier のインストールセクションの指示に従っている場合は、すでに Prettier がインストールされている可能性があります。そうでない場合は、今すぐターミナルを使用して Prettier をグローバルユーティリティとしてインストールするように指示します。

次のコマンドを使用して、すでにグローバルにインストールされているかどうかを確認できます。


```bash
prettier -v
```


インストールされている場合は、 2.0.2 のようなバージョン番号が返されます。そうでない場合は、「 command not found 」のような内容が返されます。この場合は、次のコマンドを使用してインストールします。


```bash
npm install prettier -g
```


Prettier がインストールされたので、コンピューター上のどこからでもコマンドラインで個々のファイルごとにコードの実行と整形を行うことができます。次に例を示します。


```bash
prettier --write ./src/index.html
```


**メモ:** 上記のコマンドでは、 `--write` フラグを指定して Prettier を使用しています。 Prettier は、これが「コードフォーマットに問題があれば、それを修正してからファイルを保存してください」という意味であると理解しています。これは開発プロセスには問題ありませんがフラグなしで `prettier` を使用することもでき、ファイルのチェックのみが行われます。ファイルをチェックする(保存しない)ことはリリース前に実行されるチェック、つまり「適切にフォーマットされていないコードをリリースしない」などの目的に役立ちます。

各ファイルに対して最初のコマンドを実行するのは大変なので、これを実行する単一のコマンドがあれば便利です ( lint ツールにも同じことが言えます)。

この問題を解決するには多くの方法があります。ここにほんの一部を示します。

* npm スクリプトを使用して、コマンドラインから複数のコマンドを一度に実行します( `npm run tidy-code` など)。
* 特別な「 git hooks 」を使用して、コミット前にコードがフォーマットされているかどうかをテストします。
* コードエディタープラグインを使用して、ファイルが保存されるたびに Prettier コマンドを実行します。

**メモ:** git hooks とは何ですか? Git (GitHub ではありません) は、git で実行するタスク(コードのコミットなど)にプレアクションとポストアクションを付加できるシステムを提供します。 git hooks は(この著者の意見では)少し複雑すぎるかもしれませんが、一度導入すると非常に強力になります。 hooks の使用に興味がある場合は、 Husky を参照すると、 hooks を使用するためのルートが大幅に簡素化されます。

VS Code の場合、便利な拡張機能の 1 つは Prettier Code Formatter by Esben Petersen です。これを使うと、VSCode は保存時にコードを自動的に整形してくれます。これは、HTML、CSS、JavaScript、JSON、マークダウンなど、作業中のプロジェクト内のすべてのファイルが適切にフォーマットされることを意味します。エディターに必要なのは、「 Format On Save 」を有効にすることだけです。

最近作られた多くのツールと同様に、Prettier には「使いやすいデフォルト」が用意されてます。つまり、何も設定せずに Prettier を使用できるようになります。 (デフォルトに満足している場合)。これにより、重要な創造的な作業に取り組むことができます。

### コード lint ツール

lint はコードの品質を向上させるのに役立ちますが、開発中の早い段階で潜在的なエラーを発見する方法でもあります。これは優れたツールチェーンの重要な要素であり、多くの開発プロジェクトにデフォルトで組み込まれることになります。

ウェブ開発用の lint ツールは、主に JavaScript 用に存在します(ただし、HTML と CSS 用に利用できるツールもいくつかあります)。これは当然のことです。不明な HTML 要素または無効な CSS プロパティが使用された場合、これら 2 つの言語の回復力の性質により、何も壊れる可能性はありません。 JavaScript ははるかに脆弱です。たとえば存在しない関数を誤って呼び出すと、JavaScript が壊れてしまいます。したがって JavaScript の lint は、特に大規模なプロジェクトの場合には非常に重要です。

JavaScriptの lint に最適なツールは ESLint です。 ESLint は非常に強力で多機能なツールですが、正しく設定するのは難しいので、設定を正しくするのに何時間も費やしてしまう可能性があります。

ESLint を実行すると、そのままでは設定ファイルが見つからないというメッセージが表示されます。構成ファイルは複数の形式をサポートしていますが、このプロジェクトでは `.eslintrc.json` を使用します(先頭のピリオドはデフォルトで隠しファイルであることを意味します)。

ESLint は npm 経由でインストールされるため、第 2 章の説明に従って、このツールをローカルにインストールするかグローバルにインストールするかを選択できます。 両方を使用することをお勧めします。

* 共有するプロジェクトでは、独自のコピーを作成する誰もがプロジェクトに適用したルールに従うことができるように、常に ESLint をローカル依存関係として含める必要があります。
* ESLint をグローバルにインストールして、必要なファイルをすぐにチェックできるようにすることも検討してください。

わかりやすくするために、この章では ESLint のすべての機能については説明しませんが、特定のプロジェクトとその要件に適した構成を導入します。ただし、コードの外観(または検証)に関するルールを調整して強制したい場合は、適切な ESLint 構成を使用することで実現できる可能性が高いことに留意してください。

この章の少し後で、ESLint 構成を提供します。動作する構成が設定されたら、コマンドを実行すると有用な情報が得られます。 ESLint の出力例を次に示します。


```bash
./my-project/src/index.js
   2:8 error 'React' is defined but never used  no-unused-vars
 22:20 error 'body' is defined but never used   no-unused-vars
 96:19 error 'b' is defined but never used      no-unused-vars

✖ 3 problems (3 errors, 0 warnings)
```


**メモ:** 次のセクションでESLintをインストールしますが、今は気にしないでください。

他のツールと同様にコードエディターとの統合サポートは通常 ESLint に適しており、問題が発生したときにリアルタイムのフィードバックを提供できるため、より便利になる可能性があります。

![ESLint error integration shown in VS Code](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Introducing_complete_toolchain/eslint-error.png)

初期プロジェクトの設定
-----------

これらのツールを使用すると多くの「基本的な」問題が早い段階で発見されることがわかっているので、新しいプロジェクトを安全にセットアップできます。

コマンドラインを使用して、プロジェクトを作成し、初期ツールをインストールし、基本的な構成ファイルを作成できます。繰り返しになりますが、このプロセスを数回繰り返すと、デフォルトの設定がどのようなものであるかがわかるようになります。もちろん、これは可能な構成の 1 つにすぎません。

### 初期設定

OK、プロジェクトの初期設定を済ませましょう。

1. まずターミナルを開いて、見つけやすい場所に移動します。デスクトップ、あるいはホームフォルダーやドキュメントフォルダーでしょうか?
2. 次に以下のコマンドを実行してプロジェクトを保存するフォルダーを作成し、そのフォルダー内に移動します。

```bash
mkdir will-it-miss
cd will-it-miss
```

3. 次にウェブサイトのすべての開発コードが存在する新しいディレクトリーを作成します。今すぐ次のコマンドを実行します。

```bash
mkdir src
```

コードの構成は、チームごとにかなり主観的なものになる傾向があります。このプロジェクトの場合、ソースコードは `src` 内に存在します。
4. `will-it-miss` ディレクトリーのルート内にいることを確認し、次のコマンドを入力して、ディレクトリー上で動作する git のソース管理機能を開始します。

```bash
git init
```

これはフォルダーの内容のリビジョンを保存したり、リモートリポジトリーへの保存などを開始できることを意味します。これについては後ほど詳しく説明します！
5. 次に以下のコマンドを入力して、ディレクトリーを npm パッケージに変換します。これには、前の記事で説明した利点があります。

```bash
npm init --force
```

これにより、デフォルトの `package.json` ファイルが作成され、必要に応じて後で構成できます。 `--force` フラグを指定すると、コマンドは(前に見たように)どのようなコンテンツを含めるかについての通常の質問を一切せずに、デフォルトの `package.json` ファイルを即座に作成します。現時点ではデフォルトのみが必要なので、これにより時間を少し節約できます。

#### プロジェクトコードファイルの取得

この時点で、プロジェクトのコードファイル( HTML、 CSS、 JavaScript など) を取得し、 `src` ディレクトリーに置きます。この章の目的ではないので、これらのファイルがどのように機能するかについては説明しません。 この章では、ツールがどのように動作するのかを教えるために、単にツールを動作させるためのものです。

1. コードファイルを入手するには、https://github.com/remy/mdn-will-it-miss にアクセスし、このリポジトリーの内容をローカルドライブのどこかにダウンロードして解凍します。 *Clone or download* > *Download ZIP* を選択すると、プロジェクト全体を zip ファイルとしてダウンロードできます。

 ![The GitHub will it miss repo](/ja/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Introducing_complete_toolchain/github-will-it-miss.png)
2. プロジェクトの `src` ディレクトリーの内容を、現在空の `src` ディレクトリーにコピーします。

これでプロジェクトのファイルが揃いました。これでとりあえずは完了です！

**メモ:** ローカルマシンでプロジェクトをセットアップするには、解凍したフォルダーのルートディレクトリーに移動し、その場所でターミナルを開き、ターミナルで `npm install` コマンドを実行する。これにより、 `package.json` ファイルに記載されているプロジェクトの依存関係がすべてインストールされます。

#### ツールのインストール

それでは、開発環境で使用するツールの初期セットをインストールしましょう。プロジェクトのルートディレクトリー内から次のコマンドを実行します。


```bash
npm install --save-dev eslint prettier babel-eslint
```


先ほど実行したコマンドについて、注意すべき重要な点が 2 つあります。1 つ目は、依存関係をプロジェクトにローカルにインストールしていることです。特定のプロジェクトに対してローカルにツールをインストールする方が良いです。ローカルにインストールすること（`--global` オプションを含まない場合）で、他のマシンでも簡単に同じ環境を再現することができます。

このインストールコマンドの2つ目の重要な部分は、 `--save-dev` オプションです。これによって、 npm ツールに対して特定の依存関係が開発にのみ必要であることを伝えます（したがって、 npm はこれらの依存関係を `dependencies` ではなく `devDependencies` として `package.json` ファイルにリストします）。これはつまり、このプロジェクトが本番モードでインストールされる場合、これらの依存関係はインストールされないということです。一般的なプロジェクトでは、本番で実際にコードを実行するためには不要な開発用の依存関係が多数含まれることがあります。それらを別々の依存関係として保持することで、本番環境へのデプロイ時の不必要な作業を減らすことができます（次の章で見ていく内容です）。

実際のアプリケーションコードの開発を始める前に、ツールが適切に動作するように少し設定が必要です。これはウェブ開発の前提条件ではありませんが、開発中にエラーをキャッチするのに役立つため、ツールが正しく設定されていると便利です。特に ESLint はその点で特に役立ちます。

### ツールの設定

プロジェクトのルートディレクトリー（ `src` ディレクトリーではなく）に、いくつかのツールを設定するための設定ファイルを追加します。具体的には、 Prettier と ESLint の設定です。これは一般的なツールの設定方法であり、通常設定ファイルはプロジェクトのルートに配置されます。これらの設定ファイルには、 JSON 形式で表現された設定オプションが含まれています（ただし、私たちのツールやその他の多くのツールは YAML もサポートしており、もしそちらを好みの設定ファイル形式とする場合は切り替えることもできます）。

1. まず、 `will-it-miss` ディレクトリーのルートに `.prettierrc.json` という名前のファイルを作成します。
2. Prettier を設定するために、 `.prettierrc.json` に以下の内容を記述します：

```json
{
  "singleQuote": true,
  "trailingComma": "es5"
}
```

これらの設定を使用すると、Prettier が JavaScript をフォーマットする際には、すべての引用された値にシングルクォートを使用し、末尾のカンマは使用しません（ ECMAScript の新しい機能で、古いブラウザーでエラーが発生する可能性があるものです）。 Prettier の設定についての詳細は、公式ドキュメントを参照してください。
3. 次に、ESLintの設定を行います。 `will-it-miss` ディレクトリーのルートに `.eslintrc.json` という別のファイルを作成し、以下の内容を記述します。

```json
{
  "env": {
    "es6": true,
    "browser": true
  },
  "extends": "eslint:recommended",
  "parserOptions": {
    "ecmaVersion": 6,
    "sourceType": "module"
  },
  "rules": {
    "no-console": 0
  }
}
```

上記の ESLint の設定では、"recommended" ESLint 設定を使用し、ES6の機能（例： `map()` や `Set()` など）の使用を許可し、モジュールの `import` 文を使用できるようにし、 `console.log()` の使用も許可しています。
4. ただし、このプロジェクトのソースファイルでは、React JSX 構文を使用しています（実際のプロジェクトでは React や Vue などのフレームワーク、またはフレームワークを使用しない場合もあります！）。
 JSX 構文をJavaScriptの中に挿入すると、 ESLint は現在の設定ではすぐに警告を出すことになります。そのため、 ESLint の設定に少し追加の設定を行い、JSXの機能を受け入れるようにします。
 最終的な設定ファイルは以下のようになります。太字の部分を追加して保存してください：

```json
{
  "env": {
    "es6": true,
    "browser": true
  },
  "extends": ["eslint:recommended", "plugin:react/recommended"],
  "parserOptions": {
    "ecmaVersion": 6,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    }
  },
  "plugins": ["react"],
  "rules": {
    "semi": "error",
    "no-console": 0,
    "react/jsx-uses-vars": "error"
  }
}
```

設定が現在「 React 」という名前のプラグインを使用しているため、この開発用の依存関係もインストールする必要があります。これにより、実際に lint プロセスのこの部分を実行するためのコードが存在します。
5. プロジェクトフォルダーのルートで、以下のターミナルコマンドを実行してください。

```bash
npm install --save-dev eslint-plugin-react
```


ESLintのルールは、 ESLint rules のリスト があり、心のままに調整して設定することができます。多くの企業やチームが独自の ESLint 設定を公開しており、これらはしばしばインスピレーションを得るのに役立つこともありますし、自分の基準に合ったものを選択する際にも便利です。ただし、注意が必要です： ESLint の設定は非常に奥深いものです！

ここまでで、開発環境のセットアップが完了しました。これで、ついに（ほぼ）コーディングの準備が整いました。

ビルドおよび変換ツール
-----------

このプロジェクトでは前述した通り、 React を使用し、そのためにソースコードではJSXを使用します。また、プロジェクトでは最新の JavaScript 機能も利用します。

直近の課題として、ブラウザーは JSX をネイティブにサポートしていません。 JSX は中間言語であり、本番コードではブラウザーが理解できる言語にコンパイルする必要があります。

ブラウザーがソース JavaScript を実行しようとすると、すぐにエラーが発生します。このプロジェクトでは、ブラウザーが問題なく読み込めるようにソースコードを変換するためのビルドツールが必要です。

変換ツールはいくつか選択肢がありますが、特に人気のある WebPack の代わりに、このプロジェクトでは Parcel を使用することにします。 Parcel は設定が少なくて済むため、特にこの選択になりました。

Parcel は開発要件を自動的に設定しようとする仕組みで動作します。 Parcel はコードを監視し、開発中にライブリロードするウェブサーバーを実行します。これはまた、 Parcel がソースコード内で参照されると自動的にソフトウェアの依存関係をインストールすることも意味します（第 3 章で見た内容です）。

Parcel は、必要な変換ツールと設定を、私たちが介入することなく自動的に処理します（ほとんどの場合）。

そして最後の特典として、Parcel はコードをバンドルして本番デプロイの準備をし、最小化やブラウザーの互換性要件も対応します。

したがって、このプロジェクトには Parcel の依存関係もインストールする必要があります。ターミナルで以下のコマンドを実行してください。


```bash
npm install --save-dev parcel-bundler
```

### 将来使用出来る機能

このプロジェクトのコードは、完全に標準化されていない新しいウェブ機能を含むいくつかの新しいウェブ機能を使用しています。例えば、 Sass のようなツールに頼る代わりに、この特定のプロジェクトでは W3C の CSS ネスティングの提案を使用しています。 CSS ネスティングは CSS セレクターやプロパティを相互にネストできるため、より具体的なセレクタースコープを作成することができます。 Sass は最初のプリプロセッサのうちの 1 つであり、ネスティングをサポートしていた（もしくは最初のものであった）のですが、多年経過した現在、ネスティングは標準化される見通しとなり、これによりビルドツールを必要とせずにブラウザーで利用できるようになります。

それまでは、 Parcel が PostCSS のサポートを受けて、ネストされた CSS とネイティブにサポートされる CSS の間の変換を行います。 Parcel は PostCSS との統合をデフォルトで提供しています。このプロジェクトでは特に CSS ネスティング（ Sass の代わりに）を使用することに決めたため、プロジェクトには PostCSS プラグインを含める必要があります。

postcss-preset-env を使用し、「明日の CSS を今日使う」ことができます。以下の手順に従って設定を行います：

1. プロジェクトディレクトリーのルートに `.postcssrc` という名前の単一のファイルを追加します。
2. 新しいファイルに以下の内容を追加します。これにより、最新の CSS 機能を完全に使用できるようになります。

```json
{
  "plugins": {
    "postcss-preset-env": {
      "stage": 0
    }
  }
}
```


これで必要な作業はすべて完了です — なお、 Parcel はデフォルトで依存関係を自動的にインストールしてくれることを忘れないでください！

ツールチェーンのこの段階はかなり厄介なことがありますが、わざと設定や複雑さを減らすように意図して選んだツールのおかげで、開発フェーズで行うべき作業はこれ以上ありません。モジュールは正しくインポートされ、ネストされた CSS は正しく「通常の CSS 」に変換され、ビルドプロセスによる開発の妨げがありません。

さあ、ソフトウェアの開発が始められる準備が整いました！

変換の実行
-----

プロジェクトで作業を開始するために、コマンドラインで Parcel サーバーを実行します。デフォルトモードでは、コードの変更を監視し、自動的に依存関係をインストールします。これは便利ですね、コードとコマンドラインを行き来する必要がなくなります。

1. Parcel をバックグラウンドで起動するには、ターミナルに移動して以下のコマンドを実行します：

```bash
npx parcel src/index.html
```

依存関係がインストールされた後に、以下のような出力が表示されるはずです。

```bash
Server running at http://localhost:1234
✨  Built in 129ms.
```

Parcel は、react、react-dom、react-async-hook、date-fns、およびformat-numberを含む、コードで使用する依存関係もインストールします。したがって、最初の実行は通常のParcelの実行よりも時間がかかります。

**メモ:** もしプロジェクトでParcelを実行して `Error: ENOENT: no such file or directory` というエラーが表示された場合は、プロセスを`Ctrl` + `C`で停止してから再度実行してください。

サーバーは現在、表示されたURL（この場合は localhost:1234）で実行されています。
2. ブラウザーでこのURLに移動すると、サンプルアプリが動作しているのが見えるでしょう！

Parcel のもう一つの巧妙な仕掛けは、ソースコードの変更がブラウザーで自動的に更新されるという点です。試してみましょう。

1. 好きなテキストエディタで `src/components/App.js` ファイルを開きます。
2. "near misses" というテキストを検索し、代わりに "flying pigs" のような面白いテキストに置き換えます。
3. ファイルを保存し、ブラウザーで動作しているアプリに戻ります。するとブラウザーが自動的にリフレッシュされ、ページの上部にある "<date> there will be <number> near misses" という行が変更されていることに気付くでしょう！

また、 ESLint と Prettier も試してみることができます — ファイルから意図的に多くの空白を削除して、 Prettier を実行して整形してみたり、 JavaScript ファイルに構文エラーを導入して Parcel を使用して再ビルドした際に ESLint がどのようなエラーを表示するか確認してみたりしてください。

まとめ
---

この章では、かなり良いローカル開発環境を構築し、アプリケーションを作成する準備が整いました。

通常、ウェブソフトウェアの開発では、この時点で作成したいソフトウェアのコードを作成する段階に入ることになります。しかし、このモジュールはウェブ開発のコードそのものではなく、ウェブ開発周りのツールを学ぶことが目的ですので、実際のコーディングは教えません — 実際のコーディングについての情報はMDNの他の部分で見つけることができます！

代わりに、あなたがツールを使用するためのサンプルプロジェクトを用意しました。私たちは、残りの章でこのサンプルコードを使って作業することをお勧めします。そしてその後、 src ディレクトリーの内容を自分のプロジェクトに変更し、それを Netlify に公開してみることもできます！実際に次の章では Netlify へのデプロイが最終的な目標となります！

* 前のページ
* Overview: Understanding client-side tools
* 次のページ