前 - | 次 v2.1.0 The thing I'm most excited about in ESLint v2.0.0 is code path analysis: https://t.co/H9eqTpc0hF Amazing work by @mysticatea — Nicholas C. Zakas (@slicknet) 2015, 12月 12 ESLint v2.0.0 の変更点をまとめました。 前半に利用者向けの変更内容を、後半にプラグイン開発者向けの変更内容を記載しています。 単純なバグ修正は記載していません。 一覧したい場合は、右列のTOCをご利用ください。 公式情報: リリースノート 1.10.3 から 2.0.0 へのマイグレーション ガイド ピックアップ - 利用者に影響が大きそうな Breaking Changes: 削除された既存ルールのリスト ES
Prettier 2.7 がリリースされました。 このバージョンには TypeScript 4.7 の対応のほかに、新しい CLI オプションである --cache と --cache-strategy が含まれています。 --cache と --cache-strategy を実装したのは自分なので、その背景や実装、そして使い方の話を雑にしようと思います。 背景 Rome Formatter のブログが公開されて日本の開発者からもそれなりに大きな反響がありました。 私個人としてはコードフォーマッターにそこまでの速さを求めていないのであんまり興味はなかった(もちろん速いほうがいいけど)のですが、みなさん意外と興味あるんだなあという気持ちで眺めていました。 それからしばらくして Prettier の https://github.com/prettier/prettier/issues/58
こんにちは、よしこです。 この記事では、わたしの所属する株式会社ナレッジワークで最近コードベースに取り入れた「エラーハンドリング漏れ防止の仕組み」について紹介します。 背景 「通信を伴うアクションに失敗しても画面にエラーフィードバックが表示されない」という実装漏れをしてしまったことがあり、今後こういうことが起きないように仕組みで防止したいと思いました。 「忘れてしまった」という問題なので、テストで担保するのも難しいように思いました。実装するのを忘れてしまっているということは、テストを書くこともセットで忘れてしまっているはずだからです。 「気をつける」「チェックリストを作る」のような人間が注意する方向ではなく、「嫌でも気付く」「忘れていたらCIが通らない」のように、必要なハンドリングを強制する形にできないか？と思いました。 課題 実行時に通信エラーが起きる可能性があり、ユーザーフィードバック
@cybozu/eslint-configから学ぶ、全社共通ESLint configの運用
The lightning talk for フロントエンドカンファレンス福岡スピンオフ テーマ: ESLint https://fec-fukuoka.connpass.com/event/201334/
2017年版と2018年版でwebアプリケーション作成時のreactの（マイ）ベストプラクティクスを以下のリポジトリに、まとめてみたので記事にしてみました。 react-best-practices https://github.com/wheatandcat/react-best-practices/tree/master ちなみにタイトルは、その過程で2018年版に削除したpackageです（理由は後述） github サンプルコードの内容は、ログイン/ログアウト + fetchした内容を画面に表示するだけです （ただのサンプルなので、実装はハリボテです） 2017年版 https://github.com/wheatandcat/react-best-practices/tree/master/2017years 2018年版 https://github.com/wheatandc
上記をグループ化したGroup Selectorsも定義されています。詳しくはこちら 関数の引数にcamelCaseを強制する .eslintrc.jsonの設定は、下記の通り { "@typescript-eslint/naming-convention": [ "error", { "selector": "parameter", "format": ["camelCase"] }, ] } 下記の画像の通り、エラーが検出されています。エラーの内容から、camelCaseする必要があることが分かるので、そのまま修正可能です。 具体例を見ていく 上記はシンプルな例でしたが、他にもより柔軟な名付け規則を適用可能です。 これから説明する例は、typescript-eslint/typescript-eslintのExamplesを参考にしています。 boolean型の変数名に特定のprefi
ESLintのルールを自作しよう！
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 12月から福岡勤務の穴井（@pirosikick）です。 私が所属しているリッチラボ株式会社（以下、リッチラボ）では、スマートフォン向けのリッチ広告の企画・開発と、ヤフー・ソニーと協業のクラウドファンディングサイト「First Flight」の開発・運用を行っています。 今回は、リッチ広告の開発で利用しているESLintのルールを自作する方法について書きたいと思います。 サンプルの動作環境について 本記事に登場するサンプルは、下記の環境で実行しましたので、適宜ご自身の環境に置き換えてご覧ください。 Mac OS Node.js 4系（4.2.1） npm 3.3.9 サンプルのJavaScriptは一部ES6で書いておりますので、
JSLint から JSHint をフォークした理由 ― アントン・コヴァリャノフ | 黒くないすべてのものはカラスではない
数日来 JSHint について調べていたところ、JSHint の開発者アントン・コヴァリャノフ氏による記事を見つけました。なぜ JSLint からフォークして JSHint を作ろうと思い立ったのか、リリース時における作者自身の述懐です。 元サイト：Why I forked JSLint to JSHint 大変興味深い記事でしたので、著者の承諾を得て翻訳いたします。なお、JSHint の本家サイトはこちら、JSHint がバージョン 2.0.0 にアップデートされた記事（2013/05/10）はこちらです。 Anton Kovalyov 私が JSLint から JSHint をフォークした理由 20 Feb 2011 — Berkeley 君たちが苦しんでくれるほど、私の満足度は深まる —ダグラス・クロックフォード. この金曜日、我々は JSHint を発表した。JavaScript
Ubie における ESLint 活用
Ubie では JavaScript や TypeScript で開発されているプロジェクトに対して、静的解析のために ESLint を導入しています。 この記事では Ubie での ESLint を活用事例を紹介します ESLint を活用する目的 まず私が ESLint を活用する目的は、コーディング規約やベストプラクティスを強制することで、コードレビューの手間を省き、結果として本番環境でのエラーやパフォーマンスの悪化を減らすことです。 この記事で紹介するいくつかの設定もその目的を達成するためのものです。 no-restricted-syntax でアンチパターンを禁止する ESLint には no-restricted-syntax というルールがあります。 このルールはセレクタで指定した構文を禁止できます。簡単に言えば、簡易的に独自ルールを作成できます。 たとえば次のように設定する
最近周りでよく「AirbnbのJavaScriptスタイルガイド」が良いという話を聞くようになりました。ということで、自分もAtomに導入してみたんですが、これがなかなかいい感じです。多くの開発者の意見を取り入れられて作られているスタイルガイドで、特にReactやES6の構文チェックなどにも対応しているので、とても良い書き方の勉強になっています。けっこうお勧めだと思ったので、今回はAtom限定の話となりますが、ESLintを使った導入方法を紹介したいと思います。 ESLintとはESLintは、2013年6月にNicholas C. Zakas氏によってオープンソースプロジェクトとして公開されたJavaScriptの構文チェックツールです。個別にルールをon/offできたり、独自のカスタムルールを設定できたり、公開されている様々なプラグインを組み込んで使うことができたりします。 ESLin
typescript-eslint v6 リリース！ 2023/07/10 に typescript-eslint の v6 がリリースされました。 メジャーバージョンアップということで多くの BreakingChange があるのですが、その中でもReworked Configuration Namesと呼ばれる変更は利用者に大きな影響を与えそうです。 Reworked Configuration Namesはざっくり言うと「config に書くrecommendedのようなルールセットの名前や枠組みが変わるよ」という変更です。 ルールセットの名前だけでなく、含まれるルールや分類自体に変更があるので、設定ファイルを v5 のままアップデートしてしまうと意図したルールセットと異なる設定になってしまいます。 ここでは上記の記事にある変更点を紹介しつつ、なるべく既存の設定のままアップデートする
はじめに Next.jsなどReactのプロジェクトにはlinterとformatterが必須でeslintとpretteirを使うと思います。 しかし、導入するとなると考慮すべき点や面倒な点が結構あります。 以下は一例です。 eslintとprettierは設定が複数あり、プラグインのインストールが必要 eslint-plugin-prettierを使えば、pretteirがなくてもformatterは実現できるため、そもそもprettierいるのか問題 逆にeslintはlinterとしての役割のみにして、formatterの機能は持たせたくない そこででてくるのがBiomeです。 Biomeとは 一言でいうとeslintとprettierを一つにしたものです。 以下、公式の引用とページです。 Biome はWebプロジェクトのための高性能なツールチェーンであり、プロジェクトの健全性を
これまで「グローバルのisNaN()ではなくNumber.isNaN()を使え！」を教義に生きてきたのですが、揺らいできました。 JavaScriptのisNaN()は引数を数値に変換した結果がNaNであるかを判定します。 一方のNumber.isNaN()はES6で提供された関数で、引数がNaN以外の時はtrueを返しません。 console.log(isNaN('hello')); // true console.log(Number.isNaN('hello')); // false Number.isNaN()はより厳密な比較であり、キャストを行わないため余計な混乱を避けられるものとして提供されました。 文字列などを渡した場合はtrueを返さないため、Number.isNaN()に渡す時点であらかじめ数値に変換しておくなど型を意識した操作がアプリケーション側の責務として求められるよ
// A: そのまま残る import { Foo } from "./foo"; // B: 識別子 `Foo` が削除される import {} from "./foo"; // C: import 文ごと完全に削除される どれになるかは、以下の状態の組み合わせ依存する（他にも条件あるかも）。 そのファイルでFooが値として参照されるか、型として参照されるか、参照されないか Fooがfoo.tsで値として定義されているか、型として定義されているか tsconfig のオプション設定 importsNotUsedAsValues: 値として参照されない import 文を残すかどうか preserveValueImports: 参照されない import 識別子が値なら残す isolatedModules: ファイル単位でトランスパイルする 上記は出力するモジュール形式が ESM の場合
kintoneのアクセシビリティ改善とESLintルールの整備 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。Poca11y（ポカリ）チームのSUGI(@blindsoup2p1)と小林(@sukoyakarizumu)です。 わたしたちPoca11yチームは「kintone」のアクセシビリティ改善活動に参加しています。この記事ではkintoneのアクセシビリティを改善するチーム体制について解説します。さらにPoca11yチームとkintone開発チームが協力して整備したアクセシビリティを強化するためのESLintルールについても解説します。 Poca11y（アクセシビリティ）チームとkintoneのアクセシビリティ改善 Poca11yチームとは Poca11yチームはサイボウズ全体の「アクセシビリティ」向上を目的としたチームです。Poca11yチームでは主に以下3種類の活動を行なっています。 社内啓発：アクセシビリティの社内研修・勉強会・ガイドライン作成などを行います。 製品改善：サ
はじめに 仕事でチームメンバーみんなでTypeScriptを書いているのだが、たまにmarkdownの中のJavaScriptをいじることがある。 ある日、ある数字aが3より小さく1より大きいという条件を書く必要があった。 そのときに書いたコードがこれ if (3 > a > 1) { // 省略 } プログラミングをやっていると、こういうときは 論理演算子で2つの式を結合して3 > a && a > 1 と書くように手癖がつくものだが、小学生のときから習ってきた数学的な記法はふとしたときに顔を出す。 特に、現代のエディターによる便利な補完に慣れきってしまっている状態で一切の補完が効かない状態で油断してJSを書くと上記のようなコードが爆誕する。 今回はこれのお話。 3 > a > 1の返り値 ところで、3 > a > 1の式、実はJSのSyntaxErrorにならないのを知っていただろうか
eslint-plugin-vue で来たる Vue.js 3 のリリースに備えよう - BASEプロダクトチームブログ
フロントエンドチームの右京です。 Vue.js 3 が八月上旬にリリース予定ということで、BASE でもバージョンアップに向けて少しづつアクションを始めています。 Vue.js 3 では多くの機能が追加され開発の幅が広がりますが、一方で削除や非推奨となる機能も多く頭を悩まされている方もいるのではないでしょうか、BASE もそうです。 この記事では ESLint とその Vue.js 向けプラグインの eslint-plugin-vue を利用した、deprecated となる機能へのアプローチを紹介します。 なぜ eslint-plugin-vue か ESLint には Vue.js の SFC のためのプラグインとして eslint-plugin-vue が開発されていて、BASE でもこれを利用しています。 このプラグインには vue/no-deprecated- で始まるルールがい
大規模アプリのVue3アップデート対応知見まとめ
はじめに 今参加させてもらっている案件でついにVue3へのアップデートが完了したので、知見をまとめていきます！ 僕1人だけではなく、チームでやったので多少曖昧なところもありますが、そこはご愛嬌でお願いします。 マジで一年くらいかかりました。笑 ちなみにこれを全てやれば完璧にVue3対応出来るわけではなく、あくまでこのプロジェクトで躓いた知見を書いているだけでですので、実際に上げる場合はしっかりと公式ドキュメントを確認してください。 特に移行ビルド系は執筆時点で確認していたら、かなりリリースされていたので是非確認してみてください。 前提 新規機能の開発は止めない Options APIからComposition APIへの書き換えなどはしない 特にいつまでにアップデートなどの期限は設けない マイグレーションビルドは使わない webpackerをつかっている TypeScriptは使っていない
JSのプラグインシステムについて書くJavaScript Plugin Architecture 2.0をリリースしました JavaScriptのプラグインシステムについて書いた小さな電子書籍であるJavaScript Plugin Architecture 2.0をリリースしました。 1.0(初版)公開時の記事は次のページから参照できます。 JavaScript Plugin Architectureというプラグイン設計について学ぶ無料の電子書籍を書いた | Web Scratch 2.0の詳しい変更点についてはリリースノートを参照してください。 Release v2.0.0 · azu/JavaScript-Plugin-Architecture 2.0リリース時にGitBookからHonKitに移行しました。 そのため、公開するURLが次の場所に変更されています。 https://a
前 v5.16.0 | 次 v6.1.0 We're excited to announce that ESLint v6.0.0 has been released: https://t.co/EO4ZrZIMYM — ESLint (@geteslint) 2019年6月22日 ESLint 6.0.0 がリリースされました。 既存の機能を改善するための非互換な変更があります。特に、グローバル インストール (npm install -g) された ESLint コマンドを利用している場合、今まで通りには利用できない可能性が高いです。逆に、ローカル インストールを利用している場合はほとんど変化を感じないかもしれません。 また、先日の TC39 会議で Dynamic Imports と BigInt が採択されたため、ESLint でもそれら構文の実装が開始しました。進捗状況は #11
Security.Tokyo #3の発表資料です。 クライアントサイドのパストラバーサルと、postMessage経由の脆弱性を取り上げました。
TypeScriptのProject Referencesを使ってソースコードを分割し、レイヤー間の依存関係を強制する
TypeScriptのProject Referencesを使ってソースコードを分割し、レイヤー間の依存関係を強制する サマリ Project Referencesを使うと、1つの巨大なtypescriptプロジェクトを、複数のプロジェクトに分割し、プロジェクト間の依存関係を整理することができる。これにより、例えば以下のようなことができる test/ ディレクトリで export しているテスト用の関数を、 src/ ディレクトリの本番用コードでは参照できなくする レイヤードアーキテクチャで設計しているとき、プレゼンテーション層で定義している関数を ドメイン層から参照できなくし、レイヤー間の依存関係を強制する また、プロジェクトの分割によりビルド時のパフォーマンスが大幅に改善する。 …と公式で書いているが、ビルド時の挙動を正確に把握しないとむしろ悪化するので、注意が必要 適切なプロジェクト
In this announcement, we are including all changes from each of the release candidates to make it easier to see what changed from the release candidates to now. As there are a lot of changes, we’ve created a migration guide describing the changes in great detail along with the steps you should take to address them. Not all ESLint users will be affected by the changes, however, the changes are big
※こちらは2015/9/25日の古い記事です。（ESLint v1.5.1 released 22 September 2015） 現時点(2019/9/25)ではESLint v6.4.0です。 最新のドキュメントを読みに行くことを強くオススメします。 (近いうち新たに加筆してこちらに更新する予定です) こんにちは。森田と申します。芸人をしています。今回は ESLintのエラールール。日本語「ざっくりしたの」ないのか、と思ってぐぐしてもなさそうなので自分の勉強のためにも書きました。 こちらの記事は数あるカテゴリーの中の「ベストプラクティス編」です。 他カテゴリーはこちら ESLintのエラールール。日本語ざっくり解説[可能性あるエラー編] ESLintのエラールール。日本語ざっくり解説[スタイル編] ESLintのエラールール。日本語ざっくり解説[ES6編] ESLintが勧める「ベスト
![ESLintのエラールール。日本語ざっくり解説[ベストプラクティス編] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/ee40f3c4a4082af6644203e56e135d94a1e67bb3/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9RVNMaW50JUUzJTgxJUFFJUUzJTgyJUE4JUUzJTgzJUE5JUUzJTgzJUJDJUUzJTgzJUFCJUUzJTgzJUJDJUUzJTgzJUFCJUUzJTgwJTgyJUU2JTk3JUE1JUU2JTlDJUFDJUU4JUFBJTlFJUUzJTgxJTk2JUUzJTgxJUEzJUUzJTgxJThGJUUzJTgyJThBJUU4JUE3JUEzJUU4JUFBJUFDJTVCJUUzJTgzJTk5JUUzJTgyJUI5JUUzJTgzJTg4JUUzJTgzJTk3JUUzJTgzJUE5JUUzJTgyJUFGJUUzJTgzJTg2JUUzJTgyJUEzJUUzJTgyJUI5JUU3JUI3JUE4JTVEJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz02NDc1YjFhNGQyZTRmYTViZmUxZjc1Y2NiYzRmYTc5Ng%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBNLUlTTyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZDdmYWEyZjViNWRmODU3ZDUzYmY5ZDRiNzQyMDA0MTE%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D3e68d13de296632e981e279fdf746239)
【追記150803】ESLint v1.0.0がリリースされました。メジャーリリースに伴いBreaking Changeが入っていますので、下記のままでは使えないオプションが存在します。1.0.0での新ルールについてはこちらの記事でまとめています。本稿は記録のため、当時のまま残します。 どうも@armorik83です。ESLintのオプションを全部読んで吟味したので応酬を載せます。TypeScriptを辞めたというより、単機能ライブラリならES6の方が早く書けたという程度です。まさかりはブコメから。 小分け まずは小分けにして。見出し名は公式サイトと同じにしてあります。2がexit code 1投げるやつ、1はログのみ、0が無視。 Possible Errors
Chaos Engineeringという考え方 / A concept of Chaos Engineering
ChaosConf2019 recapイベント（ https://chaosconf2019recap.splashthat.com/ ）で発表した資料です。（一部修正） Chaos Engineeringの基本的な知識や考え方を、 Chaos Conf 2019に登壇した企業が語った内容を併せて発表したものです。
チームで同じような React コンポーネントを書く
はじめに 「eslint-plugin-react の plugin:react/recommended に含まれていないルールにも有効なものがあるよ！みんなで同じようなコンポーネント書いて、レビューを楽にして保守性も上げよう！」という内容の記事です。 この記事では React の関数コンポーネント、TypeScript、Prettier を使っている前提で書いています。そのため、タグの位置調整など Prettier で対応可能なものは Prettier に任せる方針です。 先に結論の .eslintrc.cjs を載せておきます。React 以外の設定は省いています。 { extends: [ "plugin:react/recommended", "plugin:react/jsx-runtime", "plugin:react-hooks/recommended" ], rules:
ESLintのエラールール。日本語ざっくり解説[可能性があるエラー編] ※こちらは2015/9/25日の古い記事です。（ESLint v1.5.1 released 22 September 2015） 現時点(2019/9/25)ではESLint v6.4.0です。 最新のドキュメントを読みに行くことをオススメします。 (近いうち新たに加筆してこちらに更新する予定です) よろしくお願いします。 ESLintのエラールール。日本語で「ざっくりしたの」ないのか、と思ってググしても出てこなかったので自分の勉強の為にも書いたよ。 ※使い方はこちら こちらのページで記されているカテゴリーの他にもこういうのがあります。是非参考にしてみてください。(私にとっては大変勉強になりました。。) ESLintのエラールール。日本語ざっくり解説[ベストプラクティス編] ESLintのエラールール。日本語ざっくり
![ESLintのエラールール。日本語ざっくり解説[可能性あるエラー編] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/36ede46b69ee56ef6f0c5bf9d3518484cbfa6093/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9RVNMaW50JUUzJTgxJUFFJUUzJTgyJUE4JUUzJTgzJUE5JUUzJTgzJUJDJUUzJTgzJUFCJUUzJTgzJUJDJUUzJTgzJUFCJUUzJTgwJTgyJUU2JTk3JUE1JUU2JTlDJUFDJUU4JUFBJTlFJUUzJTgxJTk2JUUzJTgxJUEzJUUzJTgxJThGJUUzJTgyJThBJUU4JUE3JUEzJUU4JUFBJUFDJTVCJUU1JThGJUFGJUU4JTgzJUJEJUU2JTgwJUE3JUUzJTgxJTgyJUUzJTgyJThCJUUzJTgyJUE4JUUzJTgzJUE5JUUzJTgzJUJDJUU3JUI3JUE4JTVEJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1iNTJmOGU5MDYxOGYzNTY4ZDdjM2Y3ZjhhYmQxODI1Zg%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwTS1JU08mdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTFlM2E4YTBkMWUyYjBmNWVmMTQ0ZGRkOWY2NDFmZWI0%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D8b67546479873f241f6aad1dcb47d228)
React + TypeScriptのESLintルールをカスタマイズしたり、Airbnbのやつを導入するぞ。 | Ginpen.com
何もしないでそのままでも十分かもしれない。 先にまとめ 最近の react-scripts は ESLint を含んでいるので別途インストール不要 設定は .eslintrc.js を作成して extends: ['react-app'] する Airbnb のルール設定を使う場合はもうちょい頑張る 元々 create-react-app してない場合も同じ Airbnb ルール利用時の手順概要 ESLint 初期化 ESLint の設定を更新 コードを recommended な状態へ対応 想定環境 Node.js v10.16 react-scripts v3.1 TypeScript v3.5 ESLint v6.1 @typescript-eslint/eslint-plugin v1.13 React アプリの準備 create-react-app でテンプレートから作成します。
eslintは --fix オプション付きで実行するとコード整形してくれる。 ここ1年強、 standardjs を好んで使っていて、そのルールに従って整形していた。 最近Prettierを知ったので早速導入してみたら、以下の理由ですぐに気に入った。 軽い 行が長くなった時でもいい感じに改行してくれる 設定でstandardjsっぽく調整できる Prettierのいいところはコード整形に特化している点で、コードのクオリティには一切感知しないところ。例えば no-unused-varsとかno-extra-bindとか。 standardjsはLinterルールセットとしていろいろ入っているから結構カオス感がある。 コードのクオリティは plugin:flowtype/recommended とか plugin:react/recommended に任せれば充分。 現状の設定 プロジェクトに
Pug を HTML に移行して .vue ファイル の template タグ内に ESLint を効かせた話 - SMARTCAMP Engineer Blog
こんにちは！スマートキャンプでインサイドセールスに特化した SaaSを作っているエンジニアの中川です。 上記プロダクトのフロントエンドは Vue.js を用いて開発しているのですが、 その中で SFC 内のtemplateタグで使用していた Pug をやめて HTML に移行した件をこの記事ではお話しようと思います。 また、実際にtemplateタグに ESLint を効かせてみて発覚したエラーや警告のなかで数が多かったものや、これから Vue 3 に移行していく上で対応する必要があったルールを紹介します。 背景 eslint-plugin-vue が効かない チームに Pug 推進派がいない Pug を HTML に移行するには Vue 3 に準拠した Lint ルールを導入する Lint を実行してみる 対応した目ぼしいルール vue-require-v-for-key vue/val
1,100 超えコンポーネントの Jade / Pug テンプレートを移行した話 | PLAID engineer blog
1,100 超えコンポーネントの Jade / Pug テンプレートを移行した話 | PLAID engineer blog
皆さんこんにちは。株式会社バベルでエンジニアをしている uhyo です。バベルが提供しているaileadというプロダクトでは TypeScript が多く使われており、ESLint も活用されています。この記事では、ailead のコードベースにおいて ESLint の新しい設定フォーマットであるFlat Config (eslint.config.js)を導入した事例を紹介します。 Flat Config とは？ Flat Config については、ESlint 公式ブログでも詳しく説明されています。 ファイル名がeslint.config.js固定であり、必ず JavaScript で書かなければいけないのが特徴です。新しいフォーマットでは、従来の設定ファイル（.eslintrc{.yml,.json,.js}）で辛かった部分が解消されています。特に、設定内容の解決にあたって ESLi
Vimメモ : ALE(Asynchronous Lint Engine)で非同期コードチェック - もた日記
ALE(Asynchronous Lint Engine) サポート言語とLintツール インストール 使い方 FAQと設定 特定のLintツールのみを有効にする 左端のシンボルカラムを表示したままにする シンボルを変更する エラーと警告数をステータスラインに表示する メッセージのフォーマットを変更する コードチェック完了後に特定の操作を実行する エラー間を移動する ファイル保存時のみチェックするようにする ロケーションリストの代わりにQuickFixを使用する ALE(Asynchronous Lint Engine) wonderwall.hatenablog.com 上記記事で、flake8でPythonのコードをチェックするためにSyntasticやvim-flake8を使ってみたが、チェック中に操作ができないので非同期で動作するプラグインを調べてみる。 プラグインとしてはvim-
GitHub Actionsでeslintを動かすだけでFiles changedにlint errorが表示されて便利 - $shibayu36->blog;
GitHub Actionsでeslintを動かすだけでFiles changedにlint errorが表示されるのが便利すぎたので紹介。 様子 https://github.com/shibayu36/typescript-cli-project/pull/7/files やり方 GitHub Actionsでsetup-nodeを使った上でeslintを動かすだけ。 まずGitHub Actionsでlintを実行するように設定する .github/workflows/lint.yml npm run lintの実体はこんな感じ package.json これだけで上で紹介したようにlintのエラーがFiles changedに出てくる。便利。 仕組み Problem Matchersという仕組みを使っているみたい。例えばsetup-nodeだと .github/eslint-sty
[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)
GitHub - verekia/js-stack-from-scratch: 🛠️⚡ Step-by-step tutorial to build a modern JavaScript stack.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Next.js + TypeScript + Recoil + Herp社ESLint Config でReactチュートリアルを作る。
制作したもの 概要 React のチュートリアルの三目並べを Next.js 12 + TypeScript + Recoil + @herp-inc/eslint-config の構成で、新しめの記述を取り入れた形に書き直してみた。 （上記のリポジトリにすべてのコードを掲載した。） コンセプトは、 TypeScriptの型チェックと厳しめのESLintルールでバグが起きづらい形にし、スケールしても内部品質を担保。 Next.jsで作ることにより、ブラウザでのパフォーマンスと開発体験の向上 である。 改良したいポイント React のチュートリアルの三目並べ（マルバツゲーム）の公式サイトに掲載されている元のコードは以下である。 この code に関して、以下のような課題が考えられる。 React の書き方が、現在では非推奨のクラスコンポーネントである。（関数コンポーネント + React
{ "extends": [ "eslint:recommended", "plugin:@typescript-eslint/recommended", "plugin:@typescript-eslint/eslint-recommended", "plugin:react/recommended", "prettier" ], "plugins": [ "@typescript-eslint", "react" ], "parser": "@typescript-eslint/parser", "parserOptions": { "sourceType": "module", "ecmaFeatures": { "jsx": true } }, "rules": { "react/prop-types": "off", "react/react-in-jsx-scope": "of
prettierの使い方 - Qiita
ということで、JavaScriptのフォーマッタのprettierの紹介です。 React Confで紹介されてたものを色々試してみようと思って、まずはprettierを試してみました。 追記 2017/4/14: Prettier1.0(とMinor fixあてた1.1.0)が出ました。本記事の内容は1.0でもそのまま問題なく適用できました。 2019/7/7: prettier-eslintよりもeslint-plugin-prettierを使ったほうが良さそうです prettierとは JavaScriptのコードを整形してくれるフォーマッタ。他言語で言うとGolangのgofmtみたいなもの。 他のフォーマッタと比べて設定項目が少ないので開発者間で迷いなく共通のスタイルで統一される。 まだベータ。 1月にリリースされてから2ヶ月ちょっとでスター数6000超え。例えばeslintは3
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ESLint v2.0.0 の変更点まとめ - Qiita
Prettier 2.7 にキャッシュを実装した
Result型とESLintでエラーハンドリング漏れを検出する
2018年は、reduxとeslintとflowとwebpackを捨ててみようと思う - Qiita
ESLintでTypeScriptの変数の名付け規則をチェックしよう！ | DevelopersIO
ESLintをAtomに導入し、Reactの構文にも対応したAirbnbのJSスタイルガイドを使う
typescript-eslint v6 アップデートガイド
【Next.js】eslint + pretteirをやめてBiomeにした話
TypeScriptではNumber.isNaN()よりもisNaN()の方が安全かもしれない
TypeScript 5.0 で追加された verbatimModuleSyntax とは何か？
JavaScriptで3 > a > 1と書いてしまった話 - sasurau4のブログ
JSのプラグインシステムについて書くJavaScript Plugin Architecture 2.0をリリースしました
ESLint v6.0.0 の変更点まとめ - Qiita
注目したいクライアントサイドの脆弱性2選/ Security.Tokyo #3
ESLint v2.0.0 released - ESLint - Pluggable JavaScript Linter
ESLintのエラールール。日本語ざっくり解説[ベストプラクティス編] - Qiita
JavaScript - .eslintrc晒す - Qiita
ESLintのエラールール。日本語ざっくり解説[可能性あるエラー編] - Qiita
コード整形をStandardJSからPrettierに乗り換えたら捗った - 丁寧に手を抜く
Flat Config導入完了！ 新しいESLintの設定フォーマットを使ってみた
うわっ...私の.eslintrc、無駄が多すぎ...？