早速着手
導入
導入手順は通常の方法であり、npm パッケージマネージャーに依り実行。
npm i @yamato-daiwa/es-extensions -E配布容量関連
npm公式サイトの@yamato-daiwa/es-extensionsのページでは、当パッケージの圧縮されていない状態の容量（「Unpacked Size」）が表示されている。 例えば、バージョン1.5.8の場合は698キロバイトである。
多くの容量は、ECMAScriptモジュール（ブラウザーのアプリケーションにとって最適） とCommonJSモジュール（Node.jsアプリケーションにとって規定）で占められている。 此の様に上記の中からどのモジュールを選んでも、多くのファイルは無視される。
サーバ・コンソールNode.jsアプリケーションの場合、数百キロバイト程度の増加は 大した問題ではない事が多い。 だが、ブラウザーアプリケーションであればプロジェクト構成手段を用いて、 本番用構成からライブラリで使われなかった機能を除外する事が重要だ。
Webpackの場合、此の機能は
「Tree shaking」と呼ぶ。
本番用構成モードで此れを有効化するには、
TypeScript設定
でES系のモジュールを指定しなければいけない。
二つ目の条件、即ち依存性が有るpackage.jsonの
sideEffects: falseの指定は、@yamato-daiwa/es-extensions
に依って満たされている。
Webpackと競合するプロジェクト構成手段を使っている場合、此の手段は似た様な未使用機能の除外に
対応しなければいけない。
TypeScriptの非利用者に対する注意事項
我々のライブラリ開発は、TypeScript利用者の補助を
優先している。
其の理由は、先ず当ライブラリ開発者のJavaScript言語に対する評価であり、曰く
「JavaScriptは実用性の有る#現代の[+Keyword--YDID 商業]アプリケーションやウェブサイト等の
高品質開発には向いていない言語」。
然しTypeScriptであれば話は全く違ってくる。
完成されたオブジェクト指向プログラミングへの対応力、
フレキシブルなタイピング感、更にブラウザー専用JavaScriptや
Node.jsへのトランスパイリングは根本的に流れを変える。
TypeScriptのコンパイルエラーが無ければ、当ライブラリ関連で問題が発生する可能性は低い。 然し、当ライブラリをJavaScript利用者が使う事も予想される。
ソースコードをJavaScriptへ変換する際、TypeScriptトランスパイラ は新規機能の中に何も追加しない。 特にTypeScriptのソースコード上で指定された関数・メソッドの 引数の型確認が、JavaScript上では実行されない 。 其の上で、JavaScriptへの対応策を考える場合、関数・メソッドの 引数の型の確認をしっかり実装する必要が有った。 此の実装は一見大したコード量には見えなさそうだが、事実上、関数等でコード量が 数倍に膨れ上がると言っても過言ではない（具体例を参照 )。
様々な情報を収集、分析した結果、引数の完成後の妥当性確認は実装しない事と成った。 主な理由としては、ライブラリの全体的な容量の急増、且つ多数の関数等の推移依存性の急増が懸念され、 其れはキロバイト数を厳格に節約しなければならないブラウザーアプリケーションにとって無視出来ない問題だからだ。 と言う事は、TypeScriptではなくJavaScriptで当ライブラリを使う場合、 型不整合関連エラーが発生する可能性が高い。 だがエラーメッセージから原因が判明するとは限らず、「ライブラリのせいだ」等と誤解される事態も予想される。
機能のインポート
当npmパッケージの導入後に、当サイト内で紹介している関数やクラス等の
インポートが可能と成る。
標準のインポート方法は、importキーワードをサポートしている
ランタイムやプロジェクト構成手段の場合なら、例えば以下の様に行う。
import { addElementsToArray, removeNthCharacter } from "@yamato-daiwa/es-extensions";