MATSUKAZE.NOTE

素晴らしきParcelと、開発環境の今

素晴らしきParcelと、開発環境の今

Parcel って何？

今回はモジュールバンドラーである Parcel の話です。まずは Parcel とは何物なのか。

驚くほど速く、設定不要なWebアプリケーションバンドラー

というのが Parcel の売り文句であり、つまりは webpack の仲間です。Webアプリケーションバンドラーあるいはモジュールバンドラーは、Webページ・アプリケーションを構築するにあたって必要なファイル、例えばJavaScriptファイルやCSSファイルを必要に応じてコンパイルし、ひとまとめにパッケージングしてくれます。古くは Grunt や gulp で同様の処理をする事もありましたが、これらは「タスクランナー」であるので、少しだけ役割が異なるでしょう。

ところで、これらのツールを使う為には「黒い画面」に慣れなければなりません。それが困難である非エンジニアのWebデザイナー・コーダーの方にはGUIコンパイラが便利でしょう。CodeKit や Prepros が有名らしいのですが、このあたりは明るくないのでここでは詳しくは触れずにおきます。大昔にLessのGUIコンパイラを自作したのが思い出されます。

話が逸れましたが、今回のテーマは「すごいぞParcel」です。

Parcel のここがすごいぞ

Parcelの強みは「驚くほど速い」「設定不要」の2点とされていますが、ここでは特に後者の「設定不要」を強く推したいです。なぜなら、速さは設定次第で前後しますが、ParcelをParcelたらしめているコンセプトは不動であるからです。

設定不可、つまりシンプル

「設定不要」という触れ込みですが、これはあまり正確ではなく、「（ほぼ）設定不可」がより正しくその在り方を表現していると思います。

例えば比較して webpack ならば、 多くの場合 webpack.config.js に細かい設定を記述して実行するでしょう。SassやTypeScriptからのトランスパイル、ミニファイやファイル分割、開発サーバーの起動まで、設定項目はあまりに多岐に渡ります。その多様性と柔軟性こそが webpack の強みでありましょう。

対して Parcel は、CLIでファイルを引数にして実行するのみで、設定ファイルなどは存在しません。設定出来るのは CLI のオプションに限られていて、それも提供されているのは必要最低限です。例えばこんな具合に指定します。

"scripts": {
  "dev": "parcel src/index.html -d public --no-source-maps"
}

これが Parcel で出来る事の全てであり、同時に Parcel を働かせる為のすべき事の全てであるのです。単純明快ですぐ使えるのが強みです。

必要なものは勝手に入れてくれる

モジュールバンドラーを働かせる為には、モジュールバンドラー自体の他に多くのライブラリが必要になります。TypeScriptや、Sass/Less/Stylus などのコンパイラ、 .vue ファイルを読みたいのであれば Vue とそのローダー等、作るものの種類や規模によって多くのモジュールを別途インストール必要があります。

Parcel ならば、 import した時点でそのファイルを扱うのに必要なモジュールを勝手に・自動的にインストールしてくれます。例えば次のようなHTMLに対して parcel コマンドを実行すると、ビルド前に sass と typescript が自動でインストールされるでしょう。

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
  <link rel="stylesheet" href="./assets/css/style.scss">
</head>
<body>
  <h1>Hello, World !</h1>
  <script src="./assets/js/main.ts"></script>
</body>
</html>

ただし、自動でインストールしてくれるのはあくまでビルドに必要な物だけなので、JavaScript で何かモジュールを、例えば lodash を入れたい場合に、それをコード内で import するだけでは当然導入してはくれません。もっともそれが実現してしまうと、モジュール名をタイポしてファイル保存しただけで、誤ったモジュールがインストールされまくってしまうという迷惑極まりない機能となるでしょう。

設定不可はデメリットなのか

「設定不可」というとネガティブに受け取られるかもしれません。そういう側面も勿論あるでしょうし、かゆいところに手が届かない場面もあるでしょう。しかし、そこで webpack の設定と対峙した時のシーンを思い浮かべてみます。

  1. やらせたい処理がある、または不具合に遭遇した
  2. webpack で出来るかどうかはわからないが、試してみよう
  3. 検索・試行錯誤して設定を足したり引いたりプラグインを導入してみたりする
  4. なんとか動作する、あるいは断念する

試行錯誤に多くの工数を溶かした末にやりたかったことが出来なかった、中途で断念した経験はないでしょうか。そこで費やされた時間は「webpackでは不可能・困難だった」という事を学習するためのコストとなったわけです。

これが技術選定や実装の段階の出来事であるならば、その経験にも価値を見出す事ができるでしょう。しかし残念ながら、これは作業を効率化するためのツールの設定に過ぎないのです。効率化しようとしていたら沼にはまってしまい、効率化で得られる恩恵並かそれ以上の時間を消耗し過ぎてしまった、ということも起こりうるでしょう。

Parcel ならば、そもそも設定のスイッチが数えられる程度にしかないので、「わからないが試してみよう」といって時間を奪われる事はほとんど起こりません。なぜなら出来る事と出来ない事は明確にされているのだから。Parcel を使うためには分岐がほとんどない Parcel Way に乗る以外に道はなく、悩む余地がありません。

すべきでないことは、できるべきでない

ここから盛大に話を脱線させますが、上で紹介している Parcel の魅力には Less の魅力と通じる物があるように感じます。

Less という物に馴染みのない方のために雑に説明しますと、Less とは Sass の仲間であり、「CSSプリプロセッサ」と呼ばれる物のひとつです。CSSをより効率的に書くための記法が定義されていて、その記法で書いた物はプロセッサに通す事で通常のCSSに書き換えられるのです。

さて、Less は Sass より後発で、当然 Sass の影響を色濃く受けているのですが、Sass と比較すると出来ることはかなり限定されています。Sass は条件分岐やループをプログラマティックに表現する事ができますが、Less ではできません。

これはあくまでも私見でしかないのですが、それらの表現がスタイルシートの責務でないから、出来ないようにしているのだと考えています。スタイルシートは実に静的な物なのだから、そのような動的な表現は極力使わないようにすべきだと。そういう姿勢に勝手に共感を覚え、長らく Less のファンを続けており、Sassの一人勝ちのようになっている昨今ですが、未だに使っています。

機能としてそれが備わっていれば、人は使います。使うべきでないと考える人はそれを回避したいと考えるでしょう。その可能性を、機能を実装しないことではじめから潰してあるのが Less なのだと、そう感じていました。そしてそれに類似した特性を Parcel から感じたのです。

脱線ここまで。

Parcel はどこで活躍するか

誇大広告のように無理やり書き連ねましたが、Parcel は一体どこで活躍できるのでしょう。

少なくとも、Webアプリケーション開発の最前線には居場所はなさそうです。React や Vue、特にNext や Nuxt といったフレームワークを採用するケースでは環境を create-*-app 等で初期化する事が多いと思いますが、それらのほとんどが webpack を軸にした構成になっています。折角公式で設定されているwebpackを引き剥がして Parcel を導入するというのはあまりに険しい道で、メリットなどは見当たりません。偏執的なParcel愛があるならば止めはしませんが。

小規模でレガシーな貴方に

Parcel が活躍出来るのは、もっと小規模でレガシー寄りな開発環境においてでしょう。

  • ものすごく小さいSPAを作りたい
  • 既存の静的サイトに部分的に Vue / React コンポーネントを差し込みたい
  • 昔制作したサイトの開発環境を刷新したい
  • WordPress のテーマ用にJS/CSSをコンパイルしたい

ぱっと思い当たるのはこのあたりです。Webアプリケーション開発に携わっていると感覚が麻痺してしまいがちですが、実際はこういった小さな開発の方が数は多いのではないでしょうか。小さな物に Next/Nuxt のような巨大なフレームワークを採用するのは大仰に過ぎますし、Parcel ならば環境構築が秒で終わるので短期の開発に向いていると言えるでしょう。

サンドボックスな貴方に

開発を進める上で、簡易なサンドボックスが欲しくなる場面があります。最近では CodeSandbox という便利な物もありますが、オンラインだとリモートでのビルドを待たなければいけなかったりするので、ローカルで建てたい場合はコマンド一本でいける Parcel が便利そうです。

まとめ

昨今のWebの開発環境は、一言で言い表すとクレイジーだと思います。悪い意味です。

本稿では webpack ばかりを引き合いに出しましたが、storybook 等も同じです。彼らはとにかく、設定という名のもとに貴重な人的リソースを食いすぎる。そんなにも食いすぎて、結果一体何が育つのかというと、自身の内のブラックボックスだ、というからたちが悪いですね。

そんな現環境の愚痴を吐露するなかで、Parcel が光明をさすかもしれない可能性を感じたので、そういった祈りのようなものをネットの片隅に記録しておこうと思った次第です。Parcel は「こうあってほしかった」未来の一つの形であると、そう思います。

  • Parcel
  • Webpack
  • JavaScript
  • Less
  • Sass