JavaScript用lintツール、JSHintの入門用の記事です。
JSHintとは?
JavaScript用lintツールで歴史の長いツールです。2011年ほどからあります。
JavaScriptコードのエラーや潜在的な問題を検出するのに役立つツールです。
その他にはESLintなどが最近だとトレンドですが、この記事ではJSHintについて触れたいと思います。
JSHintは本記事執筆時点ではECMAScript 6には対応しておりませんので、6以降を使っている方は ESLint の方をお使い下さい。
デモ
オンラインのチェックツール、jshint.comもあり、簡単に試すことが出来ます。
オンライン版で試しに問題の有るコードを書いてみました。
このコードに対して、JSHintは下記のようなエラー・警告を出してくれます。
- セミコロンがない
return
のあとにかいてあるreturn
は到達不可能(到達不可能な行の内容は問わず指摘されます- 使用していない変数がある
今回の例ではシンプルなコードで試しましたが、複雑・長文なコードでもきちんと動作してくれます。
JSHintを自分たちのプロジェクトで使うためには?
普段開発しているプロジェクトでJSHintを導入したいと思った場合、以下の様な方法で導入できます。
- コマンドラインからのjshintの実行
- エディタ連携
- SaaS
コマンドラインからのjshintの実行
以下の様なコマンドでjshintのインストールと実行ができます。
$ npm install jshint $ jshint path/to/your/javascripts
エディタ連携
Atom, Vim, Emacs などほとんどのエディタでJSHint用のプラグインが配布されています。
お使いのエディタ名とJSHintで検索してみてください。
SaaS
JSHintを実行できるSaaSなどもあります。
有名どころですと、以下の様なSaaSでお使いいただけます。
導入のハードルとおすすめ設定
JSHintをシンプルに導入、実行してみると、おそらく多くのプロジェクトで誤検知が多く出ると思います。
たとえば、下記のような内容が表示されます。
Missing semicolon; '$' is not defined. 'Prism' is not defined. ['foo'] is better written in dot notation.
一般的なウェブ系のプロジェクトに含まれるJavaScriptファイル全体にJSHintの検査をかけた場合、1000件以上の指摘が行われることも少なくありません。
まずはファーストステップとして、最低限、設定を変えたほうが良さそうなところをご紹介致します。
.jshintignore
まずは使用しているライブラリなどについては検査から除外するのが良いと思います。
JSHintでは .jshintignore
というファイルを作成、プロジェクトのトップに配置することで、それらのファイルを除外することが出来ます。
たとえば、ライブラリをpublic/js
以下に配置し、自作のJavaScriptをapp/assets/javascripts
に配置している場合には、public/js/**/*.js
のように書きます。
また、app/assets/javascripts
配下に.min.js
といった拡張子でライブラリを配置している場合には、app/assets/javascripts/**/*.min.js
などを指定することで除外出来ます。
public/js/**/*.js app/assets/javascripts/**/*.min.js
上記のような .jshintignore
ファイルをまずは作成してみると良いかと思います。
ファイルパスなどはお使いのフレームワークなど、プロジェクトの状況によってご変更下さい。
ライブラリ関連のファイルが全てミニマイズされている環境であれば **/*.min.js
を記述するだけでも良いかもしれません。
.jshintrc
.jshintignoreの次はjshintの設定を行う.jshintrc
を作成します。
JSHint Options に記載のある内容が設定出来ます。
今回はウェブ系のプロジェクトを想定して、代表的なものを設定してみます。
Environments
Environments系のオプションを正しく設定して下さい。JQueryを使っている場合には"jquery": true
を記載する、などです。
例えば以下のように記載した.jshintrc
を作成してみて下さい。
{ // Environments "jquery": true, "browser": true, }
'$' is not defined.
といった誤検知が行われなくなります。
Relaxes
実務上問題のないコードに対してもあまりに厳しくし過ぎると使い勝手が悪いかと思います。
SideCIの開発チームでは以下の3つのオプションについてはチェックしないようにしています。
{ // Relaxes "asi": true, "sub": true, "eqnull": true, }
asi
はセミコロンなしを許可するものです。これをtrue
に設定するとMissing semicolon.
が出力されなくなります。
sub
は['foo']
を .foo
に置き換えましょうといった指摘を出なくするものです。この書き方はほぼ問題がなく、次のJSHintのメジャーリリースでsub
は廃止されることも予定されています。
eqnull
は == null
といったnullチェックを許可するものです。また、このオプションはUse '===' to compare with '0'.
のようなnull以外の比較との指摘は抑制しません。
Globals
グローバル変数などを記載します。先のEnvironments
と似ている機能です。Environmentsのオプションとして指定出来ないグローバル変数などを指定します。
たとえば、Prism
というライブラリを使っており、Prism
というグローバル変数を使用している場合には、下記のように記載します。
{ "globals": { "Prism": true } }
その他
JSHintでデフォルトで有効になっていないオプションの中からプロジェクトに有益なものを選択して有効化するのも良いかもしれません。
たとえば、定義したが使用してされていない変数をチェックしたい場合にはunused
を有効化します。
定義されていない変数などをチェックするundef
を有効にするとタイプミスなどを見つけやすくなります。
(ただし、先のGlobals
などでグローバル変数をもれなく定義しておく必要があります。
まとめ
JSHintはミスや潜在的なバグなどを簡単に見つけてくれるツールです。
若干の設定は必要ですが、最低限この記事で紹介した内容などを設定して頂ければ誤検知は少なくなるかと思います。
本記事で作成した.jshintrc
と.jshintignore
を下記に記載しますので、コピー、ファイルをご作成下さい。
.jshintrc
{ // Relaxes "asi": true, "sub": true, "eqnull": true, // Environments "jquery": true, "browser": true, // Specific to the SideCI "globals": { "Prism": true } }
.jshintignore
public/js/**/*.js app/assets/javascripts/**/*.min.js
また、これらを手軽に試したい場合や、継続的にチームで運用していきたい場合、SaaSのSideCIをご検討下さい。
サイト上で手軽に試せるだけでなく、GitHub PullRequestと連動し、新しい指摘が見つかった場合には自動的にコメントして問題を伝えてくれます。
無料でお使いになれますのでぜひ。