.mjs とは何か、またはモジュールベース JS とエコシステムの今後

Intro

長いこと議論になっていた ES Modules の Node における扱いに一応の決着が付き、.mjs という拡張子が採択された。

この拡張子の意味と、今後ブラウザと合わせて Universal JS を実装していく上での作法が見えてきたことになる。

合わせてエコシステムが対応していくことで、長年の夢だった JS のモジュール化を進めていくことができるだろう。

ES Modules

徐々に揃いつつある ES Modules(ESM) の仕様は TC39 で行われており、その仕様については主に以下のような部分になる。

import や export と行った構文
module 内はデフォルト strict mode
module でスコープを閉じる
module 内の this は undefined
etc

逆に以下は TC39 での策定範囲外となる

どう Module を読み込むか
どう依存を解決するか
etc

これは、読み込みに関わる部分は実行環境に大きく依存し、それは JS 自体が定義する問題ではないからである。

実際にブラウザと Node.js で見ても、その扱いは大きく変わってくる。

ESM / CJS

そもそも ES modules(ESM) が CommonJS(CJS) とは違う構文を策定したのには理由がある。

// commonjs
const foo = require("./foo")
module.exports = { message: "hello world" }

// ex modules
import foo from "./foo"
export default { message: "hello world" }

CJS は ESM 以前の JS の範囲で実装されていたため、require 関数や modules オブジェクトへの操作を特別扱いすることで実現していた。

しかし、この方式では例えば以下のように書くことも、JS の範囲である以上正しくなってしまう。

// commonjs

let version
if (Math.random() < 0.5) {
  version = 1
} else {
  version = 2
}
const foo = require(`./foo.v${version}`);

これでは、実行してからでないと、foo.v1, foo.v2 どちらで依存解決すべきかわからない。

したがって browserify などは、こうした書き方はしないという前提でビルドを行なっていた。

ESM は、関数やオブジェクトではなく、新しく「構文(syntax)」を用意することによって、この問題を解決している。

// ex modules
import foo from "./foo"
export default { message: "hello world" }

構文を定義することで、パースを行なった時点で曖昧な書かれ方をしている部分を Syntax Error として弾くことができる。

また、パースが通るということは、正しく依存関係を把握できているということになり、実行する前に依存解決が可能であることも意味する。

この実行しないでも良いという構文の利点は、静的解析ツールなどとも相性が良く、CJS を置き換える非常に良い仕様となった。

実行環境における ESM の扱い

TC39 の責任範囲は、JS ファイル内に書かれる構文が中心であり、そのファイルが実際にどう扱われるかは、実行環境の責務となる。

特に実行環境がどう扱うかについて、もっとも重要なのが、そもそもそのファイルが CJS か ESM か の判別である。

判別が正しく行えなければ、先述のデフォルト strict mode や、トップレベルの this を undefined と扱うと行った処理ができなくなるからである。

(ここでの CJS は、require() や module を使っているかというよりも、単に ESM ではないという意味が強い)

Modules on Browser

ブラウザにおける Module の扱いは、HTML の範囲での仕様策定を伴う。

具体的には、<script> タグの type 属性を用いて Script であるか Module であるかを判別することが可能だ。

<script type=module src=module.js></script>
<script type=text/javascript src=analytics.js></script>

また、ここに加えて nomodule 属性を用いて「ブラウザが modules を実装しているかどうか」の判別も可能となっている。

詳しくは以下の記事で解説している。

ES Modules への橋渡しとしての nomodule 属性

このように、ブラウザは読み込む前にそのファイルを Script/Module どちらとしてパースするかを判断することができる。

パースが正しく終われば、依存を解決のために追加の Fetch を以下のように行う。

ブラウザによる ESM の依存解決と Parse/Fetch の順番

あとはそのまま実行するだけなので、問題なく使うことができる。

Modules on Node.js

Node.js においては、パース時にそのファイルが ESM/CJS どちらなかのかを判別する方法を長く議論していた。

いくつかの案があったが、代別すると 2 種類ある。

パースする前にわかる
- package.json に module であることを書く
- .mjs や .m.js などの拡張子にする
パースしてわかる
- ファイルの先頭に "use module;" と書く
- 必ず import や export default を書く
- まず ESM としてパースしてだめなら CJS としてやり直す