こんにちは、仁木です。
先日、新規サイトのコーディングの担当割り振りをコーダーの河野さんと話している時に「ちょっとPug使ってみない？」という話になり、巷で話題のPugを使ってみました。
ただし、Pugは基本的にはHTMLコードのコンパイラであり、PHPを多用しているアウラではPugの環境をカスタマイズしてあげる必要がありました。
また、Pugは、Gulpなどのタスクランナーやwebpackのビルドツール、CLIなど、様々な環境で実行することが出来てしまうので、その辺りを吟味した過程なども含めて、環境の構築内容やカスタマイズ内容について今回は紹介したいと思います。
Pugをご存知ない方に説明をすると「Pug」はJavascriptで動くHTMLのコンパイラです。コンパイラとは、人間が書いたソースコードをコンピューターが理解できる言葉に翻訳してくれるプログラムです。
もともとコンパイラは人間が読んだり書いたりすることが難しい機械語を、わかりやすい言語でかくための橋渡し役的なものですが、Pugに関してはその役割はなく、「効率的に楽してソースコードを書く」と言う部分にフォーカスされています。
ちなみに以前は「Jade」という名前でしたが、商標の問題で「Pug」に変わったようです。
それでは、Pugを使うことで具体的にどんなことが楽になるのかを簡単に紹介します。
HTMLは普通に書くと以下のような書き方になります。
|
1 2 3 4 5 |
<h1>見出しタグです。</h1> <p>文章が入るタグです。</p> <a href="https://aura-office.co.jp>リンクタグです。</a> |
Pugはこう書きます。
|
1 2 3 4 5 |
h1 見出しタグです。 p 文章が入るタグです。 a(link="https://aura-office.co.jp") リンクタグです。 |
「タグを囲うカッコ（”<>”）」や「閉じタグ」がなく、「要素名 （半角スペース）テキスト」と言う非常にシンプルな書き方になります。
アンカー要素みたいに、属性は「カッコ”()”」の中に書きます。
またIDやクラスはCSSのセレクタと同じ記述で書くことが出来ます。
|
1 2 3 |
h1#headline ID付きの見出しタグです。 p.paragraph クラス名は「paragraph」。 |
純粋なHTMLではソースコードはインクルード出来ません。ヘッダーやフッターなど共通部分はインクルードすることでマークアップの時間を大幅に減らせます。
以下のように「header.pug」を用意します。
|
1 2 3 |
//- header.pug header p ヘッダー |
このheader.pugをpage.pugにインクルードします。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
//- page.pug doctype html(lang="ja") head meta(charset="utf-8") title ページタイトル body .content p コンテンツ include footer |
Pugはインクルードの他にも、「継承」や「Mixin（ミックスイン）」と言った機能もあります。
ソースコードのテンプレートを作って、各ページで使い回すことで効率的にコーディングできるようになっています。
Pugの紹介はここまでにして、ここからは本題のPugのカスタマイズについて掘り下げていきます。
はじめにPugのインストールですが、なるべく現在の環境に変更がない方法で導入したかったため、タスクランナーやビルドツールなどを使用せずに、シンプルにPugの機能のみをインストールできる「pug-cli」を選択しました。
「pug-cli」はNode.jsのパッケージマネージャからインストールします。
ここで気を付けたいのが、コマンドからyarn install -D pug-cliでインストールはできるのですが、npmで取ってくるバージョンに問題があるようで、Pugのコンパイル時にインクルードファイルまで一緒にエクスポートされてしまいます。（通常はされません。）
なので、githubに公開されているリポジトリからパッケージを取得します。
package.jsonに以下を追記してインストールします。
|
1 2 3 |
"devDependencies": { "pug-cli": "https://github.com/pugjs/pug-cli", } |
npm-scriptでコマンドを実行します。今回は以下のコマンドにしました。
|
1 |
pug src/pug -o ./ -b src/pug -w --pretty -E php |
はじめの、src/pug はPugのファイルを格納しているディレクトリを指定します。
次に、-o ./はエクスポートしたファイルの格納ディレクトリの指定です。
-b src/pugは複数のPugファイルをディレクトリの構造を維持したままエクスポートする際に、基準となるディレクトリを指定します。
-wはファイルの変更を監視するオプションで、Pugのファイルが編集されて保存されたタイミングでエクスポートし直してくれます。
--prettyはソースコードを圧縮せずに、インデントや改行を保つオプションです。このオプションを指定しない場合は圧縮されたソースコードがエクスポートされます。
最後の-E phpはエクスポートするファイルの拡張子をphpに指定しています。
Pugは、コンパイルしたファイルは通常HTMLファイルとしてエクスポートされます。ただしPHPを使う場合、拡張子がHTMLだとPHPが実行できないので、拡張子をphpにする必要があります。
Pugを実行する準備ができたら、実際にPugでコードを書いていきますが、PHPのコードを普通に書くとエスケープ処理されてしまうので以下のような書き方で対応します。
|
1 2 3 4 5 6 7 |
//- その1 .box. <?php echo 'hello'; ?> //- その2 .box | <?php echo 'hello'; ?> |
ファイルの冒頭にPHPの処理を書きたい場合など、HTMLタグの外に書く場合
|
1 2 |
. <?php echo 'hello'; ?> |
属性値の場合は「=」の前に「!」を足します。
|
1 |
img(src!="<?php echo $url;?>/img/image01.jpg") |
全体的にどうしても書き方が特殊になり、多少読みづらさは出てきます。
どうしてもPHPタグをそのまま書きたい場合は、Gulpなどタスクランナーを利用して処理を追加してあげると良さそうです。
やはり何と言っても、略記でHTMLコードを書けるのが一番のメリットですね。
その他には、Mixinを使うことでデザインパーツのコードを一箇所で管理できそうな所も魅力です。（今回はそこまで使えずでした。）
ただ、ヘッダーなどのIncludeしたコンテンツを更新すると、全ファイルに影響が出るのでGitなどでデプロイできる環境がなければ、大規模なサイトなどれはFTPでアップするのは厳しそうだな、と感じました。（その点PHPはサーバーサイドでレンダリングするので、Includeファイルのみの更新で済みます。）
あとは、開発環境や本番環境など、サーバーごとにパラメーターを変更する必要がある場合も管理が大変そうだと感じました。（Webpackなどバンドラーを使えば解決するのかもしれません）
規模の大きなサイトで利用する場合は、公開後の更新など、運用方法も見据えて導入を検討した方が良さそうです。
ちなみに上記はPugとPHPのみのシンプルな構成での感想です。開発環境や運用方法によっては問題にならない場合もあると思います。
Pugの導入を考えている人の参考になれば幸いです。
