A Formal Commitment to New Language Features
JSHintのブログに投稿されたA Formal Commitment to New Language Featuresという記事の紹介です。
BabelなどによってES.nextの機能を試せるようになっていますが、
JSHintがそれらの新しすぎる構文をサポートするのが難しい理由について。
理由の一つとしてメンテナンスが難しすぎるという問題があること。
もう一つの大きな理由としては、JSHintは常にコミュニティ駆動型のツールであるため、
エコシステムを破壊するかもしれないまだ不安定なものをファーストクラスとしては採用しない事が挙げられています。
JSHintがJSLintをforkして作られた経緯については、以下に作者のブログで書かれています。
ES.nextを一概に取り入れないという意味ではなく、その機能のプロポーサルがStage 2以上のものは、全く早すぎるというわけではないためexperimentalフラグで取り入れていくとしています。
Note: Stage 2はECMAScriptのプロポーサルの段階を示すもので、
プロポーサルのドラフトができてブラウザがフラグ付きで実験的なサポートをしたりする段階です。
JSHint 3ではこの方針に則り
esnextというオプションは廃止mozオプションについてはそのまま- ES6については
esversion: 6オプションでサポート - ES7についてはちゃんと標準化が完了してからサポート
- Stage 2以上のプロポーサルについては
experimentalオプションでサポート
という形にしていくようです。
JSHintの競合としてESLintやそれを利用してBabelがサポートするStage nのプロポーサルもLintできるbabel-eslintがあります。
ESLintは柔軟なサポートをするためにプラグインシステムを導入していますが、
プラグインにはプラグインなりの難しさがあり今回の件が発端で議論されてます。
@mjackson FWIW (roughly) over 1/3 of ESLint users use babel-eslint. In the future ESLint won't even be required as it'll be rolled into core
— Sebastian McKenzie (@sebmck) July 10, 2015ESLintと役割が微妙に競合でもあるJSCSの@mikesherovさんが言うように、
競合がいることは健全であるため、これからもLintツールにおいても互いの方針によって発展していくのは正しいと思います。
@mikesherov @sebmck having 2 impls is fine. Better than monoculture. It's when 20 show up that sucks. Why I love Acorn AND Esprima.
— Mike Sherov (@mikesherov) July 11, 2015
