Parcelを使ったらその魅力は「Configを書かなくても良い」ではなく「Configを書かせない」なのだと気づいた

Webpackの対抗馬的に出てきたparcel。特に必要もなかったのでしばらくスルーしてたが、ちょっと触ったら思った以上に面白かったので気づきをまとめておきたい

parcel-bundler/parcel

なぜParcelが産まれてきたか？

フロントエンドのビルドツールはGrunt -> gulp -> Webpackと流れて、Webpackはかなりスタンダードになった。
この一方で、Webpack疲れとでも呼ぶべき現象が起きてきた。

一つの大きな理由として膨大になるconfigファイルが挙げられる。
Gruntやgulpの頃から、ビルドの設定ファイルが肥大化し、触れる人が少ない、属人化するみたいな現象は良くあった。

Webpackも例に漏れず、Configは簡素といえないものになることが少なくない。

• pluginとloaderという概念を分離している設計
• 昨今のフロントの責務の増加
• フロントエンドに携わる人口の増加
• CSSや画像までカバーしているWebpackの責務範囲

Webpackによる部分もあるものの、時代による部分は大きく、仮に今Gulpやgruntが生きていても、似たような問題は起きてたのではないかと予測している。

そんなこんなで、parcelは「Zero Configuration」というコンセプトを含む形で産まれてきた

本題：Parcelの真髄は「Configを書かなくても良い」ことではなく「Configが書けない」ことではないだろうか

Parcelの登場もあってか、「Zero Configuration」というのはWebpack4も対応してきた。またfuse-boxもZero Configurationについて言及している。

これらWebpack4やfuse-boxのZero Configurationは、「設定を書かなくてもすぐ動かせるよ」という意味と言って良い。「書かなくても動かせるし、書くことでカスタマイズも出来る」ということになる。

対してParcelは、Configファイルというのがそもそも無い。必要な設定は babelrc や eslintrc などそれぞれのrcファイルに書かせたり、pluginもpackage.jsonに記述されているものを勝手に読み込むという形になっている。 parcelrc のようなものは少なくとも公式には存在しない（プラグインが勝手に使ってしまってることはある）

この「そもそも無い」というのは「無くても動く」とは大きく異なる。触り心地としてはgulpやGruntよりもBrowserifyに近いだろう。
Configが無い分をCLIコマンドのオプションとして渡す部分もBrowserifyに近いものを感じる。

• Configが無いので肥大化しようがない。属人化が薄くなる
• 各ツールのrcファイルにお行儀よく記述することになるので、他のツールにも移植するときに使い回せる
• CLIコマンドなので、サーバーサイドエンジニアに馴染み深い

あえて制約をかけるというのは、シンプルになるので良いことが多い。
片一方、下記のような問題もあるだろう

• 内部で何をやっているかのブラックボックスが大きくなる
• 出力先、出力方法がある程度固定化される。parcelに縛られる
• 複雑なことをやろうとしたとき誤ったやり方をすると複雑度が上がる

これが確固たる明確な方針なのかはわからないが、少なくともどうしても必要になるまでは導入しないという方向性は見て取れる。

どこかのタイミングで障壁が出来て何らかのconfigが生まれる可能性はあるものの

Config一切無しでどこまで出来るのか？

正直に言えば、Configが無くて出来る事なんてどの程度なの？と思ったが、ここまでは検証できた

• index.htmlのビルド（読み込んでるjsファイルのビルド含め）
• 出力ディレクトリの変更（ — out-dirオプション）
• 複数エントリファイルのビルド（parcel build a.js b.jsみたいな列挙にはなる）
• WebWorkerのビルド（特に設定せずnew Workerを分離してくれた）
• dynamic importのファイル分離
• SCSSのビルド
• SVGを含むReactのビルド
• サーバーモード・HMR・SourceMap、及びそれぞれのdisable化
• manifestファイルの生成（要プラグイン）
• typescriptのビルド（要プラグイン）

思った以上に結構出来てしまった。よほど複雑なビルドケースでなければだいたい対応出来るんじゃないかと思ってしまう

その他のトピック

コードがきれい

さすが最近出来ただけあって、class、async、awaitを使ったモダンなコードの作りになっている。

プラグインも作ってみるのにある程度ソースを見る必要があったが、それほどの難解さは無かった。

awesome-parcel

公式がプラグイン・ドキュメント集がある。公式がこれを用意しているのはポイント高い

parcel-bundler/awesome-parcel

結局Parcelは本番環境で使えそうか？

個人的な結論としては、かなり使えると思っている。

ただWebpackから移植するような場合だと、それまでの制約があったりするので少々フィットしない場合が多いんじゃないかと思える。

主に使いやすいのは、例えば新規だったり「レガシー環境を徐々にモダンにしていきたい！」という場合だ。
こういうときには悪くない選択肢なんじゃないかと思っている。

また、create-react-appのejectの代わりに使ってみたりもしたが、こういうフォーマットが一緒の場合もかなり効果高いんじゃないかと思った。

例えばparcelではじめて見て耐えられなくなったらWebpackへ移植していく、みたいな方向もいいんじゃないかと思う。