たれぱんのびぼーろく

わたしの備忘録、生物学とプログラミングが多いかも

ブラウザとモジュールとバージョン管理

ブラウザはモジュールを持つか

ブラウザとモジュール

モジュール化は綺麗で管理しやすく安全なコードを生む。
モジュールは最高だ。
そして今や、ブラウザ(フロントエンド)でもモジュールは使える

モジュールは単体で動くのが主たる仕事ではない。
他のモジュールと共同して動くのだ。
そのためには、モジュールの読み込みが必要だ。

ブラウザの長きにわたる問題点は、モジュール読み込みの不在だった。
Scriptタグの連打とグローバル空間の汚染は最悪で、jsファイル内からは読み込みすら不可能だった。
しかしそれは過去のもの、全てはimportが解決した。

import

import ~~~ from “module_name”;

主要ブラウザは全て、import文に対応している.
Can I use... Support tables for HTML5, CSS3, etc

Node.jsではフラグ立てれば使える.
モジュールチーム
GitHub - nodejs/modules: Node.js Foundation Modules Team

モジュール解決

次の段階は、import対象だ。
つまり、import ~~~ from “module_name”; のmodule_nameだ。
対象のディレクトリをハードコードしたくない
つまり、module specifierの管理であり、module resolutionとそのalgorithmだ。

GitHub - domenic/package-name-maps: How to solve the web's "bare import specifier" problem

ESモジュール特有のつらみ、そこから生まれる問題と解決策

ESモジュールはブラウザで使われる。
そしてブラウザはモジュールをインターネット越しにダウンロードする。
ゆえにモジュール読み込みはとても時間がかかる。
モジュールを読み込むたびに実行していると、日が暮れてしまう。
だからESモジュールでは(commonJSとは異なり) モジュール解決とモジュール実行を非同期にしている。
そのつらみの結果、モジュール名に変数を入れられない問題が発生する。
なぜなら変数は、コードを実行しないと生まれないからだ。
変数はロードするモジュールの分岐等に有用なため、つらい。

そこで出てくるのがDynamic import、つまり実行後のモジュールimportだ。

モジュール解決の現状

webpack

resolve.alias to your webpack.config.js
How to avoid relative path hell in JavaScript / TypeScript projects – @goenning

I think babel has something like this using ‘@/thing/…’, but I don’t use babel.

It’s called modules resolving and webpack can do it too: https://webpack.js.org/configuration/resolve/. Take a look :)

参考文献

スーパークール必読参考文献

hacks.mozilla.org