lintとは

lint、あるいはlinterという言葉をご存知でしょうか？ lintとはC言語において、コンパイラではチェックされない、バグの要因となりそうなソースコードの記述に対し、警告を行う静的解析処理のことを指します。lintを直訳すると「糸くず」という意味で、乾燥機の糸くずを取り除くさまをプログラミング用語として流用したものだそうです。

lintによる解析処理を行うlinterは、JavaScriptにおいてもいくつか存在します。本連載のメインで紹介するESLintも、それらlinterのうちのひとつです。

ご存知のとおり、JavaScriptは事前にコンパイルを必要としないインタープリタ型の言語です。ゆえにプログラムの実行前にバグの要因を指摘してくれるlinterの活用は、大規模・複雑化する昨今のフロントエンドの開発において、品質管理上の効果が期待できます。

同じような理由で、事前にトランスコンパイルすることで保守性・品質の向上が望めるTypeScriptやFlowのような静的型付き言語の需要が高まりつつありますが、これらで行われる型チェック処理も、型チェックリンターによる強力なリンティング処理といえるでしょう。

コードスタイルを整える

linterはコードが読みやすくなるよう、整えるという役割もあります。このテーマで行った座談会記事も参考にしてください。

• コードスタイル座談会｜今だからこそ必要なルール

lint周辺ツールの概要と現状

ESLintをはじめとしたlint系のツール、あるい類似する部分をサポートするツールとして、EasyConfig、JSLint、JSHint、TSLint、JSCS、Prettier……といった名前を聞いたことはないでしょうか？ 名前が似たものも多いので、これからこれらのツールを取り入れてみようと考えている方にとっては、どれをどのような組み合わせて使えばよいのか迷うところかもしれません。

これらのツールは、最近ではあまり利用されなくなったもの、他のプロダクトへの統合がすすめられてるもの、急激に利用されるようになったもの、利用言語によって使い分けが必要なものと、状況はさまざまです。

また、開発環境の自由度やコーディング上の制約などは、企業文化やプロジェクトの都合によって異なるものですが、これらツールの採用の前提として大きく関わる部分でしょう。

まずは一旦、各種ツールの概要と現状について把握すべく、簡単におさらいしておきましょう。

EditorConfig

EditorConfig*は、エディタやIDEにおける各種設定項目を、.editorconfigという設定ファイルで管理可能にする規格化された拡張機能です。インデント数や文字コード、行末の空白文字を除去するか否かなど、コーディングスタイルに関わる項目の設定が可能になっています。

*注：EditorConfig

EditorConfigについては、次の記事も参考にしてください。

• チーム開発に効く環境構築術｜EditorConfigのススメ

設定ファイルを配置したディレクトリ以下に存在するファイルに対し、設定内容が適用される仕組みになっています。そのため、複数人で開発を進める場合、プロジェクトのルートディレクトリに配置することで、統一されたエディタ設定で作業を進めることが可能になります。

前提として、利用するエディタがEditorConfigに対応している必要がありますが、プログラミングに利用されるメジャーなエディタであれば、ほぼ対応しています。利用エディタに制約のない複数人体制による開発を行う場合は、積極的に利用するとよいでしょう。

JSLint、JSHint、ESLint

JavaScript向けのよく知られているlinterとしては、JSLint、JSHint、ESLintの3つが挙げられます。

このシリーズで紹介するESLintは、2013年6月にニコラス C. ザカス氏により作られたオープンソースプロジェクトです。次のようなOSSのほか、多数の採用事例があります。

• React
• Redux
• Vue
• webpack
• Jest
• TestCafe

GitHubのスター数（ESLint：9,980、JSHint：7,677、JSLint：3,089）、Googleトレンドを見ても、2018年1月現在のlinterのデファクトスタンダードは、ESlintであるといってよい状況です。これらの現状を踏まえると、JavaScript向けのlinterとしては、ESLintを採用しておけば間違いなさそうです。

2013年1月から2018年1月現在までの様子です。

ESLintの詳細な解説は次回以降の連載で紹介するとして、これらlinterの変遷についても簡単に触れておきます。

ESLintが普及する以前は、JSONを世に広めたことで知られるダグラス・クロックフォード氏により開発されたJSLintが利用されていました。JSLintはコーディング制約が厳しすぎることで有名で、設定変更の柔軟性が低いこともあり、JSLintをフォークして作られたJSHintが利用されるようになっていきます。

JSLintからJSHint をフォークした理由

当初は開発者コミュニティから支持されていたJSLintでしたが、lintのルールが、ダグラス氏流のコーディングスタイルを強要する挙動になるに伴い、ダグラス氏とコミュニティの間に確執が生まれるようになったようです。そのような背景も、開発者駆動としての新たなツールであるJSHintを開発する動機となったことが、JSHintの開発者であるアントン・コワリョフ氏のブログに書かれています。

Why I forked JSLint to JSHint – Medium

JSHintではデフォルトのコーディング制約はかなり緩くなり、設定ファイルベースでコーディング制約の調整が可能になりましたが、ESLintではさらに柔軟に「開発者自身による独自のリンティングルールの作成」と「プラガブルな適用」が可能になります。また、エディタと連携したコードフォーマッターとしての機能、ES2015、ES2017、JSXの対応等の優位性もあり、現在もっとも利用されるlinterになるに至ります。

JSCS

JSCS*は、JavaScript Code Style checkerの略で、ESLintとほぼ同時期に開発されたコードスタイルをチェックすることに特化したツールです。チェックにひっかかった箇所を強制的に修正するコードフォーマッタとしての機能もあり、ESLintと機能が被る部分があります。

*注：JSCS

JSCSについては、下記の記事も参考にしてください。全4回の記事になっています。

• チーム開発に効く環境構築術｜JSCS 1

2016年4月には、JSCSはv3.0でメジャーバージョンアップを終了し、JSCSの開発チームがESLintの開発チームに合流することがアナウンスされました。

• JSCS — end of the line – Oleg Gaidarenko – Medium
• Welcoming JSCS To ESLint - ESLint - Pluggable JavaScript linter

現在は、JSCSで利用できたルールを段階的にESLintでも利用できるよう作業が進められている状況です。JSCSからESLintへの移行を考えてる場合は、次のページで移行手順が紹介されているので参考にしてみてください。

• Migrating from JSCS - ESLint - Pluggable JavaScript linter

Prettier

Prettierは、元MozillaのDevToolチームに所属していたジェームス・ロング氏により開発されたコードフォーマッターに特化したツールです。対応言語が、JavaScript、Flow、TypeScript、CSS、SCSS、Less、JSX、Vue、GraphQL、JSON、Markdownと幅広いことも大きな特徴です。

2017年1月のアナウンス以降、同年3月に開催されたReact Confで注目され、わずか1年たらずでGitHubのスター数が20,000近く付いている人気のOSSです。2018年1月時点でのESLintのスター数が約10,000ですので、その人気のほどが伺えます。

• A Prettier JavaScript Formatter

コードフォーマッタという点では、ESLintやJSCSの機能と被ることになりますが、行単位に設定された最大文字数に対し、適切な改行処理を行い、可読性の高いコード整形を行うという点が最大の特徴となっています（ESLintでは最大文字数を超えたという警告しかできません）。

また、ESLintとは対称的に、設定可能な項目数が極端に少なく非常に強制度が高い整形処理を行います。採用に際しては、それまで持っていたコードスタイルに対する細かなこだわりを捨てることを要求されますが、それゆえに開発者間でコードスタイルの定義に迷う余地がなく、共通のスタイルで統一されたソースコードが維持されるというメリットを享受することができます。

本連載では、Prettierについても、ESlintとの連携を含めて別途解説する予定です。

TSLint

TSLintはTypeScript専用のlinterです。TypeScriptを推奨言語としているAngularでも採用されていることもあり、ご存知の方も多いのではないでしょうか。

ESLintがES2015やJSXをサポートしてる点を踏まえると、linterの学習コストを抑えるという意味でも、ESLintによるTypeScriptのサポートもほしいところです。

完全互換ではないという前提が付きますが、TypeScriptのlintを可能にするtypescript-eslint-parserというESLintプラグインが存在します。「完全互換ではない」ということの特に大きな問題として、利用する構文によっては、次のルールが正常に機能しないという点が挙げられます（詳細についてはIssue #77を参照ください）。

• no-undef: 未定義変数の参照によるエラー
• no-unused-vars: 未使用変数の定義によるエラー

筆者としては実際に利用してみて「実用には厳しい」という感想を持ちましたが、前述ルールの無効化を許容できるのであれば、このプラグインをベースとしたESLintの採用を検討してみるのもよいでしょう。

一方で、TSLint側でESLintのルールを利用可能にするtslint-eslint-rulesというTSLintプラグインも存在します。すべてのESLintのルールがサポートされてるわけではありませんが、ESLintによる設定データの資産をなるべく流用したいといったケースでは、試してみる価値はありそうです。

まとめ

今回は、各種ツールの概要と現状について紹介しました。これらの内容を踏まえると、現状では次のようなツールの組み合わせで開発環境を整えるのがよいではないかと筆者は考えます。

• JavaScript、ES2015をベースとした開発を行う場合
  • EditorConfig + ESLint + Prettier
• TypeScriptをベースとした開発を行う場合
  • EditorConfig + TSLint + Prettier

ESLintのTypeScriptへの互換についてはおしいところですが、ESlintは、Flow、Vue.js、Reactを始め各種ライブラリに幅広く対応しています。また、Prettierの自動整形処理も、レビュー作業を伴うチーム開発においては、生産性の観点からも非常に強力な機能であるといえます。まだ利用されてないようでしたら、一度、試すことをお勧めします。

次回からは、ESLintの具体的な使い方を解説していきます。