Flat Config導入完了！ 新しいESLintの設定フォーマットを使ってみた
皆さんこんにちは。株式会社バベルでエンジニアをしている 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
JavaScript/TypeScript の Lint ツールを XO で統一した - ドクターズプライム Official Blog
@1000ch (id:hc0001) です。掲題の通り、少し前にドクターズプライムの Frontend プロジェクトで使う lint ツールとして ESLint ではなく XO を使っていく方針に切り替えました。最近その振り返りを行ったので、その備忘録として文字に起こします。 github.com 経緯と課題 これまでは Create React App に付属する ESLint に加えてルールを少しカスタマイズして、それをいくつかのプロジェクトで使っていました。これにはいくつかの課題が存在していました。 ESLint およびその周辺プラグインの依存関係を含めたバージョンアップをケアし続ける必要がある renovate や dependabot などを用いて（半）自動化できるものの、依存の数や大きさに応じて依然としてコストが高い ESLint のルールを中長期的にメンテナンスする必要があ
React+TSプロジェクトで便利だったLint/Format設定紹介
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「linter/formatter」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが 株式会社ナレッジワーク というスタートアップで開発・運用しているプロジェクトにおいて便利だったLint/Format関連の設定についてご紹介していきます。 使っているのは、TSのlintのためにESLint, CSSのlintのためにStylelint, 主なファイルのformatのためにPrettierです。 ESLint pluginsとextendsだけどんなもの入れてるか載せておきます。 "plugins": [ "strict-dependencies", // 後述 "unused-imports", // 後述 ], "extends": [ "a
Next.jsに専用のESLintが追加された！
Next.js11がついに発表されましたね。 next/script、Next.js Liveなど、興味深い機能が色々ですが、自分が地味に嬉しかったのはNext.js専用のESLint設定がデフォルトでサポートされたことです。 create-next-appでESLint設定済みのNext.jsプロジェクトが作成できる ReactやNext.jsのプロジェクトを立ち上げる際、結構面倒くさい難しいのがESLintの設定です。 .eslintrcファイルの記述とか、extendsの記述順によって優先されるルールとかも変わってくるので、慣れないうちはなかなか難しい作業でしょう。（自分はいまだに試行錯誤してます…） しかし、今ではcreate-next-appを使うと、専用のESLintが設定済みのNext.jsプロジェクトを作成してくれます。 実際にコマンドを実行した結果を見ていきましょう。 $
【2020冬】 TypeScript + Prettier + ESLint + VSCode の設定 - Qiita
概要 eslint-plugin-prettier が非推奨になったらしい。 いつのまにか eslint-plugin-prettier が推奨されないものになってた | K note 以下の要件を満たしつつ、ESLint の config から Prettier を分離したい。 VSCode からフォーマッタを実行できる。 非 VSCode 民でも npm script からフォーマッタを実行できる。 CI でフォーマッタ未適用コードをエラーにできる。 TL;DR src: https://github.com/arx-8/try-separate-eslint-and-prettier/commit/0d0f92201ca2102f20893b26fd23a902621aba41 やったこと VSCode からフォーマッタを実行 以下の通り移行。 prev: 拡張機能 dbaeumer
GitHub上でSwaggerをプレビューできるChrome拡張機能を作った - Qiita
概要 GitHub 上で、Swagger の yaml | yml | json を Swagger-UI に変換できる Chrome 拡張機能を作った。 その紹介。 「Swagger とは？」という話は、下記等を参照のこと。 Swaggerの概要をまとめてみた。 - Qiita Demo クリックするだけ。簡単に変換できる。 全展開・全折り畳みができて便利。 インストール Chrome Web Store からインストールできる。 swagger-viewer - Chrome ウェブストア 特徴 簡単 1クリックで変換できる 依存なし この拡張機能のみで動作する Web の Swagger Editor を開いたり、ドキュメント生成サーバーを起動する必要なし セキュア（たぶん） 外部ネットワークへの送受信はないため、業務でも使用できる ※自己責任でお願いします たぶん Chrome の
@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を削
ES modulesのexport defaultは使わないほうがよい - Islands in the byte stream
ES modulesにexport defaultってのがあるんですが、default exportのexport対象に名前が必須でないため、IDEによるコード補完と相性が悪いです。 他のところはどうしてるのかなと思って調べてみると、GoogleのTypeScript Style Guide では禁止されてました(v1.0.0, 2019/07 現在）。 https://github.com/google/gts/blob/v1.0.0/tslint.json#L40 ("no-default-export": true) TypeScript compiler coding guidelineには特に言及はないみたいですね。 https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines そもそもexport defaultは
全力で大きくなるReactのコードをスタイルガイドに沿って見直したら、大変勉強になりました | Wantedly Engineer Blog
Wantedlyでは今年に入って、Reactの導入や、webpackの導入によるビルドプロセスの変更、CoffeeScriptからJavaScriptへの変更など、フロントエンドの開発環境が大幅に変更されました。このあたりの話は高松の記事に詳しく書かれていますが、よりリッチなUIを効率的にチーム開発できるようになり、とてもいい変化でした。 コードの質にばらつきがReact導入時は、一つのチームだけReactの開発を行っていたのですが、複数チームが独立して開発するようになると、同じReactのコードでもチームごとに雰囲気の違うコードが出来上がっていました。 ここは括弧を付けるべきなのか、このインデントは好ましいのか、ここはSyntac Sugerを使ったほうがいいんじゃないかなど、疑問点がある度にチーム間で確認をとるのは大きなコストになるため、どこまで指摘するかはチームのレビュアーに依存して
JavaScript(ES2015)でvarやletを使う必要はほぼ無い - id:anatooのブログ
ES2015でvarやletを使う場面はほとんど無いので、まずconstを使う。constだとダメな場合にはletを使う。 背景 ES2015では、変数を宣言するための文法としてconstとletが導入された。 const foo = 'foo'; let bar = 'bar'; constは再代入できない変数を宣言できる。letは再代入できる変数を宣言できる。 const foo = 'foo'; foo = 'hoge'; // ERROR let bar = 'bar'; bar = 'hoge'; // OK あれ、じゃあvarとletは同じなの？っていうとそうではなく、letやconstはvarとは違って、関数スコープよりも細かなブロック単位のスコープを提供する。例えばconstやletを使うと、if文やfor文などのブロック中でのみ有効な変数を宣言できる。 で、プロジェクトに
僕が JavaScript 開発をするときの ESLint の設定ファイルの基本形 - BattleProgrammerShibata
eslint.org 目下のところ JSHint と JSLint 戦争は ESLint という第三勢力の登場によって僕の中でめでたく終結したので最近の JS 開発の際には ESLint を使っている。で、以下の .eslintrc （プロジェクト単位に作れる ESLint の設定ファイル）が僕の場合の基本形。欲しくなったルールをなんか秘伝のタレ的に下に下に継ぎ足してるので、特に定義の順序には拘ってない。 { "rules": { // 定数式による条件を警告 "no-constant-condition": 1, // 情報が不十分な JSDoc を警告 "valid-jsdoc": [2, { "requireReturn": false }], // console メソッドを注意 "no-console": 1, // alert メソッドを許可 "no-alert": 0, //
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
