社内LTで発表した資料です。 ESLintの仕組みについて、Lintの動き、拡張性、世のコーディング標準に乗っかろう、というお話をしました。 合わせて、若手主催のLTということもありまして、それぞれの技術要素について、発展技術の紹介もしています。

1. ESLintの仕組み
2019-05-29 金谷敦志

2. ESLint - The pluggable linting utility for
JavaScript and JSX
公式サイトおよびGitHubリポジトリ
● JavaScript界におけるLinterのデファクトスタンダード
○ Lintはコードを静的解析してバグやスタイル違反を指摘するツール
○ 昔はJSLint, JSHintがあったが、ESLintに取って代わられた
● 今日は下記3点について
○ ESLintのコードチェック方法
○ Pluggableとは？
○ JavaScriptコーディング規約を変えよう
※使い方の話はないので、Getting Started with ESLintを見てね
2

3. ESLintのコードチェック方法
3

4. ESLintのコードチェック方法
基本的な流れ
※Architectureを読んでからコードを読むと理解が早まる
1. コンフィグの読み込み(詳細は割愛)
2. 抽象構文木を作成
3. ルールベースのチェック
4. レポート出力
4

5. 抽象構文木を作成
5
> var espree = require('espree')
> var res = espree.parse("var name = 'eslint';")
> JSON.stringify(res)
{"type":"Program",
"start":0,
"end":20,
"body":[
{"type":"VariableDeclaration",
"start":0,
"end":20,
"declarations":[
{"type":"VariableDeclarator",
"start":4,
"end":19,
"id":{"type":"Identifier","start":4,"end":8,"name":"name"},
"init":{"type":"Literal","start":11,"end":19,"value":"eslint","raw":"'eslint'"}
}
],
"kind":"var"
}
],
"sourceType":"script"
}

6. ルールベースのチェック
● ESLintが標準で持っているルール(およびソースコード)
● ソースコードから生成された抽象構文木に対してルールを適用する
● 例: space-before-function-paren.js
○ var f = function () {}
■ leftTokenは {"type":"Keyword","start":287,"end":295,"value":"function"}
■ rightTokenは {"type":"Punctuator","start":296,"end":297,"value":"("}
■ 294文字目と296文字目の間にスペースがあることが分かる
○ fix可能なルールで fixオプションがついていれば、その場で直す
6

7. レポート出力
12:8 error Missing JSDoc parameter type for 'response' valid-jsdoc
12:8 error Missing JSDoc parameter description for 'response' valid-jsdoc
15:5 error Expected method shorthand object-shorthand
15:32 error Unexpected space before function parentheses space-before-function-paren
16:9 error Expected line before comment lines-around-comment
17:51 error Expected '===' and instead saw '==' eqeqeq
7
各種形式でレポート出力できる(ソースコード)
下記はデフォルト(stylish.sh)例だが、JUnit形式で出力してCIに食わせることもできる

8. 余談
ESLintのlintingの仕組みを知っておくとプログラミングの可能性が広がる(特に抽象構文木)
● 字句解析
● 構文解析
JavaScriptのminifyの実装ができる
上記に意味解析も加えると、コンパイラの実装ができる
そこまでいかなくても、ドメイン固有言語(特に外部DSL)の設計実装ができるかも
8

9. Pluggableとは？
9

10. Pluggableとは？
あまり知らないので調べてみたが、これも同様にドキュメントがしっかり書かれている
● ルール
● プラグインで下記をまとめ上げたものを提供できる
○ ルール
○ コンフィグ
○ 事前事後作業
● レポートのフォーマッタ
○ グラフ出力は便利
● パーザまでも(espreeが返すノードと同じインターフェースにすればOKらしい)
10

11. プラグインの作り方
"use strict";
// Requirements 必要に応じて利用したいライブラリを書く
var requireIndex = require("requireindex");
// Plugin Definition
// import all rules in lib/rules ここにプラグインが読み込みたいルールを格納しておけばOK
module.exports.rules = requireIndex(__dirname + "/rules");
// import processors (必要に応じてjs以外にも対応できるように。 .jsxや.vueなどが対象？)
module.exports.processors = {
// add your processors here
};
11

12. 余談
プラグインの仕組みを理解しておくとプログラミングの可能性が広がる
● プラグインのインターフェース設計
● プラグインがあるフォルダからのソースの読み込み
● インターフェースに定義のある通りにプラグインを実行
Webアプリケーションフレームワークなどで、上記のことをやっている
12

13. JavaScriptコーディング規約を変えよう
13

14. 当社におけるJavaScriptコーディング規約
当社におけるJavaScriptコーディング規約(公開に当たり社内リンクを消しています)
● コードのフォーマットはESLintで頑張ればできる
● エラー指摘もeslint:recommended を利用すればできる
● でも…これ守ってるチームはあるのだろうか
● 守っていないのであれば、これを守るようなESLintプラグイン開発の意味はあるのか
14

15. ESLintが普及した最大の理由
コーディング規約を公開できる＆ 必要に応じてオーバーライドして使える
有名ドコロ
● Airbnb JavaScript Style Guide (いち早くES2015に対応したことで有名)
● eslint-config-google
● JavaScript Standard Style
● (有名ではないがESLintもESLintでコーディング規約を書いている)
15

16. JavaScript Standard Styleの提案
https://standardjs.com/
● 俺達がスタンダードだと言わんばかりの名前
● 採用している組織が多い
● セミコロン不要！(一番議論を醸す部分)
● 当社におけるJavaScriptコードの傾向を調べていないが、なるべく移行負担の少ない規約を採用したい
● 何にせよ、有名ドコロのコーディング規約を利用して、遵守しやすい状態にしたい
16

17. 余談
セミコロンは必要だろ常識的に考えて。という方向けの、semistandard もあります
● 基本、JavaScript Standard Styleと同じ
● 違いはセミコロン必須なこと！
○ あとセミコロン重複も NG
17

18. まとめ
● ESLintのコードチェック方法
○ 抽象構文木を作る
○ ルールを適用する
○ フォーマットしてレポート出力する
● ESLintの拡張性、再利用性が高い
● 世のコーディング規約にのっかろう(意見募集)
● 学んだ知識を応用しよう
18