以前の日記で、
「時代はESLint。JSLintでもJSHintでもなくESLint。」みたいな記事をみると、ESLint に鞍替えしたほうがいいのかなぁとも思いつつ、既存ルールをそのままお引っ越しする方法が分かっておらず、ひとつひとつ載せ替えるのにも時間がかかってしまうなぁという思いでちょっと停止してしまっていた
とかって書いていて JSHint から ESLint へのお引越しが止まってしまっていたのだけど、また別のタイミングがやってきて「この機会に乗り換えたほうが良いのではないか?」的な気持ちが盛り上がってきたので、再び調べていた。
この移行の話は、オレだけじゃないはずだ!と思って「JSHint ESLint migration」みたいに検索してみたら、そのものズバリの Issue が見つかった。こういうのは ESLint 本家の Issue を見れば良かったのか。
何個かコメントがやりとりされている中の最後の方に紹介されているツールがあった。
つまり、こうやることで、JSHint のルールファイルを ESLint のものにコンバートしてくれるらしい。
% node index ./path/to/.jshintrc > ./.eslintrc
devDependencies のバッヂに out of date とか出ちゃっている(依存している ESLint のバージョンが古い)のだけど、手元で試してみたところ実行そのものは問題なくできた。ルールがどこまで正しくコンバートされたかは、、、JSHint も ESLint もいまいちふわふわした知識しかないので、正直よくわからない。
今まで JSHint で文句を言われないように作ってきた JavaScript のファイルたちに対して、eslint-rules-mapper でコンバートした設定を使った ESLint を実行してみたところ、いくつか文句を言われてしまった。
例えば、JSHint 時代において、ファイル内のコメントを使ったインラインコンフィグで逃げていたもの(ひー)。
/* jshint unused: false */
こいつらに対しては、ESLint 版のインラインコンフィグを使って逃げたり(わー)。
/*eslint no-unused-vars:0 */
他に、JSHint だと指摘されなかったけど ESLint 化したらひっかかったやつには、comma-style があった。これは、つまりカンマの使い方が一部のファイルで違っていたのが原因。
var hoge = 0
, fuga = 1;
var hoge = 0,
fuga = 1;
これは多数派のほうをルールにして、少数派のほうをインラインコンフィグを追記するワザで逃げたよ、いまのところ(あーあ)。
でも、これでだいたい目処がついた気がするので、もうちょい整理したらチームに提案してみようっと。