ノンコーディングで kintone アプリのカスタマイズを行えるサービス、
”gusuku Customine” を、ようやく皆様にお披露目することが出来ました。現在、パブリックプレビュー中で、どなたでも無償で使用していただけますので、ぜひご自身のkintoneアプリで試していただき、ご意見やフィードバックなどいただければと思います。
ご自身で本格的に kintoneアプリの カスタマイズ開発をされている方は React や Vue.js を使ったり、ES2015, ES2016, ES2017、場合によっては TypeScript や Flow なんかも使って、生産性や品質を高めるためにモダンJSの要素を取り入れて開発を進めておられることと思います。
その際に Babel と共に定番で使われるのが Webpack です。弊社でも、この 2年ほどは 殆どの案件で Webpack を使って開発を行ってきました。Webpack を用いることにより CommonJS のように モジュールの仕組みを用いて JS開発を行うことができ、多くのモジュールが公開・提供されている npmエコシステムの恩恵を受けることができます。また、kintoneカスタマイズでは画像やCSSの組み込みに制約があるため、これらを JS化して kintoneアプリに組み込めることも大きな魅力と言えます。
（1つの jsファイルのサイズ上限、通常のカスタマイズでは 5MB、プラグイン内では 512KB という壁と闘いながらですが、、）
でも最近、
webpack疲れ
はないですか？
私の場合、Webpack のバージョンが 1系から 2 に上がった頃からはっきりと、「Webpack メンドクサイ」と感じることが増えてきました。
フロントエンド技術の移り変わりは激しく、kintoneカスタマイズ案件に求められる要件も複雑化しており、必要となるたびに都度 PostCSS やら svg やら loader と呼ばれる webpack のモジュール？ を webpack.config.js に追加していきました。
TypeScriptを導入した際には、当初 ts-loader を使っていましたが （当時の）Vue.js と相性が悪く awesome-typescript-loader に切り替えるなど、package.json と webpack.config.js がどんどん「秘伝のタレ」化していきました。
モジュール使うなら Webpack 、Webpack を入れとけば多い日も安心という風潮に違和感を隠せなくなった頃、標題のもとにさせていただいた、
webpack時代の終わりとparcel時代のはじまり
という Qiita記事を目にしたわけです。
設定不要のビルドツール
それまでにも、webpack以外のモジュールバンドラーを検討しなかったわけじゃありません。
私は kintone への jsファイルアップロード（deploy）に自作の gulp プラグインを使用していたので、これも含めて FuseBox への乗り換えを検討したこともありました。
でも、通常のフロントエンド開発で使えるツールが kintone アプリのカスタマイズ開発においても同じようにうまく使えるケースばかりではありません。
Parcel についても、一番最初に試した際には思うように動かず、まだ様子見だなと思ったことを覚えています。しかし、Parcel の「設定ファイルが不要・存在しない」というコンセプトには明らかな魅力があり、TypeScriptサポートや Vue.jsサポートが入っていく状況を見ながら、乗り換える機会をうかがっていたのです。
エモい話はこれぐらいにして、Parcel を使って実際に開発を行う手順を見ていきましょう。
Parcel を使用する場合は Webpack とは異なり、loader が必要ありません。
package.json の devDependencies に大量に入れていた、なんちゃら-loader をごっそり削っています。
代わりに “parcel-bundler” と Vue.js を使う場合は “parcel-plugin-vue” を入れます。
繰り返しますが、Parcel には「設定ファイルが存在しない」ので webpack.config.js は要りません。
parcel src/entry.js -d dist
を実行すれば 監視（watch）モードでの build が行われ、dist フォルダへ モジュールバンドルされた entry.js と entry.map （source-map ファイル）が出力されます。
エントリポイント（src/entry.js）以下で参照されているソースコードを変更すれば cacheを使用して自動的に build し直されます。適当なタイミングで kintone へ jsファイルをアップロード（deploy）するなり、httpsで参照できるようにして動作確認を行います。
kintone へは source-map ファイルをアップロード（deploy）することが出来ないので、Chrome の開発者ツールで右クリックして、手動で「Add source map…」します。
Source map URL には「http://localhost:1234/entry.map」を入力します。
ソースコードが認識されるので、ブレークポイントを設定するなど、効率的に開発作業を進めることが出来ます。
（この手順は手作業が必要なので少し面倒ですね。kintoneの jsファイルサイズ上限 5MBの壁に阻まれることも多いのですが inline-source-mapを使えると良いのですが。リファレンスを見たのですが、現状 Parcel では inline-source-mapするオプションはないようです。）
開発が完了したら、環境変数「NODE_ENV」に「production」を設定して
parcel build src/entry.js -d dist --no-source-maps
で buildすると productionモードで出力されます。Vue.jsも問題なく使用できることを確認できました。なお、Parcel を使用するには Node.js の 8.x 系以降を使用する必要があります。
いかがだったでしょうか。
実は、私自身はこのところあまりスクラッチで kintone のカスタマイズ開発を行っていないこともあり、現状で Webpack を捨てて全面的に Parcel へ移行できるかと言われると、十分に試せていないので分かりません。
しかし、このところの Parcel の充実ぶりや支持の広がりを見ていると、「parcel時代」が始まりつつあるように感じます。
半年後には状況がガラリと変わって、全く別のツールがスタンダードになったりすることもあるフロントエンド界隈ですから、キャッチアップするのがしんどいなと感じたら、水面下で足をもがく役割は我々のような専門家に任せ、gusuku Customine のように 生産性の高い開発ツールを検討に入れていただければ幸いです。
