本文へジャンプ

柔軟に対応できるフロントエンド開発環境を構築する 2022

Posted by kenta sugiyama

ナマのHTML、CSSを書いていた頃が懐かしいと感じる今日この頃ですが、今は今で様々な開発方法(モジュールバンドラ)が乱立しています。
MONSTER DIVEではみんながみんな同じ環境で開発するのではなく、それぞれのスキルセットに合わせて柔軟に対応できるようにベースとなる環境を用意しクリエイターそれぞれがカスタマイズして開発を進めています。
デザイナーなど非エンジニアがコードを触る機会もありますが最低限Sassは使用するという点だけ縛りがあります。 そんなMONSTER DIVEでのフロントエンド開発環境を簡単にご紹介します。

タスクランナー

「タスクランナー」とは、「タスク(仕事・課題)」をプログラム処理で自動化してくれるツール全般のことを指します。
フロントエンドの制作業務の中で出てくる単純作業を自動化してしまい、業務の効率化、サイトの品質を守るが目的です。
Grunt→Gulpとタスクランナーひとつを取っても遍歴のあるMONSTER DIVEでの開発環境ですが、現在はnpm-scriptsを採用しています。

npm-scripts

npm-scriptsとは、package.jsonファイルに記述可能なシェルスクリプトのエイリアスです。
package.jsonファイルに直接記述しても良いですし外部のJavaScriptファイルにタスクや設定を記述して読み込むことも可能です。

Why?

Grunt、Gulpなどのタスクランナーやwebpackなどのモジュールバンドラなど様々にある中でなぜnpm-scriptsを採用したか。
こちらのどれもNode.jsのモジュールとして動作するツールですが、Node.jsのインストール時に付属するnpm(Node Package Manager)を使用すれば処理を実行できるツールです。

Gulpやwebpackは歴史も深く有用ですが、逆に言えば様々なツールが乱立している現在では別のものに取って代わられる可能性もあります。GruntGulpに置き換わったように。
webpackもバージョンアップが引き続き行われていますが、ひとつのツールの依存し続けるのは良くないだろうということで原点回帰することにしました。
各ツールのメジャーバージョンアップ時の対応が不要になったり、Gulp運用時に使用していた様々なnode_modulesの知見を活かせるというのも理由のひとつです。

天変地異が起こってそもそもNode.jsを使わなくなったら、、というのは考えないことにします笑

パッケージマネージャ

先程のnpm以外にもNode.jsの代表的なパッケージマネージャにyarnがあります。

yarn

2016年にFaceBookが公開したJavaScriptのパッケージマネージャになります。
npmと互換性があり、同じpackage.jsonが使えます。

現在の開発環境ではyarnを採用していますが、メリットとしてnpmよりインストールなど速度が速いというものがあります。
また、npmと同じのpackage.jsonが使えるため、同一プロジェクトでnpm or yarnで固定しなくて良いという点があります。
※yarnを使用していてわざわざnpmを使わなければならないというケースが想像できませんが、、

yarn自体はnpmでインストールすることができます。

$ sudo npm install -g yarn

ベースとなるタスクランナー、パッケージマネージャの選定がほぼな気がしないでもないですが、フロントエンドの基本的な構成要素HTMLCSSJavaScriptについて紹介します。

HTML

EJSPugをベースとして用意います。どちらかに固定すると宗教戦争が起こるのでクリエイターそれぞれに委ねられます。
非エンジニアが初期構築から行うケースはほぼないですが、EJSであれば中身はHTMLのママでも問題ないのでEJS、Pugの2者選択にしています。

CSS

SCSS記法を使用したSassを使用しています。
Classの命名規則などもOOCSSBEMSMACSSFLOCSSなど様々な設計思想がありますがここも論争が起こるので特に指定はせずクリエイターに委ねられます。
あまりに考えられていない設計をすると盛大なツッコミが入るので要注意です。
基本的にはクリエイター各々に委ねられますがnormalize.cssreset.cssはベースとして組み込んでいます。
個人的にはBEMをベースに設計しています。

JavaScript

スキルセットごとに一番書き方が分かれるところです。 jQueryを使うもの、ES6を使うもの、TypeScriptを使うもの様々です。エンジニアであれば最低限ES6は使おうという取り決めはあります。
各ブラウザの依存関係をなくすのにBabelを用意していますが、IE11の対応が不要となってきた今では必要なくなってきたかも!?
個人的にはTypeScriptParcelでコンパイル、バンドルするようにしています。
以前はwebpackをTypeScriptのコンパイラーとして使用していましたが未圧縮時のコードが読みにくいのもありParcelに乗り換えました。
ts-loaderとか追加のモジュールをインストールしないくても良く設定が単純で高速なところも気に入っています。
Parcelもタスクランナーとして使用できますがTypeScriptのコンパイルのみで使用しています。

Vue.jsの書籍執筆に携わっておいて何ですが、個人的にはReact使いでフレームワーク系の開発する際も大きな設定変更などせずに対応できていてParcel便利です。

parcel_typescript.png

欲を言えばimportしているnode_modulesだけ別でバンドルできたら言うことないんですが。。

その他

他には開発時にローカルサーバー立ち上げるBrowsersync、CSSにベンダープレフィックスつけるAutoprefixer、ファイルの変更を検出するwatch、納品時の画像圧縮系のモジュール、コードの保守性を保つために静的検証ツールのESLint、コードフォーマッターのPrettierなどベースとして組み込んでいます。

まとめ

あくまでベースという形でクリエイターそれぞれに委ねられているMONSTER DIVEのフロントエンド開発環境ですが、それぞれで環境が異なることでの利点もあります。
後からヘルプ等でプロジェクトにアサインされた場合など主担当が設計した環境に倣うことになるので、他の人の良い部分を自分の環境にフィードバックできることと、イマイチだと思ったところは指摘するなどお互いに成長を促せるからです。
社内勉強会などで一方的にレクチャーされるのも良いですが、プロジェクトを通してアップデートする方が何事も成長が早いかと思うので良い風潮だなと思っています。

これからも小さなところからでも一歩ずつ自分もチームも成長していければなと思います。

Recent Entries
MD EVENT REPORT
What's Hot?