面倒でついつい端折ってしまいがちな、ブラウザでのAMP HTMLバリデーション。

このブログでも、記事の中でhtmlタグを使うことが少なくありません。
そんなときに、ampの記述をすっかり忘れちゃってることが何度かありました。

そんなミスに気づくのに頼っていたのは、サーチコンソールのAMPエラー。
それでも悪くはないのですが、ちょっと遅すぎな気もします。

できたら公開前に気づきたい。
そんな訳で、AMP HTMLバリデーションを調べ直してみました。

結果としては、バリデーションエラーのチェックを自動化することができました。

ちなみに、AMPの基礎知識。
AMPのバリデーションをするのには、ブラウザのアドレスバー内の表示の末尾に #development=1 を入力。
ブラウザのコンソールに結果を表示してくれます。

これはとても便利ではありますが、地味に面倒な作業でもあるのです。
特に複数ページをチェックする場合には。

公式のサイトに、

「amphtml-validator」

というモジュールが紹介されています。
これでいちいち

#development=1

をつけてバリデーションする必要性から解放されます！

AMP ページを検証する - amp.dev

amphtml-validatorをインストールします。
amphtml-validator - npm

yarn add amphtml-validator

コマンドラインで実行できます。

yarn amphtml-validator dist/index.html

ファイルを指定することで、そのファイルの記述が正しいかを判定してくれます。
問題なければ「PASS」が返ってきます。

しかし、このモジュールだと、ファイルごとにチェックしなきゃ いけません。

これじゃ、ブラウザのバリデーターと刺して手間が変わりません。
特に、いくつかのページをアップデートしたときに、不便。

やはり、ディレクトリ丸ごと、一気にチェックしてしまいたい。

Gulpなら、「ディレクトリごとまとめてチェック」できることがわかりました。
__「gulp-amphtml-validator」__というパッケージを利用します。

yarn add gulp-amphtml-validator

Gulp.jsにもこんな風に記述で使えます。

const gulpAmpValidator = require('gulp-amphtml-validator');
gulp.task('amphtml:validate', () => {
  return gulp.src(['dist/**/*.html', '!dist/sw/*.html'])
    .pipe(gulpAmpValidator.validate())
    .pipe(gulpAmpValidator.format())
    .pipe(gulpAmpValidator.failAfterError());});

直したところはm、srcに書くディレクトリの指定です。
Service workerのディレクトリだけ除外しています。

Gulpを実行します。

gulp amphtml:validate

これでディレクトリごとAMP HTMLをバリデーションできました。

せっかくCiecleCIを使っているので、「generate時に全てのファイルをチェックして、エラーだったらデプロイをしない」というようなフローを実現したいですよね。

まんま circleci/config.yaml にコマンドを書いたら、エラーが出てしまいました。

- run:  name: AMP HTML validation  command: gulp amphtml:validate

CircleCI上でgulpを叩くには、ちょっとした工夫が必要なようです。
CircleCI verison 2でgulpの走らせる処理

もうちょっと楽をしたいので、別の方法を模索。
こちらの方の記事にあるように、npm scriptsがスマートなようです。
CircleCIで静的サイトのS3向け自動デプロイ - Qiita

package.jsonにnpm scriptsを追加します。

"scripts": {
  // 〜 省略  "ampvalid": "gulp amphtml:validate"},

そして、cilecleCIの設定ファイルに記述。

- run:  name: AMP HTML validation  command: yarn run ampvalid

これで、記事の公開前にAMPバリデーションに成功しているかどうかを確認できるようになりました。

今回、全てのファイルをバリデーションしてみたところ、見逃していたところが発見できました。

404.htmlで、「canonicalが必要」というエラーが出ていました。
404だからいいかーと思っていましたが、AMP HTMLで書かれている以上、対応した方が良いのでしょう。
今回、修正しておきました。

致命的ではないとはいえ、想定できなかったエラーを発見できました。
これこそが自動化の強みですね。