JavaScript用lintツール、JSHintの入門用の記事です。

JSHintとは？

JavaScript用lintツールで歴史の長いツールです。2011年ほどからあります。
JavaScriptコードのエラーや潜在的な問題を検出するのに役立つツールです。

その他にはESLintなどが最近だとトレンドですが、この記事ではJSHintについて触れたいと思います。
JSHintは本記事執筆時点ではECMAScript 6には対応しておりませんので、6以降を使っている方は ESLint の方をお使い下さい。

デモ

オンラインのチェックツール、jshint.comもあり、簡単に試すことが出来ます。
オンライン版で試しに問題の有るコードを書いてみました。

このコードに対して、JSHintは下記のようなエラー・警告を出してくれます。

1. セミコロンがない
2. return のあとにかいてある return は到達不可能(到達不可能な行の内容は問わず指摘されます
3. 使用していない変数がある

今回の例ではシンプルなコードで試しましたが、複雑・長文なコードでもきちんと動作してくれます。

JSHintを自分たちのプロジェクトで使うためには？

普段開発しているプロジェクトでJSHintを導入したいと思った場合、以下の様な方法で導入できます。

1. コマンドラインからのjshintの実行
2. エディタ連携
3. SaaS

コマンドラインからのjshintの実行

以下の様なコマンドでjshintのインストールと実行ができます。

$ npm install jshint
$ jshint path/to/your/javascripts

エディタ連携

Atom, Vim, Emacs などほとんどのエディタでJSHint用のプラグインが配布されています。
お使いのエディタ名とJSHintで検索してみてください。

SaaS

JSHintを実行できるSaaSなどもあります。
有名どころですと、以下の様なSaaSでお使いいただけます。

1. SideCI
2. CodeClimate
3. HoundCI

導入のハードルとおすすめ設定

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と連動し、新しい指摘が見つかった場合には自動的にコメントして問題を伝えてくれます。
無料でお使いになれますのでぜひ。

www.sideci.com