ESLint 設定を Glob ベースでがっつり書き直した - Qiita
Prettier や TypeScript を使うようになって、3年前に構築してぼちぼち保守してきた自分用の共有設定 eslint-config-mysticatea をそのまま使えないことが増えてきました。また、1年ほど前に Glob ベースで設定できるようになっている ので、この際がっつり書き直すことにしました。 ついでに、ESLint 共有設定を作る際のプラクティスのようなものがまとまっていないと感じたので、まとめてみます。改めて整理してみると、本当にバッドノウハウの塊だなぁ...。互換性に縛られずリライトしたいですね...。 新しい共有設定の紹介 新しい設定は @mysticatea/eslint-plugin にあります (eslint-config-mysticatea ではない)。
@typescript-eslint ことはじめ - teppeis blog
追記: 2019/05/01 最近の@typescript-eslint/eslint-plugin, Prettierのアップデートによって、正式にTypeScript 3.4対応されました。一通り普通に動いてる感じ。 これまで自分で使っていて問題になったのがパフォーマンス。ESLint単体やTSLintに比べて、プロジェクトによるだろうけど2倍以上遅い。体感で結構辛い。 Poor performance on some projects · Issue #389 · typescript-eslint/typescript-eslint これはTypeScriptのパーサーを通す部分の構造上の問題が原因なので、簡単には直せなそうな気配。 とりあえず、個人的には型を必要とするルールにそこまでの価値を感じていないので、該当ルールを無効にしてparserOptions > projectを削
TypeScript on ESLint の未来 - Qiita
The future of TypeScript on ESLint:https://t.co/PTCWKWN22s — ESLint (@geteslint) January 18, 2019 ESLint の TypeScript サポートの今後について、公式にアナウンスがありました。 要点をまとめると、 TypeScript チームが TSLint から ESLint に切り替えていくと発表したよ。 ESLint チームと TypeScript チームが協力して開発を進める場として、typescript-eslint プロジェクトを開始したよ。 既存の部品は新しいプロジェクトの org に移動するよ (typescript-eslint-parser は @typescript-eslint/parser になる、等)。 という感じです。 以下は公式アナウンスの翻訳です。 数週間前、
ヤバいESLint/TSLintルール作っちゃったかもしれない
Transcript Ϡό ͍ E S L i n t / T S L i n t ϧ ʔϧ ࡞ ͬ ͪ Ό ͬ ͨ ͔ ͠ Ε ͳ ͍ 2 0 1 8 . 4 . 2 4 R o p p o n g i . j s # 2 P ro f i l e • ϑϩϯτΤϯυΤϯδχΞ at PERSOL • GitHub: boiyaa Twitter: boiyaaaaaa Ͳ Μ ͳ ϧ ʔϧ ͔ return จΛېࢭͯ͠Έͨ eslint-plugin-no-return tslint-no-return ݩʑଞͷؔܕݴޠνοΫͳจ๏Λਅࣅ͔ͨͬͨ ˍؔͷॻ͖ํΛἧ͔͑ͨͬͨతͳಈػɻ // Error function foo(bar) { const baz = bar ** 2; return baz; } // Error const foo = function
ESLint v4.0.0 の変更点まとめ - Qiita
前 v3.19.0 | 次 v4.1.0 We're excited to announce that ESLint v4.0.0 has been released! https://t.co/sLe0kCwfMA — ESLint (@geteslint) 2017年6月12日 ESLint 4.0.0 がリリースされました! 主にはインデント ルールの改定、公開 API のクラス化、コメント関連の API 変更などです。エンドユーザー向けには特にインデント ルールの改定の影響が大きいでしょう。それ以外は見えないところが変わった感じだと思います。 Release note: 4.0.0-alpha.0 Release note: 4.0.0-alpha.1 Release note: 4.0.0-alpha.2 Release note: 4.0.0-beta.0 Release no
ESLint v4.1.0 - Qiita
{ "rules": { //... }, "overrides": [ { "files": ["**/*.spec.js"], "env": { mocha: true } } ] } #7348: 各ルールのfix()関数が複数のfixオブジェクトを返せるようになった 自動修正をサポートする検証ルールを作る場合、fix()関数を実装します。 このとき、fix()関数はfixオブジェクトを1つだけしか返せませんでした。v4.1.0から、複数のfixオブジェクトを返すことができるようになります。 例えば、あるノードを囲むカッコを削除するfix()関数は次のように変化します。 context.report({ node, message: "Unexpected parenthesized expression.", fix(fixer) { const openParen = sourc
ESLint プラグイン紹介: eslint-plugin-eslint-comments - Qiita
eslint-plugin-eslint-comments は、ESLint ディレクティブ コメント (/*eslint-disable*/のようなやつ) を使うときのベストプラクティスをまとめた ESLint の追加ルール集です。 ESLint ディレクティブ コメントを使うときは、意図せず有用な警告が抑制されてしまうことを防ぐため、可能な限り影響範囲が狭いように記述すべきです。 このプラグインのルールは、そのための手助けをしてくれます。 インストール ESLint プラグインですので、npm を利用してインストールします。 ESLint をグローバル (--global) にインストールしている場合は、同じくグローバルへ。ESLint をローカル (--save-dev) にインストールしている場合は、同じくローカルへインストールしてください。
VimでESLintとFlowを使うためにNeomakeからALEに乗り換える - Qiita
はじめに [Vim]SyntasticによるESLintチェックが遅いのでNeomakeに乗り換えた - dackdive's blog ここで書いたように ESLint を Syntastic で実行するのはちょっと重いなというのがあって Neomake という非同期で lint チェックできるプラグインに乗り換えた。 それからしばらくして Flow を触り始めたのだが、 ESLint と Flow を同時に使おうとすると Neomake では色々問題があったので ALE という別のプラグインを使うことになった。 最初にまとめ 以下を満たすのは Neomake では無理で、ALE では可能だった ESLint・Flow のどちらか一方がインストールしたプロジェクトでも問題なく使える 現在編集中のファイルに対してだけチェックをかけることができる 軽い（非同期で実行される） ALE はインス
GitHub - import-js/eslint-plugin-import: ESLint plugin with rules that help validate proper imports.
[Vim]SyntasticによるESLintチェックが遅いのでNeomakeに乗り換えた - dackdive's blog
（2017/01/23追記） この後 Flow を導入しようとしたら色々問題が発生したので、Neomake から ALE に乗り換えた。 （追記ここまで） （2018/04/15追記） 現在、記事を書いた時と設定方法が変わっているようです。 こちらの方が最新の手順をまとめてくださっているので、ご参照ください。 （追記ここまで） Vim の Syntax Checker として有名なのは Syntastic ですね。 最近は JavaScript を書くことが多いので、この Syntastic を使って ESLint のチェックをできるようにしていました。 上の記事に書いてある設定を行ったことで、Vim で常に lint チェックをかけられるようになったのは良かったんですが 1 個だけ不満があって、チェックのたびに操作がブロックされてしまうという問題がありました。 正直こればっかりは我慢する
![[Vim]SyntasticによるESLintチェックが遅いのでNeomakeに乗り換えた - dackdive's blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/873ce4479e450530132222b8556b3750b38c3892/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fd%2Fdackdive%2F20161023%2F20161023121542.gif)
ESLint v3.3.0 - Qiita
前 v3.2.0 | 次 v3.4.0 ESLint v3.3.0 released: https://t.co/F87gDj31Cu — ESLint (@geteslint) 2016年8月12日 ESLint 3.3.0 がリリースされました。 小さな機能追加といくつかのバグ修正が行われています。また、いくつかのルールが非推奨に指定されました。これらの非推奨ルールは将来的 (1年後くらい) に削除されることになります。 質問やバグ報告等ありましたら、お気軽にこちらまでお寄せください。 日本語 Issue 管理リポジトリ 日本語サポート チャット 本家リポジトリ 本家サポート チャット 非推奨になったルール #2716: no-negated-in-lhs in演算子の左辺に NOT 演算子を書く (例: !"a" in b) と警告するルールでした。 今回instanceof演算子に
全力で大きくなるReactのコードをスタイルガイドに沿って見直したら、大変勉強になりました | Wantedly Engineer Blog
Wantedlyでは今年に入って、Reactの導入や、webpackの導入によるビルドプロセスの変更、CoffeeScriptからJavaScriptへの変更など、フロントエンドの開発環境が大幅に変更されました。このあたりの話は高松の記事に詳しく書かれていますが、よりリッチなUIを効率的にチーム開発できるようになり、とてもいい変化でした。 コードの質にばらつきがReact導入時は、一つのチームだけReactの開発を行っていたのですが、複数チームが独立して開発するようになると、同じReactのコードでもチームごとに雰囲気の違うコードが出来上がっていました。 ここは括弧を付けるべきなのか、このインデントは好ましいのか、ここはSyntac Sugerを使ったほうがいいんじゃないかなど、疑問点がある度にチーム間で確認をとるのは大きなコストになるため、どこまで指摘するかはチームのレビュアーに依存して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ESLintとPrettierをどう扱うべきかの考察（2018年12月版） - Qiita
GitHub - buzinas/tslint-eslint-rules: Improve your TSLint with the missing ESLint rules
GitHub - amilajack/eslint-plugin-compat: Check the browser compatibility of your code
GitHub - eslint-community/eslint-plugin-eslint-plugin: An ESLint plugin for linting ESLint plugins
GitHub - eslint-community/eslint-plugin-promise: Enforce best practices for JavaScript promises
GitHub - selaux/eslint-plugin-filenames: Eslint plugin to check filenames.
GitHub - eslint-community/eslint-plugin-security: ESLint rules for Node Security
GitHub - amilajack/eslint-plugin-flowtype-errors: Run Flow as an ESLint plugin
