入る前に、
こんにちは
いよいよ、Nuxt.js関連記事の最終章になります。
今まで、フロント側の開発について、CSR/SSRや、Universal Appについて、その中のNuxt.jsについて、あれこれ見てみました。
最後は、このNuxt.jsを使ってチームレベルで開発する時、よく話が出る、LINTについて調べてみましょう。
そして、どんな感じで使えばいいのかまで自分がの経験をもとに紹介したいです。
Lint?
それではLintは何でしょうかね？
Lintチェックした？ Lintチェック自動に回せる仕組みを入れたいです。
という話、現場で良くしたことあると思います。
（もちろんそんなことは当たり前とか、そんなことに時間使う暇はないよ。などの場合があるかもしれません。）
ここで話してるLintはここを見ると、
コンパイラよりも詳細かつ厳密なチェックを行うプログラムである。静的解析ツールとも呼ばれる。
のように案内してます。 言葉とおりです。
そして、そのLint作業を行ってくれるツールをLinterだといいます。
Goでは、go-lint, golangci-lintなどが有名だし、よく使われてます。
PHPでもphpmd, phpcsなどがあります。
それの、JS版としてよく使うのが、ESLintになります。
そして、そのESLintとペアとして、よく使うのがPrettierというツールです。
これは、ESLintから指摘されてものを自動的に修正をサポートしてくれるツールになります。
インストール
基本的に、ESLint、Prettier両方ともNuxtアプリをインストールする時から入れるのが可能です。
ここで、選択することで、すでに入れられる方法と
Yarn, NPMを使って後からインストールする方法もあります。
ESLint
Prettier
インストールは、公式ドキュメントを参考してください。
使い方
それぞれインストールが終わったら、package.jsonにとあるコマンドが追加される・追加したと思います。
{
...
"lint:js": "eslint --ext \".js,.vue\" --ignore-path .gitignore .",
"lint:prettier": "prettier --check .",
"lint": "yarn lint:js && yarn lint:prettier",
"lintfix": "prettier --write --list-different . && yarn lint:js --fix",
...
}
必ずこのように書かれてる必要はないです。
この中でよく使うのは、lint と lintfix になると思います。軽く説明すると、
lint は、.js, .vueファイルのLintチェックを行う。
lintfix は、 Lintエラーに対してのprettierを使って自動修正を行われる。
という処理です。
設定ファイル
これらを確認するもとになる、設定ファイルがあります。
eslintの場合、eslintrc.js, prettierの場合 .prettierrcになります。
それぞれの公式ドキュメントを見る限り、ファイルの拡張子はjavascript, json, yaml をサポートしてるので、読みやすい、管理しやすいものを選択していれることをおすすめします。
（json形式がよく使われますが、個人的にはコメントアウトが使えるyamlをよく使います。)
eslintの公式ドキュメントでは除外処理についても案内してます。パス、パターン、特定ファイルなどの指定がそれぞれできるので、テストファイルや、特定.js ファイルなどの場外しながら管理するのもありだと思います。
もちろん prettierも除外ができます。 prettierの場合、.prettierignore というファイルで管理してます。
こちらももちろん、特定パス、ファイル、拡張子などが指定できるので参考してください。
細かい設定について、
詳細設定は、公式ドキュメントを読むか、Qiitaなどで検索して必要な部分を追加で入れてください。
特に設定がない場合、ESLintの場合、recommendedというものとして処理します。 これが不便だと思ったら、eslintrcファイルのrule 部分を入れて、不要だと入れてください。
{
"no-cond-assign" : false
}
// 項目名：false ←このように書くことで該当項目をOFFするのができます。
項目によって、On/OFF以外に、Warningというものがあります。
言葉通りにエラーではないが、注意して！ 的なものとして、Lint結果をCLI上に案内します。
そして、項目によってより細かいオプション指定が可能なものもあります。それも少し書き方が異なるので、指定するときには公式ドキュメントをよく確認してみてください。
TIPS
これらは普段開発するときにはあんま気にしてないはずです。
PR作成し、レビュー依頼する時が一番気づく時かな…と思います。ｗ
なので、気付きづらい部分を普段の開発プロセスの中から指摘してくれるようにサポートができます。
Git Pre-Commitというものと、Github Actionsがあると思います。
Actionsは、もう、CI/CDレベルの話になるので、自分的にはPre-Commitをおすすめします。
使い方は、こちらもQiita内で検索するとかなりいい記事が多いのでご参考してください。
ようするに、Commit処理をHookとしてなにかの処理を入れるものです。
もちろんPushをHookとして、なにかするのも可能なので、色々拡張して使ってみてください。
うちのチームでは、Pre-commitを使って、Lint処理を確認します。
なんのなくPre-commitだけをHookにすると、全ファイルが対処になるので、lint-staged というものと一緒に合わせて使います。
こちらは、gitのstaged状態になってる(git add したファイルのみ）が検査対象になります。 もちろんデプロイするときには全体検査をもう一度行います。
まとめ、
今回の記事では本当に軽く書いてみました。
細かい設定の説明や案内まで書くのは無駄だと思ったので、簡単にこのような理由でこんなことを使います、参考してください。ぐらいのレベルで書いてみました。
Lint処理は普段Nuxt.js以外でもよく使うものです。 説明でも書いたとおりに言語ごとサポートしてるものがあるぐらいです。
その分チームレベルの開発でコードの可読性は生産性管理的に、大事なものだと思います。
Pre-commitや、Lint-stagedなどのツールも他のPJでもよく活用できると思います。必要だと思う部分はどんな言語でも似てると思いますので…Nuxt.jsだけじゃなく他の言語のコードベースを運用してるのであればぜひ検討してみてください。
自分は今回のPJを担当しながらいろんな失敗を経験しました。
あるときには失敗で落ち込んでたりしましたが、当時のPJが終了したり、この記事を書きながら過去を考えてみたらまぁまぁいい勉強になったチャレンジだと思います。
いつもやりたいことをやらせてくれるマネジャーさんに感謝の心を込めて記事を完了したいと思います。
Nuxt.jsて何だ？どう使えばいいんだろうと悩みがあったエンジニアさんたちに少しでも約立つ情報が載せられたら嬉しいです。
かなり長い記事、ここまで読んでいただいてありがとうございます。
また新しいSubjectを持って戻ります！