Help us understand the problem. What is going on with this article?

ESLint v4.0.0 の変更点まとめ

More than 3 years have passed since last update.

v3.19.0 | 次 v4.1.0

ESLint 4.0.0 がリリースされました!

主にはインデント ルールの改定、公開 API のクラス化、コメント関連の API 変更などです。エンドユーザー向けには特にインデント ルールの改定の影響が大きいでしょう。それ以外は見えないところが変わった感じだと思います。

質問やバグ報告等ありましたら、お気軽にこちらまでお寄せください。


⚠️ 非互換な変更 (ユーザー向け)

#8236, #8239: eslint:recommendedが変更されます

#7618: indent ルールが変更されます

より厳しいインデント チェックが行われるようになります。
例えば、既存では無視されていたコメント行や式の途中の行、閉じカッコの行などがチェックされるようになります。

もしindentルールの振る舞いをもとに戻したい場合、代わりにindent-legacyルールをご利用ください。

{
    "rules": {
        "indent": "off",
        "indent-legacy": ["error", /* your configuration */]
    }
}

#8213: .eslintrcファイルのエラーチェックが強化されます

設定ファイルが無効なプロパティを持つ場合、ESLint がエラーを投げるようになります。
例えば、スペルミスや ESLint 0.x の頃に書いた古い設定が残っていた場合などにエラーになります。

#6759: .eslintignoreファイルの振る舞いが変更されます

.eslintignoreに書かれたパスの解決方法が変わります。
従来はカレント ディレクトリを起点にパスを解決していましたが、4.0.0 からは.eslintignoreファイルの位置を起点に解決されます。

ESLint は通常カレント ディレクトリにある.eslintignoreファイルを利用するので、大半のケースでは違いがありません。ただし、CLIオプションによって別の場所にある.eslintignoreファイルを指定している場合に影響を受けます。

#7693, #7879, #8267: いくつかのルールのデフォルトの振る舞いが変更されます

  • no-multi-spaces ... コードと末尾コメントの間の空白をチェックするようになります。
  • padded-blocks ... Switch 文と Class 定義をチェックするようになります。
  • space-before-function-paren ... Async アロー関数のasyncキーワードと引数カッコの間の空白をチェックするようになります。

#6362: npm scoped packages によるプラグインの指定方法が変更されます

あのときのあれです。

従来の npm scoped packages によるプラグインのルールは、次のように指定していました。

{
    "plugins": [
        "@my-organization/foo"
    ],
    "rules": {
        "foo/some-rule": "error"
    }
}

しかしfoo/some-ruleだと、eslint-plugin-fooのルールなのか@my-organization/fooのルールなのか区別がつかないため、指定方法が変更されます。

{
    "plugins": [
        "@my-organization/foo"
    ],
    "rules": {
        "@my-organization/foo/some-rule": "error"
    }
}

⚠️ 非互換な変更 (プラグイン/独自ルール開発者向け)

#8213: RuleTesterのテストパターン チェックが強化されます

テストパターンが無効なプロパティを持っていた場合にエラーが出力されるようになります。
これにより、テストしていたつもりが実はスペルミスで... というのを検出できるようになります。

#6724: AST nodes からコメントのプロパティが削除されます

各 AST ノードから非標準のleadingComments/trailingCommentsプロパティが削除されます。
代わりにコメント取得の公開 API をご利用ください。

  • node.leadingCommentssourceCode.getCommentsBefore(node)
  • node.trailingCommentssourceCode.getCommentsAfter(node)

また、コメント アタッチメントの処理がespreeからeslintに移動されたため、パーサー プラグインを作る労力が減ります。

#6724: コメント取得 API が Shebang を (正式に) 含むようになります

これまで、実装のバグにより、一部のコメント取得 API は Shebang を1行コメントの1つとして返していました。
4.0.0 から、すべてのコメント取得 API が Shebang を含むようになります。このとき、コメント種別は type: "Shebang" となります。

#8408: コメント取得 API が変更されます

これまで sourceCode.getComments(node) を提供していましたが、これは非推奨になります。
代わりに以下の3種類のメソッドをご利用ください。

  • sourceCode.getCommentsBefore(node)
  • sourceCode.getCommentsAfter(node)
  • sourceCode.getCommentsInside(node)

⚠️ 非互換な変更 (連携ツール開発者向け)

#8295: linter.verify() API のオプションから global プロパティが削除されます

これまで linter.verify() API は、オプションの1つとして global プロパティを受け付けていました (これは globals プロパティの別名です)。
しかし、4.0.0 から global プロパティを認識しなくなります。

#8004: より多くのルールの Lint 結果が endLine/endColumn を持つようになります

Lint 結果のendLine/endColumnプロパティは、主にエディタ連携でエラー箇所に赤線を引くために利用されています。これらプロパティは比較的最近で追加されたもので、(互換性のために) ルールが特別に指定しない限りはundefinedになっていました。

4.0.0 から、ルールが報告した AST ノードの範囲に従ってendLine/endColumnプロパティが生成されるようになります。Programノード、FunctionDeclarationノードなど、広い範囲の AST ノードを報告するルールは修正する必要があるかもしれません。

#8231: 公開 API のいくつかが ES2015 クラスになります

CLIEngine, SourceCode, RuleContext等の API がクラスになります。
そのため、new抜きのコンストラクタ呼び出しがエラーになったり、メソッドがfor-in文などで列挙されなくなったりします。

#7364: Lint 結果が Fixable なエラー・警告の数を持つようになります

Lint 結果が新しいプロパティfixableErrorCountfixableWarningCountを持つようになります。
これらは、報告されたエラー・警告のうち、eslint --fixコマンドで修正できるものの数です。

#8454: linter オブジェクトが非推奨になり、代わりに Linter クラスが追加されます

今まで API としてシングルトンの linter オブジェクトが公開されていましたが、これは非推奨になります。
代わりに Linter コンストラクタが追加されました。

const eslint = require("eslint")

// 従来は linter オブジェクトを使っていた
eslint.linter.defineRule("foo", foo)
eslint.linter.verify(text, config)

// 4.0.0 以降は Linter コンストラクタを使う
const linter = new eslint.Linter()
linter.defineRule("foo", foo)
linter.verify(text, config)

同一プロセス内で複数の CLIEngine を初期化したときに、内部的に linter の状態を共有してしまうのが問題になっていたため、この変更が行われました。

💡 新しいルール

#5614: no-buffer-constructor

Node.js 6 にて非推奨になったBufferコンストラクタを警告するルールです。
代わりにBuffer.allocBuffer.fromをご利用ください。

なお、Buffer.allocBuffer.fromは Node.js 4.5.0 で追加された関数なので、それ以前のバージョンをサポートする場合は Feross の safe-buffer モジュールを利用する必要があります。

/*eslint no-buffer-constructor: error */

//✘ BAD
let a = new Buffer(10)
let b = new Buffer("hello")

//✔ GOOD
let a = Buffer.alloc(10)
let b = Buffer.from("hello")

蛇足ですが、その他の非推奨になっているものを警告したい場合は eslint-plugin-nodenode/no-deprecated-api ルールを利用できます。今回Bufferコンストラクタだけコアルールになったのは、それがセキュリティ Issue で重要だからのようです。

#6073: array-bracket-newline

JSCS Icon JSCS 互換ルールです。

配列リテラルのカッコの内側の改行に関するスタイルを矯正するスタイル・ルールです。

いくつかオプションがあり、中身が複数行の場合に改行を必須としたり、要素数に応じて改行あり・なしを切り替えたりできます。

/*eslint array-bracket-newline: [error, {minItems: 3}] */

//✘ BAD
let a = [1, 2, 3]
let b = [
    1, 2,
]

//✔ GOOD
let a = [
    1, 2, 3,
]
let b = [1, 2]

要素の間の改行は次項 array-element-newline を利用する。

#6075: array-element-newline

JSCS Icon JSCS 互換ルールです。

配列リテラルの各要素間の改行スタイルを矯正するスタイル・ルールです。

いくつかオプションがあり、中身が複数行の場合に改行を必須としたり、要素数に応じて改行あり・なしを切り替えたりできます。

/*eslint array-element-newline: [error, {minItems: 3}] */

//✘ BAD
let a = [1, 2, 3]
let b = [1,
    2]

//✔ GOOD
let a = [1,
    2,
    3]
let b = [1, 2]

カッコと要素の間の改行は前項 array-bracket-newline を利用する。

#7356: padding-line-between-statements

2つの文の間に空白行を置くべきかどうかを指定するスタイル・ルールです。
今まで数種類の "特定の文の前後に空白行を置くべきかを指定するスタイル・ルール" がありましたが、それらは非推奨になり、このルールに一本化されました。

ルールは「空白行の要不要 (never or always) と2種類の文の種別」を1セットにして、そのセットを任意の数だけ設定できます。

例えば「return文の前に空白行が常に必要」にする場合は次のようになります。

/*eslint padding-line-between-statements: [
    "error",
    { blankLine: "always", prev: "*", next: "return" }
] */

//✘ BAD
function foo() {
    bar();
    return;
}

//✔ GOOD
function foo() {
    bar();

    return;
}
function foo() {
    return;
}

例えば「return文の前に空白行が常に必要」かつ「関数定義の前後には空白行が常に必要」にする場合は次のようになります。

/*eslint padding-line-between-statements: [
    "error",
    { blankLine: "always", prev: "*", next: "return" },
    { blankLine: "always", prev: "function", next: "*" },
    { blankLine: "always", prev: "*", next: "function" }
] */

//✘ BAD
function foo() {
    bar();
    return;
}
function foo() {
}

//✔ GOOD
function foo() {
    bar();

    return;
}

function foo() {
}

設定は後優先です。
複数の設定にマッチする場合は、一番最後の設定が有効になります。

例えば「変数宣言の後には空白行が常に必要」だが「変数宣言同士の間には空白行を許可しない」にする場合は次のようになります。

/*eslint padding-line-between-statements: [
    "error",
    { blankLine: "always", prev: ["const", "let", "var"], next: "*" },
    { blankLine: "never", prev: ["const", "let", "var"], next: ["const", "let", "var"] }
] */

//✘ BAD
var a;

var b;
foo()

//✔ GOOD
var a;
var b;

foo()

#7981: switch-colon-spacing

switch文のcase/default句にあるコロン:の前後の空白に関するスタイル・ルールです。
デフォルトでは、コロンの前には空白を許可せず、コロンの後には空白か改行を必要とします。

/*eslint switch-colon-spacing: error */

//✘ BAD
switch (a) {
    case 0 :foo(); break;
    case 1:bar(); break;
    default : baz(); break;
}

//✔ GOOD
switch (a) {
    case 0: foo(); break;
    case 1:
        bar();
        break;
    default:
        baz();
        break;
}

#8169: semi-style

セミコロンを行頭に置くか、行末に置くかを指定するスタイル・ルールです。

/*eslint semi-style: [error, last] */

//✘ BAD
foo()
;[1, 2, 3].forEach(foo)

//✔ GOOD
foo();
[1, 2, 3].forEach(foo)

#8387: for-direction

for文の比較の方向と更新の方向が食い違っていた場合に警告するルールです。

/*eslint for-direction: error */

//✘ BAD
for (let i = 0; i < 10; --i) {
}
for (let i = 10; i >= 0; ++i) {
}

//✔ GOOD
for (let i = 0; i < 10; ++i) {
}
for (let i = 10; i >= 0; --i) {
}

🔧 オプションが追加されたルール

#6488: object-curly-newline consistent

オブジェクト リテラルのカッコの内側の改行に関して、"改行禁止" の警告を抑制するオプションが追加されました。

/*eslint object-curly-newline: [error, {minItems: 2, consistent: true}]*/

//✔ GOOD
let a = {
    foo: 1
}

✒️ eslint --fix をサポートしたルール

#8347: no-confusing-arrow

/*eslint no-confusing-arrow: [error, {allowParens: true}] */

a => 1 ? 2 : 3

// gets fixed to:

a => (1 ? 2 : 3)

#8660: no-debugger

/*eslint no-debugger: error */

foo()
debugger
bar()

// gets fixed to:

foo()

bar()

❌ 非推奨になったルール

#8099: newline-after-vars

padding-line-between-statements ルールで置き換えられました。

#8099: newline-before-return

padding-line-between-statements ルールで置き換えられました。

#8099: lines-around-directive

padding-line-between-statements ルールで置き換えられました。


mysticatea
ESLint のメンテナ。Vue.js の開発チームメンバー。JavaScript 言語仕様書 ECMA-262 や JavaScript 構文解析器 Acorn のコントリビューター。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away