いろいろ

Author: shibukawa

baseenv.rst

@@ -5,6 +5,7 @@
 環境構築の共通部分を紹介しておきます。
 
 プロジェクトでのコーディングであれば、誰が書いても同じスタイルになるなど、コード品質の統一が大切になりますので、単なる個人用の設定ではなく、それをシェアできるというのも目的として説明していきます。
+
 ここでは、基本的にすべてのプロジェクトでJest、ESLint、Prettierなどを選択しています。まあ、どれも相性問題が出にくい、数年前から安定して存在している、公式で推奨といった保守的な理由ですね。きちんと選べば、「JSはいつも変わっている」とは距離を置くことができます。
 
 * Jest
@@ -214,18 +215,29 @@ Prettierの設定ファイルも作成します。シングルクオートの有
 Visual Studio Codeの設定
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-VSCodeから利用する場合は、拡張機能と、その設定をファイルに記述しておきます。まずは拡張機能です。
+Visual Studio Codeから利用する場合は、拡張機能と、その設定をファイルに記述しておきます。まずは拡張機能です。
+
+Visual Studio Codeでフォルダを開いたときに、必要な拡張機能がインストールされるようにします。\ ``.vscode``\ フォルダにファイルを作ることで、プロジェクトのソースコードと一緒に、プロジェクトの共有設定を共有できます。同じ拡張機能を入れてもらって、コードチェックなどのクオリティを統一し、コードインテグレーション時に無駄な調整をしなくて済むようにできます。ここではついでにコードのスペルチェックの拡張機能も入れておきます。
+
+この設定はこのJSONを書いても良いですし、拡張機能のページで該当する拡張機能を開いてから、コードパレットで\ ``Extensions: Add to Recommended Extensions (Workspace Folder)``\ を選択すると追加されます。
+
+.. figure:: images/add-to-recommendation.png
+
+   拡張機能をプロジェクト推奨に設定
 
 .. code-block:: json
    :caption: .vscode/extensions.json
 
    {
      "recommendations": [
        "esbenp.prettier-vscode",
-	   ],
+       "streetsidesoftware.code-spell-checker"
+     ],
      "unwantedRecommendations": []
    }
 
+インストールができたら、次はその拡張機能の設定をします。こちらもプロジェクトのリポジトリにファイルを入れておくことでプロジェクトメンバー間で共通の設定をシェアできます。
+
 Prettierを標準のフォーマッターに指定し、VSCode自身の実行メカニズムを利用してファイル保存時にフォーマットがかかるようにします。  
 
 .. code-block:: json
@@ -255,7 +267,15 @@ ESLintのインストールと設定はウィザードで作ります。
 
 モジュール形式はCommon.jsかES6 modulesか、使う場合はReactかVueか、Node.jsなのかブラウザなのか、TypeScriptを使うのかあたりを聞かれます。設定ファイルをどの形式で出力するか、最後に必要なパッケージをnpmでインストールするかも聞かれます。モジュール形式はES6 modulesを、TypeScriptの利用はYを、設定ファイルの形式はJavaScriptを、ツールのインストールはYを選択します。ウェブのフロントエンド、ブラウザ向けかNode.jsか向けかは環境に応じて選択してください。これインストールと設定は8割がた完了です。
 
-ESLintの設定は、機能を追加するプラグインと、設定をまとめて変更するextends、プロジェクト内部で個別に機能を切り替えるのはrulesに書きます。次のサンプルはブラウザ＆React、TypeScriptで生成したものに、Prettier関連の\ ``extends``\ を2つ追加したのと（必ず末尾におくこと）、個別ルールで、開発時のみ\ ``console.log()``\ を許可するように、返り値の型推論を許可しています。ESLintとPrettierでオーバーラップしている領域があり、ここで追加したextendsはそれらの設定が喧嘩しないようにするためのもので、ESLint側の重複機能をオフにします。React拡張を作成する場合は、Reactバージョンの設定をしないと警告を毎回見ることになるでしょう。 
+ESLintの設定は、機能を追加するプラグインと、設定をまとめて変更するextends、プロジェクト内部で個別に機能を切り替えるのはrulesに書きます。次のサンプルはブラウザ＆React、TypeScriptで生成したものに、Prettier関連の\ ``extends``\ を2つ追加したのと（必ず末尾におくこと）、個別ルールで、開発時のみ\ ``console.log()``\ を許可するように、返り値の型推論を許可しています。また、コールバック関数の利用でよくあるのですが、未使用引数で出る警告はライブラリ側の都合で避けようがなかったりするため、アンダースコアで始まる名前の変数に関しては未使用でも警告が出ないようにしています。
+
+ESLintとPrettierでオーバーラップしている領域があり、ここで追加したextendsはそれらの設定が喧嘩しないようにするためのもので、ESLint側の重複機能をオフにします。React拡張を作成する場合は、Reactバージョンの設定をしないと警告を毎回見ることになるでしょう。 
+
+先ほどの初期化でほとんどのツールはインストール済みですが、Prettierとの連携用設定のパッケージは入っていないので追加します。
+
+.. code-block:: bash
+
+   $ npm install --save-dev eslint-config-prettier
 
 .. code-block:: js
    :caption: .eslintrc.js
@@ -284,6 +304,7 @@ ESLintの設定は、機能を追加するプラグインと、設定をまと
        rules: {
            'no-console': process.env.NODE_ENV === 'production' ? 2 : 0,
            '@typescript-eslint/explicit-module-boundary-types': 0,
+           'no-unused-vars': ['error', { argsIgnorePattern: '^_' } ]
        },
        settings: {
            react: {
@@ -364,6 +385,31 @@ Visual Studio Codeの設定
 
     以前は次に紹介するPrettierをESLintの一部として組み込んで利用することがデファクトスタンダードでした。Lintのエラーもしかし、その場合、チェックのたびにコードをフォーマットしなおし、それからパースして文法のチェックが実行されます。ESLintはコーディングの中でなるべくリアルタイムに結果をプログラマーに提示する方が開発の流れが途切れずに品質の高いコードが量産できます。現在はフォーマッターとこのESLintは同期させないで個別に実行させるのが推奨となっています。
 
+ESLintの警告と特定の行だけ無効化する
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ESLintの警告はなるべく適用したいが、特別なコードだけ除外したいことがあります。逆をやることは基本的になく、なるべく厳しくして、特別な箇所だけ緩めてあげるのが一番やりやすい方法でしょう。例えば、コードジェネレータで生成したコードの警告を無効化したり、変数名の規則はcamelCaseだが、サーバーのレスポンスのみsnake_caseを許容したい場合などがあります。
+
+.. code-block:: ts
+   :caption: 特定の行のみ無効化
+
+   const { status_code } = await res.json(); // eslint-disable-line camelcase
+
+   // eslint-disable-next-line camelcase
+   const { status_code } = await res.json();
+
+
+.. code-block:: ts
+   :caption: 特定のブロック内のみ無効化
+
+   /* eslint-disable camelcase */
+
+   const { status_code } = await res.json();
+
+   /* eslint-enable camelcase */
+
+これ以外に、.eslintignoreでファイルごと無効化する方法など、さまざまな方法があります。
+
 テスト
 -----------
 
@@ -400,7 +446,7 @@ scripts/testと、jestの設定を追加します。古い資料だと、transfo
      ]
    };
 
-最後にESLintの設定です。これでJest固有のキーワードがエラーならなくなります。
+JestでもMochaでも、人気のフレームワークはテスト専用の関数などが定義されているものとしてテストコードを記述していきますが、これらの関数があるかどうかは、ESLintからは見えません。ESLintにさまざまな設定を追加することで、Jest固有のキーワードでもエラーがでなくなります。
 
 .. code-block:: json
    :caption: .eslintrc.js
@@ -422,40 +468,6 @@ scripts/testと、jestの設定を追加します。古い資料だと、transfo
    }
 
 
-Visual Studio Codeの設定
---------------------------------
-
-Visual Studio Codeでフォルダを開いたときに、eslintの拡張と、editorconfigの拡張がインストールされるようにします。\ ``.vscode``\ フォルダにファイルを作ることで、プロジェクトのソースコードと一緒に、プロジェクトの共有設定を共有できます。同じ拡張機能を入れてもらって、コードチェックなどのクオリティを統一し、コードインテグレーション時に無駄な調整をしなくて済むようにできます。ここではついでにコードのスペルチェックの拡張機能も入れておきます。
-
-.. code-block:: json
-   :caption: .vscode/extensions.json
-
-   {
-     "recommendations": [
-       "dbaeumer.vscode-eslint",
-     ]
-   }
-
-この設定はこのJSONを書いても良いですし、拡張機能のページで該当する拡張機能を開いてから、コードパレットで\ ``Extensions: Add to Recommended Extensions (Workspace Folder)``\ を選択すると追加されます。
-
-.. figure:: images/add-to-recommendation.png
-
-   拡張機能をプロジェクト推奨に設定
-
-ファイル保存時にeslint --fixが自動実行されるように設定しておきましょう。これでVisual Studio Codeを使う限り、誰がプロジェクトを開いてもコードスタイルが保たれます。Visual Studio Codeのeditor.codeActionsOnSaveは、files.autoSaveがafterDelayのときは効かないので、offに設定しておきます。
-
-.. code-block:: json
-   :caption: .vscode/settings.json
-
-   {
-     "editor.codeActionsOnSave": {
-       "source.fixAll.eslint": true
-     },
-     "files.autoSave": "off"
-   }
-
-ファイルを保存してみて修正されるか試してみましょう。もしされない場合は一度コマンドラインから実行してみてください。拡張で設定されているパッケージが足りない場合などはエラーが発生します。
-
 .. todo:: tsdocとかドキュメントツールを紹介
 
 .. todo:: eslintやテストの書き方の紹介

browserenv.rst

@@ -0,0 +1,34 @@
+ブラウザ環境
+==========================
+
+今も昔も、ウェブフロントエンドが今のJavaScript/TypeScriptの主戦場です。本章ではそのウェブフロントエンドの環境について紹介します。
+
+現在、メジャーなウェブフロントエンドのフレームワークというと、React、Vue.js、Angularです。本書で取り上げるのはReactとVue.jsです。React以外にReactをベースにした統合フロントエンドフレームワークとなっているNext.jsも取り上げます。Angularは2以降からTypeScriptに書き直されて、TypeScript以外では書けなくなり、最初からTypeScriptが有効な状態でプロジェクトが作成されるため、説明は割愛します。
+
+本章では、それぞれの環境の共通部分について紹介します。
+
+ウェブアプリケーションにおけるビルドツールのゴール
+-----------------------------------------------------
+
+JavaScriptでビルドといっても、いろいろなステップがあります。
+
+1. TypeScriptやBabelを使って、ターゲットとなるバージョンのJavaScriptに変換
+2. SCSSとかPostCSSを使ってブラウザにない機能を使って書かれたCSSを素のCSSに変換
+3. webpackなどを使って、1つのJavaScriptファイル、もしくは遅延ロードをするJSファイル群を生成
+
+実際には綺麗にステップが分かれることはなくて、バンドラーがimport文を追跡しつつファイルを探し、.tsを見つけてはTypeScriptで処理して（コンパイル）、コード中にSCSSを見つけてはSCSSの処理系に投げて、一つのファイルにまとめる（バンドル）・・みたいな工程を行ったりきたりしながらビルドします。以前は、これにJake、Gulp、Gruntなどのタスクランナーも組み合わせてやってましたが、今はwebpack単体にts-loaderなどを組み合わせる感じで一通りできます。webpackがシェア80%で一強です。
+
+しかし、ファイルを集めてきてコンパイルしつつ1ファイルにバンドルし、必要に応じてminify化してサイズを小さくするといったタスクは、比較的重い処理です。そのため、ウェブのフロントエンドのビルド環境は、開発者のストレスを軽減するために、さまざまな機能を備えてきました。
+
+* バンドルツールは毎回ファイルを読み込むのではなく、メモリに常駐し、変更されたファイルだけすばやく読み込んでバンドルを完成させる
+* ブラウザに対して、変更検知を伝えるコードを差し込んでおくことで、すばやくブラウザをリロードして最新のファイルを読み込む仕組み
+
+これらを実現するのが開発サーバです。開発サーバーはHTTPサーバーとして起動し、JavaScriptやHTML、CSSを配信するサーバーとしてブラウザからは見えます。その裏では、ファイルシステムのソースコードを監視し、変更があったら即座にビルドをして動作確認までのリードタイムを短くします。それだけではなく、その開発中のウェブサイトを見ているブラウザに対して強制リセットをしかけたり（ホットリロード）、起動中にJavaScriptのコードを差し替えたり（ホットモジュールリプレースメント）といったことを実現します。また、TypeScriptだけではなく、CSSでも、事前コンパイルでコーディングの効率をあげる方法が一般化しているため、この設定も必要でしょう。
+
+この分野では数多くのツールがあります。スキルのある人は自分の好みや要件に合わせてツールを選択すると良いでしょう。TypeScriptの対応についても、最初から対応していたり、後からプラグインで拡張など、いろいろなものがあります。
+
+webpackは細かくカスタマイズできますし、豊富な開発リソースで頻繁にリリースされています。ツリーシェイキングといった不要なコードを除外してサイズを小さくする機能にいち早く取り組んだり、業界をリードしています。困った時に検索すると情報も多く出てきます。一方で、TypeScript対応で開発サーバーやCSS対応など、機能を足していこうとすると設定やプラグインが増えていきます。特に、ReactのJSX構文を利用する場合は、バンドラーの処理の前段でTypeScriptをJavaScriptに変換したあとにBabelを使い、最後にバンドラーで1ファイルや複数ファイルにまとめるなど、ビルドのパイプラインが多段になりがちです。ReactやVueの環境構築ツールやNext.js、Nuxt.jsなどはwebpackを内包して、少ない設定の量で一定の機能を備えたビルド環境を整えてくれます。本書でも、webpackそのものを紹介することはしませんが、これらのツールの紹介をします。
+
+他にも数多くのバンドラーがあります。webpack以降に出てきたものの多くは設定が少ない、あるいは設定ファイルが不要（ゼロコンフィギュレーション）を売りにしたものが数多くあります。Rollupは人気のあるバンドラーで、TypeScriptを使うにはプラグインが必要ですが、そうでないのであれば設定がほとんど必要ありません。RollupをベースにTypeScriptサポートを最初から組み込んだmicrobundleもあります。HTMLやCSSのビルドもできて開発サーバーも全てついてくるオールインワンでビルド速度を重視したParcelや、Go製でビルド速度に特化したesbuildもあります。一方で、カスタマイズが必要なので最初からカスタマイズ前提でCLIを提供しないFuseboxなどもあります。
+
+

complex.rst

@@ -264,6 +264,8 @@ C言語由来のループは昔からあるものですがループ変数が必
 速度の面で言えば、旧来の ``for`` ループが最速です。 ``for ... of`` や ``forEach()`` は、ループ1周ごとに関数呼び出しが挟まるため、実行コストが多少上乗せされます。
 といっても、ゲームの座標計算で1フレームごとに数万要素のループを回さなければならない、といったケース以外ではほぼ気にする必要はないでしょう。
 
+``forEach()``\ 、\ ``map()``\ などのメソッドは関数型プログラミングの章でも紹介します。
+
 iterableとイテレータ
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -376,6 +378,17 @@ TypeScriptを使っていると、ES5への出力の場合型情報を見て、
 
 TypeScriptを使うと、型情報がついて実装が簡単になるだけではなく、速度のメリットもあります。
 
+配列のようで配列でない、ちょっと配列なオブジェクト
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TypeScriptがメインターゲットとしてるブラウザ環境では、配列に似たオブジェクトがあります。HTMLのDOMを操作したときに得られる、\ ``HTMLCollection``\ と、\ ``NodeList``\ です。前者は\ ``document.forms``\ などでフォームを取得してきたときにも得られます。どちらも\ ``.length``\ で長さが取得でき、インデックスアクセスができるため、一見配列のようですが、配列よりもメソッドがかなり少なくなっています。\ ``NodeList``\ は\ ``forEach()``\ はありますが、\ HTMLCollection``\ にはありません。\ ``map()``\ や\ ``some()``\ はどちらにもありません。
+
+どちらもイテレータは利用できますので、次のようなコードは利用できます。
+
+* ``for .. of``\ ループ
+* スプレッド構文
+* ``Array.from()``\ で配列に変換してから各種配列のメソッドを利用
+
 オブジェクト
 ---------------------
 

function.rst

@@ -150,7 +150,7 @@ TypeScriptでは関数やクラスのメソッドでは引数や返り値に型
    let check: (arg1: string, arg2: number) => boolean;
 
 ``arg2`` がもし関数であったら、関数の引数の中に関数が出てくるということで、入れ子の宣言になります。
-多少わかりにくいのですが、内側から順番に剥がして理解していくのがコツです。
+多少わかりにくいのですが、内側から順番に剥がして理解していくのがコツです。ネストが深くなり、理解が難しい場合はtype宣言で型定義を切り出して分解していく方が良いでしょう。
 
 .. code-block:: ts
 
@@ -185,6 +185,35 @@ TypeScriptでは関数やクラスのメソッドでは引数や返り値に型
    console.log(sort(a, s => s.toLowerCase()))
    // ["a", "B", "c", "D"]
 
+関数を扱う変数に、デフォルトで何もしない関数を設定する
+------------------------------------------------------------
+
+コールバック関数を登録しておく変数に対し、何も代入されないときに呼び出し元が存在チェックをサボっていると、\ ``undefined``\ に対して関数呼び出しをしたとエラーが発生します。その場合は、とりあえず何もしない関数を代入してエラーを回避したいと思うでしょう。
+
+JavaScriptの世界では型がないため、とりあえず引数を持たず、本体が空の無名関数を入れてしまうと回避はできます。
+
+.. code-block:: js
+
+   // 何もしない無名関数を入れておく
+   var callback = function() {};
+
+TypeScriptでは、例え引数を利用しなかったとしても、また実際に実行されないのでreturn文を省略した場合でも、変数の関数の型と合わせる必要があります。わかりやすさのために、変数宣言と代入を分けたコードを提示します。
+
+.. code-block:: ts
+
+   // 変数宣言（代入はなし）
+   let callback: (name: string) => void;
+   
+   // ダミー関数を設定
+   callback = (name: string): void => {};
+
+もちろん、1行にまとめることもできます。JavaScript的にはどれも違いのない「関数」ですが、引数と返り値が違う関数はTypeScriptの世界では「別の型」として扱われますし、何もしない無名関数は引数も返り値もない関数の型を持っている、という判断が行われます。実際のロジックが空でも定義が必要な点は要注意です。
+
+.. code-block:: ts
+
+   // 変数宣言（代入で推論で型を設定）
+   let callback = (name: string): void => {};
+
 デフォルト引数
 ----------------------
 

react.rst

@@ -1,25 +1,6 @@
 Reactの環境構築
 =====================================
 
-ウェブフロントエンドが今のJavaScript/TypeScriptの主戦場です。本章ではそのウェブフロントエンドの環境構築について紹介します。しかし、本書を書き始めたときに比べて、TypeScriptユーザーが増えるにつれて環境構築のサポートがどんどん手厚くなっているため、章の内容は減っています。そのため、1章でメジャーなフレームワークをすべて紹介することにしました。
-
-本書で取り上げるのはReactとVue.jsです。React以外にReactをベースにした統合フロントエンドフレームワークとなっているNext.jsも取り上げます。
-Agularは2以降からTypeScriptに書き直されて、TypeScript以外では書けなくなり、最初からTypeScriptが有効な状態でプロジェクトが作成されるため、説明は割愛します。
-
-ウェブアプリケーションにおけるビルドツールのゴール
------------------------------------------------------
-
-ウェブアプリケーションの環境構築は、ただコンパイルができるというだけではなく、TypeScriptからJavaScriptにトランスパイルされたファイルを1つや複数のチャンクにまとめるバンドラーというツールも必要です。また、開発サーバなどの設定も必要でしょう。開発サーバーはHTTPサーバーとして起動し、JavaScriptやHTML、CSSを配信するサーバーとしてブラウザからは見えます。その裏では、ファイルシステムのソースコードを監視し、変更があったら即座にビルドをして動作確認までのリードタイムを短くします。それだけではなく、その開発中のウェブサイトを見ているブラウザに対して強制リセットをしかけたり（ホットリロード）、起動中にJavaScriptのコードを差し替えたり（ホットモジュールリプレースメント）といったことを実現します。また、TypeScriptだけではなく、CSSでも、事前コンパイルでコーディングの効率をあげる方法が一般化しているため、この設定も必要でしょう。
-
-この分野では数多くのツールがあります。スキルのある人は自分の好みや要件に合わせてツールを選択すると良いでしょう。TypeScriptの対応についても、最初から対応していたり、後からプラグインで拡張など、いろいろなものがあります。
-
-webpackは細かくカスタマイズできますし、豊富な開発リソースで頻繁にリリースされています。ツリーシェイキングといった不要なコードを除外してサイズを小さくする機能にいち早く取り組んだり、業界をリードしています。困った時に検索すると情報も多く出てきます。一方で、TypeScript対応で開発サーバーやCSS対応など、機能を足していこうとすると設定やプラグインが増えていきます。特に、ReactのJSX構文を利用する場合は、バンドラーの処理の前段でTypeScriptをJavaScriptに変換したあとにBabelを使い、最後にバンドラーで1ファイルや複数ファイルにまとめるなど、ビルドのパイプラインが多段になりがちです。ReactやVueの環境構築ツールやNext.js、Nuxt.jsなどはwebpackを内包して、少ない設定の量で一定の機能を備えたビルド環境を整えてくれます。本書でも、webpackそのものを紹介することはしませんが、これらのツールの紹介をします。
-
-他にも数多くのバンドラーがあります。webpack以降に出てきたものの多くは設定が少ない、あるいは設定ファイルが不要（ゼロコンフィギュレーション）を売りにしたものが数多くあります。Rollupは人気のあるバンドラーで、TypeScriptを使うにはプラグインが必要ですが、そうでないのであれば設定がほとんど必要ありません。RollupをベースにTypeScriptサポートを最初から組み込んだmicrobundleもあります。HTMLやCSSのビルドもできて開発サーバーも全てついてくるオールインワンでビルド速度を重視したParcelや、Go製でビルド速度に特化したesbuildもあります。一方で、カスタマイズが必要なので最初からカスタマイズ前提でCLIを提供しないFuseboxなどもあります。
-
-Reactについて
------------------------------------------------------
-
 ReactはFacebook製のウェブフロントエンドのライブラリで、宣言的UI、仮想DOMによる高速描画などの機能を備え、現在のフロントエンドで利用されるライブラリの中では世界シェアが一位となっています。Reactによって広まった宣言的UIはいまやウェブを超え、iOSのSwift UIやAndroidのJetpack Compose、Flutterなど、モバイルアプリの世界にも波及しており、このコミュニティが近年のムーブメントの発信源となることも増えています。
 
 JavaScriptは組み合わせが多くて流行がすぐに移り変わっていつも環境構築させられる（ように見える）とよく言われますが、組み合わせが増えても検証されてないものを一緒に使うのはなかなか骨の折れる作業で、結局中のコードまで読まないといけなかったりとか、環境構築の難易度ばかりが上がってしまいます。特にRouterとかすべてにおいて標準が定まっていないReactはそれが顕著です。それでも、もう2013年のリリースから長い期間が経ち、周辺ライブラリも自由競争の中で淘汰されたりして、定番と言われるものもかなり定まってきています。環境構築においてもほぼ全自動で済むツール\ ``create-react-app``\ が登場しましたし、オールインワンなNext.jsも利用できます。そろそろ「枯れつつあるフレームワーク」としてReactを選ぶこともできるようになると感じています。

webparcel.rst

@@ -0,0 +1,147 @@
+Parcelを使ったウェブ開発
+=============================================
+
+React開発であればcreate-react-appやNext.js、Vueであれば@vue/cliやNuxt.js、Angularも@angular/cliといった、それぞれのフレームワークごとに環境構築をまとめて行う環境整備ツールが近年では充実してきています。
+
+しかし、そこから多少離れるものであったり、あるいはより高速なビルドが欲しいなど、要件によっては他のビルドツールで環境を作る方がプロジェクトにはマッチする可能性もあります。本章ではParcelを使った環境構築について紹介します。
+
+.. note::
+
+   現時点ではリリースされていないParcel 2.0を対象に説明します。
+
+Parcelとは
+--------------------------
+
+* https://v2.parceljs.org/
+
+Parcelはゼロコンフィグを目指したバンドラーです。ほとんど設定を書くことなく環境を準備できます。たとえプロダクション開発ではwebpackを使ったとしても、小さいコードをすばやく書き上げる場合などに知っておいて損はないでしょう。Parcelはビルド設定ファイルを作成することなく、エントリーポイントのファイルを指定するだけでビルドできます。エントリーポイントのファイルはウェブ開発であればHTMLファイルも使えます。そのHTMLから参照されているスクリプトファイルやCSSなどをすべて辿ってビルドしてくれます。
+
+TypeScriptも最初からサポートしています。tsconfig.jsonがあればそれを拾って解釈してくれますし、なくても動きます。単にtsファイルをscriptタグのsrcにするだけで、そのままTypeScriptの処理系をインストールしつつビルドしてくれます。最初のビルドも高速ですし、キャッシュもしてくれて2回目以降も速いです。TreeShakingとかの生成されたファイルの最適化機構も入っています。
+
+なお、ゼロコンフィグというか、設定ファイルがなかったので、ちょっと凝ったことをしようとすると、Parcelのビルド機能をAPIとして呼び出すウェブサーバーを書かねばならず、かえって大変になることもありましたが、Parcel 2からはちょっとした設定ファイルでデフォルト設定を変更できるようになりました。例えば次のようなことができるようになります。
+
+* TypeScriptのビルドでエラーメッセージが出せるようになった
+* APIサーバーへのプロキシができるようになった
+
+React環境
+--------------------------
+
+Parcelは環境構築は簡単ですが、全自動の環境構築ツールはありません。まずはプロジェクトフォルダを作り、package.jsonを作成します。
+
+.. code-block:: bash
+
+   $ npm init -y
+
+:doc:`baseenv`\ で紹介したように、PrettierとESLintを設定しておきましょ。
+
+次にParcelを追加します。
+
+.. code-block:: bash
+
+   $ npm install --save-dev parcel-bundler
+
+次にHTMLファイルを用意します。ポイントは前述のように、\ ``<script>``\ タグに読み込ませたいTypeScriptのコードを書くことです。
+
+.. code-block:: html
+   :caption: src/index.html
+
+   <!DOCTYPE html>
+   <html lang="en">
+     <head>
+       <meta charset="utf-8" />
+       <meta name="viewport" content="width=device-width, initial-scale=1" />
+       <meta http-equiv="X-UA-Compatible" content="ie=edge">
+       <title>Parcel Project</title>
+     </head>
+     <body>
+       <div id="root"></div>
+       <script src="./index.tsx"></script>
+     </body>
+   </html>
+
+最後にこのスクリプトを書き足します。
+
+.. code-block:: ts
+   :caption: src/index.tsx
+
+   import React, { StrictMode } from 'react';
+   import { render } from 'react-dom';
+
+   render(
+     <StrictMode>
+       <div>test</div>
+     </StrictMode>,
+     document.getElementById('root')
+   );
+
+ビルドを実行すればそのタイミングで拡張子を見てTypeScriptをインストールして実行はしてくれますが、先にインストールしてtsconfig.jsonを作っておきます。
+
+.. code-block:: bash
+
+   $ npx install --save-dev typescript
+   $ npx tsc --init
+
+デフォルトではES2015 modulesが有効になっておらず、ビルドターゲットが古いのでそこを修正するのと、今回はReactなのでJSXもreactにしておきます。
+
+.. code-block:: json
+   :caption: tsconfig.json
+
+   {
+     "compilerOptions": {
+       "target": "ES2018",
+       "module": "es2015",
+       "jsx": "react"
+     }
+   }
+
+.. code-block:: json
+   :caption: package.json
+
+   {
+     "scripts": {
+       "start": "parcel serve src/index.html",
+       "build": "parcel build src/index.html",
+     }
+   }
+
+TypeScriptのエラーを表示する
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+これでビルドと開発はできますが、デフォルトのParcelは\ ``@babel/preset-typescript``\ を使って型情報を切り落とすだけで型のチェックは行ません。VSCodeで編集すればその場でエラーチェックはしてくれますが、変更したファイルが他のファイルに影響を与えていてエラーになっていたり、警告が出ていた、というのはなかなか気付きにくいです。バリデーションを有効化すると、このようなトラブルは防げます。
+
+.. code-block:: json
+   :caption: .parcelrc
+
+   {
+     "extends": "@parcel/config-default",
+     "validators": {
+       "*.{ts,tsx}": ["@parcel/validator-typescript"]
+     }
+   }
+
+なお、執筆時点ではこのプラグインで自動インストールされるバージョンではエラーになってしまいます。nightly.430というバージョンであれば問題なく実行できました。将来解決されると思いますが、先行して利用するのであればこちらを使ってください。
+
+.. code-block:: bash
+
+   $ npm install @parcel/validator-typescript@2.0.0-nightly.430
+
+APIサーバーに対してプロキシする
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.proxyrcファイルを作成することで、一部のリクエストをAPIサーバーに受け流すといったことが可能です。これにより、フロントエンドとバックエンドが同じオリジンで動作するようになり、CORSなどのセキュリティの環境整備が簡単になります。もし、本番環境も別ホストで配信するのであれば、元々CORSの設定などは考慮されていて少ない労力でなんとかなると思われますが、そうでない場合、テスト環境のためにCORSを設定するといった大仰なことをしなくて済みます。
+
+.. code-block:: json
+   :caption: .proxyrc
+
+   {
+     "/api": {
+       "target": "http://localhost:3000/"
+     }
+   }
+
+なお、パスのリライトなど、高度なこともできます。しかし、動作しなかったときの問題追跡が面倒になるため、ホスト名の転送だけで済むようにしておくと良いでしょう。
+
+WebComponents開発環境
+--------------------------------
+
+あとで書く