ESLint

[azu]

ESLintのアーキテクチャ

URL: http://eslint.org/

どう書ける?

consoleが残ってないかを検出するno-console.js

module.exports = function(context) {
    return {
        "MemberExpression": function(node) {
            if (node.object.name === "console") {
                context.report(node, "Unexpected console statement.");
            }
        }
    };
};

どういう仕組み?

• 最初にルールが使ってるAST Node毎にon(nodeType)をしておいて、
• ASTをtraverseしながらそれぞれのNodeをemitしていく
  • 上の例だとon("MemberExpression")する
• https://github.com/eslint/eslint/blob/f07f601074e6b2f9c51f2af03bd5f73055263c35/lib/eslint.js#L803-L828
• 走査が1回のみで済んで、かつルール側もNodeの指定でenterとexitで捉えれば、コンテキスト(ネスト)も把握出来る仕組み

  どういう事に向いてる?

• ルールが独立したものになるのでルール間で依存がない
• Plugabbleなルールを追加して管理するタイプ

  どういう事に向いていない?

• それぞれのプラグインが順序的な依存があるもの
• 例えばプラグインがソースに対して書き換えのような破壊的な変更を含む場合、それぞれのプラグインが変更した内容をマージする仕組みが必要になってしまう。

  この仕組みを使ってるもの

• textlint

  チェックリスト

• [x] どう書ける?
• [x] どういう仕組み?
• [x] どういう用途に向いている?
• [x] どういう用途に向いていない?
• [x] この仕組みを使ってるもの
• [x] 実装してみよう
• [x] エコシステム
• [x] まとめ

[azu]

Architecture - ESLint - Pluggable JavaScript linter

[azu]

いわゆるpub/subなパターンといえる

[azu]

https://github.com/eslint/eslint/issues/3134#issuecomment-135840617

やっぱりwriteするには吸収層が必要。 このアーキテクチャー的にプラグインは基本的writeは難しいので、擬似的にwriteする仕組みは必要。

[azu]

ひとまず書けたので close #21 細かいところは別Issueで直そう