![見出し画像](https://assets.st-note.com/production/uploads/images/132213962/rectangle_large_type_2_543cf197bd2605b92421f4a5d10a5fd5.jpeg?width=1200)
2月22日 kintoneのカスタマイズの手段、どれを選ぶか。
2月22日ですね。
数年前に別の会社様によって作られたJavaScript+TypeScript+React+Webpackを作り直す作業をしています。
その時のライブラリやライブラリ間の依存関係を解きほぐし、うまく依存関係が整うようにするのも大変です。
こういう作業をたまにしますが、その度にwebpackにするメリットを考えます。
確かに大規模アプリであれば、webpack化は必要です。kintoneはアプリごとに入れられるJavaScriptの数にも30と言う限りがあります。
https://jp.cybozu.help/k/ja/admin/javascript_fullcustomize.html
そもそも複雑な処理の場合、イベント発火の順序の制御などを整え、ブラウザによる見た目や処理の違いを吸収してくれるwebpackは重宝します。
ですが、今回の件はそこまで複雑なJavaScriptではありません。にもかかわらず、webpackが使われています。そのため、依存関係の解析や環境の再現も含めて手間がかかっています。
これ、他のkintone開発会社さんはどのように切り分けをしているのでしょう。
どの規模の案件、アプリであればwebpackでパッキングするのか。
興味があります。
そういえば先々月には別のお客様でwebpackされていたものを全部分解してJavaScriptで入れ直す作業もしました。
弊社としてもJavaScriptで行くのかwebpackにするのか、ガイドライン(アクアビット蒸留書)の中で謳っておかないとブレるリスクがあります。
また、PolyfillやBabelを組み込むかどうかの判断基準なども詳しく盛り込まないと。
さらに、自社で作成するプラグインもどうするか考える必要があります。
多分、こう言う複雑さやガイドライン策定の手間を考える手間が大変だから、各社さんは有償プラグインや連携サービスの導入に踏み切るのでしょうね。
弊社としてもサービス提案の際、自社で作ったJavaScript、webpack、プラグインなども含め、アクアビット蒸留書の拡充を考えていく必要がありそうです。
いいなと思ったら応援しよう!
![Yoshikazu Nagai(長井 祥和)](https://assets.st-note.com/production/uploads/images/2511383/profile_fd0b0bd04ef61ae58d6f6f9fde934db6.jpg?width=600&crop=1:1,smart)