Vue.js で単一ファイルコンポーネント機能を用いて *.vue 形式でコンポーネントを記述する場合は、下記のように書くことが出来ます。
<template lang="pug">
.some-template
a(href="/") Top
h1 Hello world!
</template>
<script>
import Vue from 'vue';
export default Vue.extend({
name: 'SomeTemplate',
});
</script>
ここで利用されている pug と呼ばれるものは、以前 jade と呼ばれていた HTML のプリプロセッサ言語です。
上記のテンプレートは、下記のように HTML 展開されます。
<div class="some-template">
<a href="/">Top</a>
<h1>Hello world!</h1>
</div>
HTML を書くのに比べて、上記例では文字数を 約 35 % 少なく 記述することが出来ています。
小さいスケールでコードを書き始める時、出来るだけコードの文字数は減らしてサクサクと書いていきたいものですから、私のプロジェクトでは pug を採用して一気にゴリゴリコンポーネントを増やしていました。
しかし、全体のコード量が増え、メンバーが増え、運用のフェーズに入った時、この書き方には問題があることに気づきました。
pug を捨てた理由
現代的なプログラミングは、 IDE やエディタによる 多大なサポートによって最適化されている ことがメリットとして挙げられます。
しかし、この pug を使うと、 静的解析ツールのサポートを受けられない ことに気づいたのです。
現在 Vue ファイルの lint を行うものといえば、 vue-eslint-parser を利用し、 eslint で行うことがメジャーではないでしょうか。
しかし、 この issue#29 にある通り、現段階(2019/04)で vue-eslint-parser は pug 言語のパースには対応していないため、 eslint で解析を行うことが出来ません。
それはどういうことを意味するかというと、 eslint-plugin-vue で利用可能なたくさんのルール をエラーチェック・自動修正出来ない ということです。
特に Vue のスタイルガイドは非常に優秀で、コンポーネントを書く時に悩ましい部分をあらかた解決してくれる存在です。
eslint-plugin-vue はそのスタイルガイドに基づいて、多くの項目を自動で修正してくれます。
このサポートを受けれないとなると、 <template> 内のコードの信頼性を仕組みで向上することが出来ないつらい状態です。
vscode の強力な Vue 拡張である Vetur も issue#527 のようにフォーマッタが実装されていません。
かろうじて vue-format が自動でフォーマットしてくれるかな、程度です。つらい。
一括して修正する
幸い pug は API を提供しているので、その API を利用すれば簡単に HTML に変換することが可能です。
このあたりのライブラリを使えば、一括で修正が可能です。その後に eslint --fix を実行すれば、ほとんどのエラーは解消出来ると思います。
全てのエラーを自動で解消出来るわけではないので、その後はチマチマ 1 ファイルずつ点検していくことにはなりますが、一度やってしまえば終わりなので許容出来る量のうちにやっておいた方が良いですね。
「記述するコード量が増える」問題に対処する
「記述するコード量が増える」という問題は、例えば vscode ではデフォルトで有効になっている Emmet 記法 を用いることでほぼ解決出来ます。
この Emmet 記法は、 pug っぽく HTML の要素を記述して展開を実行することで、少ないコード量から HTML を生成出来るものです。
#page>div.logo+ul#navigation>li*5>a{Item $}
こう書いて展開を実行すると、
<div id="page">
<div class="logo"></div>
<ul id="navigation">
<li><a href="">Item 1</a></li>
<li><a href="">Item 2</a></li>
<li><a href="">Item 3</a></li>
<li><a href="">Item 4</a></li>
<li><a href="">Item 5</a></li>
</ul>
</div>
このようになります。
記法は pug や jQuery のクエリセレクタに似ているので覚えやすいですね。それに、別にこの記法を用いなくても良いわけなので、デベロッパフレンドリーです。
事前に保守する時のことを考えて、こういった Linter サポートなどがしっかりしているかどうか調べてから技術を利用するようにしましょう(教訓)。