ビルド

Author: shibukawa

docs/_sources/console.rst.txt

@@ -7,7 +7,7 @@
 
    console.log("ログ出力");
 
-これが一番使われるものだと思いますが、他にもいろいろあります。これを実装すべきといった仕様はないのですが、現状で各環境で実装されている仕様はLiving StandardとしてWHATWGにあります。しかし、どの環境でも使えるとは限りません。特に、TypeScript Playgroundでは使えないもの多数ありますが、これらは何もしないだけでエラーになるわけではありません。
+これが一番使われるものだと思いますが、他にもいろいろあります。これを実装すべきといった仕様はないのですが、現状で各環境で実装されている仕様はLiving StandardとしてWHATWGにあります。しかし、どの環境でも使えるとは限りません。特に、TypeScript Playgroundで使えないものが多数ありますが、これらは何もしないだけでエラーになるわけではありません。
 
  * https://console.spec.whatwg.org/
 

docs/_sources/contributors.rst.txt

@@ -28,6 +28,15 @@ Pull Requestをくださった方々
 * `@ichikawa-hiroki <https://github.com/ichikawa-hiroki>`_
 * `@eduidl <https://github.com/eduidl>`_
 * `@inductor <https://github.com/inductor>`_
+* `@tamo <https://github.com/tamo>`_
+* `@ota-meshi <https://github.com/ota-meshi>`_
+* `@ravelll <https://github.com/ravelll>`_
+* `@mottox2 <https://github.com/mottox2>`_
+* `@masayuki0109 <https://github.com/masayuki0109>`_
+* `@hnakamur <https://github.com/hnakamur>`_
+* `@c-bata <https://github.com/c-bata>`_
+* `@Yu0614 <https://github.com/Yu0614>`_
+
 
 フィードバックをくださった方々
 ------------------------------------

docs/_sources/deploy.rst.txt

@@ -267,7 +267,7 @@ Debianベースのイメージ作成とDockerの基礎
 
 それぞれのイメージの中ではいくつかの命令を使ってイメージを完成させていきます。
 
-``COPY\ は実行場所（コンテキスト）や別のイメージ（\ ``--from``\ が必要）からファイルを取得してきて、イメージ内部に配置する命令です。このサンプルでは使っていませんが、\ ``ADD``\ 命令もあり、こちらは\ ``COPY``\ の高性能バージョンです。ネットワーク越しにファイルを取得できますし、アーカイブファイルを展開してフォルダに配置もできます。\ ``RUN``\ は何かしらの命令を実行します。
+``COPY``\ は実行場所（コンテキスト）や別のイメージ（\ ``--from``\ が必要）からファイルを取得してきて、イメージ内部に配置する命令です。このサンプルでは使っていませんが、\ ``ADD``\ 命令もあり、こちらは\ ``COPY``\ の高性能バージョンです。ネットワーク越しにファイルを取得できますし、アーカイブファイルを展開してフォルダに配置もできます。\ ``RUN``\ は何かしらの命令を実行します。
 
 重要なポイントが、このイメージ作成のステップ（行）ごとに内部的にはイメージが作成されている点です。このステップごとのファイルシステムの状態は「レイヤー」と呼ばれます。このレイヤーはキャッシュされて、コンテキストとファイルシステムの状態に差分がなければキャッシュを利用します。イメージの内部にはこのレイヤーがすべて保存されています。実行用イメージはこのレイヤーとサイズの問題は心の片隅に置いておく方が良いですが（優先度としては10番目ぐらいです）、ビルド用のイメージはサイズが大きくなっても弊害とかはないので、なるべくステップを分けてキャッシュされるようにすべきです。また、キャッシュ効率をあげるために、なるべく変更が少ない大物を先にインストールすることが大切です。
 

docs/_sources/exception.rst.txt

@@ -32,7 +32,7 @@ A → B → Cと順番にタスクをこなすプログラムがあったとし
      // 最後に必ず呼ばれる
    }
 
-もし、回復処理で回復仕切れない場合は、再度例外を投げることもできます。
+もし、回復処理で回復し切れない場合は、再度例外を投げることもできます。
 
 .. code-block:: ts
    :caption: 例外の再送
@@ -174,7 +174,7 @@ JavaScriptの言語の標準に含まれていない、処理系独自の機能
 
 実際に実行時に例外が起きうる（どんなにデバッグしても例外を抑制できない）ポイントは、外部の通信とかごく一部のはずです。あまりたくさん例外処理を書く必要もないと思いますし、書く場合もどこに書いたかがわかりやすくなります。
 
-広くする問題としては、原因の違う例外が混ざってしまう点もあります。例えば、JSONのパースを何箇所かで行なっていると、それぞれの箇所で ``SyntaxError`` が投げられる可能性が出てきます。原因が違ってリカバリー処理が別の例外が同じ ``catch`` 節に入ってきてしまうと
+広くする問題としては、原因の違う例外が混ざってしまう点もあります。例えば、JSONのパースを何箇所かで行なっていると、それぞれの箇所で ``SyntaxError`` が投げられる可能性が出てきます。原因が違ってリカバリー処理が別の例外が同じ ``catch`` 節に入ってきてしまうと、正確に例外を仕分けを行って漏れなく対応する必要が出てきます。しかし、どの例外が投げられるかを明示できる文法がなく、実装のコードを見ないとどのような例外が投げられてくるか分かりません。そのため、「間違いなく対処できているか？」を判断するコストが極めて高くなります。
 
 ``Error`` 以外を ``throw`` しない
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -369,7 +369,7 @@ Node.jsで ``async`` / ``await`` やら ``Promise`` を一切使っていない
 
 これまでTypeScriptにおける例外処理の方法や作法などを説明してきました。しかし、ベースとなっているJaavScriptの制約により、お世辞にも使いやすい機能とは言えません。理由は以下の3つです。
 
-* Javaの ``throws`` のように、メソッドがなげうる例外の種類がわからなず、ソースの関数の実態やドキュメント（整備されていれば）を確認する必要がある
+* Javaの ``throws`` のように、メソッドがなげうる例外の種類がわからず、ソースの関数の実態やドキュメント（整備されていれば）を確認する必要がある
 * JavaやC++のように、 ``catch`` 節を複数書いて、型ごとの後処理を書くことができず、 ``insteadof`` を駆使してエラーの種類を見分けるコードを書く必要がある
 * ``Promise`` や　``async`` 関数で、何が ``reejct`` に渡されたり、どんな例外を投げるのかを型定義に書く方法がない
 
@@ -419,4 +419,4 @@ TypeScriptでも、いくつか方法が考えられます。
 例外についての文法の説明、組み込みのエラー型、エラー型を自作する方法、非同期処理の例外処理などを説明してきました。
 例外の設計も、一種のアーキテクチャ設計であるため、ちょっとした経験が必要になるかもしれません。
 
-TypeScript、特にフロントエンドの場合、例外を無視することはユーザーの使い勝手を悪くします。どのようなことが発生し、どのケースではどのようにリカバリーするか、というのをあらかじめ決めておくと実装は楽になるでしょう。
+TypeScript、特にフロントエンドの場合、例外を無視することはユーザーの使い勝手を悪くします。どのようなことが発生し、どのケースではどのようにリカバリーするか、というのをあらかじめ決めておくと実装は楽になるでしょう。

docs/_sources/functional.rst.txt

@@ -7,7 +7,7 @@ JavaScriptの世界には長らく、クラスはありませんでした。プ
 
 一方で昔からJavaScriptで関数型プログラミングを行おう、という一派はそれなりにいました。
 
-JavaScriptの出自からして、Schemerという関数型が好きだったブレンダン・アイクです。
+JavaScriptの出自からして、Schemeという関数型言語が好きだったブレンダン・アイクです。
 開発時の会社の方針でJava風の文法を備え、Javaに影響を受けた言語にはなっていますが、Javaのような静的型付けのオブジェクト指向のコンパイル言語とはやや遠い、プロトタイプ指向のインタプリタになっています。
 関数もオブジェクトとして、変数に入れたり自由に呼び出したりできる一級関数ですし、無名関数を気軽に作ったり、その関数が作られた場所の変数を束縛するクロージャとしても使えたり、関数型言語の要素も数多く備えています。
 

docs/_sources/module.rst.txt

@@ -35,7 +35,9 @@ npmjs.orgで配布しない、自作のアプリケーションやライブラ
 
    npm install --save-dev [パッケージ名]
 
-新しいコンピュータや他人のコンピュータ上で作業フォルダを作る必要があるときは、その以前インストールしたファイル一覧を元に ``npm install`` コマンドだけですべての必要なパッケージのダウンロードが完了します。 ``dependencies`` と ``devDependencies`` のパッケージがダウンロードされます。そのパッケージが他のパッケージに依存していたら、それらもすべてダウンロードしてインストールされます。 ``npm install --prod`` だと、 ``dependencies`` のみがダウンロードされます。初回にダウンロードされて ``package.json`` に登録されるときは、サブのパッケージも含めて ``package-lock.json`` というファイルに全バージョン情報が保存されます。 ``npm ci`` コマンドを使って、これに記録されたバージョンと厳密に一致したバージョンのみをダウンロードすることもできます。
+新しいコンピュータや他人のコンピュータ上で作業フォルダを作る必要があるときは、その以前インストールしたファイル一覧を元に ``npm install`` コマンドだけですべての必要なパッケージのダウンロードが完了します。 ``dependencies`` と ``devDependencies`` のパッケージがダウンロードされます\ [#]_\ 。そのパッケージが他のパッケージに依存していたら、それらもすべてダウンロードしてインストールされます。 ``npm install --prod`` だと、 ``dependencies`` のみがダウンロードされます。初回にダウンロードされて ``package.json`` に登録されるときは、サブのパッケージも含めて ``package-lock.json`` というファイルに全バージョン情報が保存されます。 ``npm ci`` コマンドを使って、これに記録されたバージョンと厳密に一致したバージョンのみをダウンロードすることもできます。
+
+.. [#] ただし環境変数 ``NODE_ENV`` が ``production`` に設定されていると、``--prod`` オプションを付けた場合と同じ動作になります。
 
 TypeScriptとパッケージ
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -401,7 +403,7 @@ TypeScriptはインポートしたものが型だけの場合に、出力から
 
 この挙動を制御するオプションが3.8から増えました。\ ``tsc --init``\ しても出力されない、レアなオプションです。
 
-``compilerOptions.importsNotUsedAsValues: "remove" | "preserve" | "error"
+``compilerOptions.importsNotUsedAsValues: "remove" | "preserve" | "error"``
 
 * "remove": 削除する（現行のデフォルトとおなじ）
 * "preserve": 型だけであってもインポートを残し、副作用が必ず発生するようになる