先日、こちらのESLint Pluginを作成したのでご紹介します。 実装したLintルール 以下の2つのLintルールを実装しています。 next/imageをimportするとエラーを出す next/linkをimportするとエラーを出す 作ろうと思った背景 Fastly IO（Image Optimizer）やimgixを使用して画像の最適化を行なっているサービスでは、next/imageを使用する意味がないため、使用を制限したいケースがあります。また、Server Side RenderingをしているページをCDNでキャッシュしている場合や、一部のページだけでNext.jsを使用している場合に、next/linkの使用を制限したいケースもあります。 参考記事 このような背景から、Next.jsのnext/imageおよびnext/linkの使用を制限するESLint Plugi
Highlights MCP Server Integration ESLint v9.26.0 adds support for a Model Context Protocol (MCP) server, enabling ESLint to interact with AI models and tools through a unified interface. This feature allows large language models (LLMs) to run ESLint in IDEs and other software, assisting developers with tasks like linting and code analysis. The MCP server can be started using the --mcp flag in the
ESLint コアルールの TypeScript 対応について ESLint v9.23.0 で ESLint のコアルールの TypeScript 対応が開始しました。 その後の ESLint のアップデートでもコアルールの TS 対応が進んでいます。ESLint コアの責務を増やすような機能追加は少し意外だと感じたので、その背景について調べてみました。 背景: 従来のコアルールの拡張方法の課題 ESLint のコアルールは JavaScript を想定して書かれたものであるが、TypeScript に対してもほぼ期待通り動作するルールが多い。TypeScript は JS のほぼ上位互換な言語であるため、TypeScript 用のパーサー (@typescript-eslint/parser) が吐き出す AST もほぼ上位互換であり、パーサーさえ TS 用のものを使えば多くの ESL
背景 ある日。 彡(ﾟ)(ﾟ) 「ファッ！？ 基本ケバブケースでファイル名が作られてるのに、一部でスネークケースとキャメルケースが混じっとる！！」 という状況に直面しました。 Nest.jsで作っていたマイクロサービスで起こっており、基本的にキャメルケースで当初は命名が統一されていました。 が、別のマイクロサービス(Laravel)でModel(Actice Record)の定義などを先にしていたのをNest.jsにそのまま持ち込んだ際に、テーブル名がキャメルケースだったりすることもあり、そこから紛れ込み始めたものと思われます。 要するに、人為的なエラーです。 ということでこれを修正する 目に見えるケバブケース以外のファイル命名は潰せましたが、本当潰し切れているか。あるいはこれから先も同じようなことが起こらないかが気になるところ。 こんなときの解法がlinterによる静的解析です。 という
Baseline はブラウザで利用可能な JavaScript や CSS のサポート状況を明確化するプロジェクトです。ESLint/CSS の require-baseline ルールを使用することで、Baseline でサポートされていない CSS プロパティや値を検出することができます。 ブラウザによる CSS のサポート状況の差異は、Web 開発者にとって頭痛の種です。新しい CSS プロパティや値を使用する際には、それがどのブラウザでサポートされているかを確認する必要があります。Baseline はそのような問題を解決するためのプロジェクトです。ブラウザで利用可能な JavaScript や CSS のブラウザのサポート状況を明確化することで、Web 開発者が安心して新しい機能を使用できるようになります。 Baseline で「Newly Available」とされている機能は
こんにちは、フロントエンドエンジニアのやなぎ（@apple_yagi）です。 PR TIMESではフロントエンドのReactリプレイス当初より Barrel file を作成するルールがありました。しかし、先日そのルールを廃止することに決めたため、その経緯についてご紹介します。 Barrel filesとは Barrel filesとは複数のモジュールを1つのファイル（Barrel file）にまとめてexportすることを指します。以下の例ではutils/test.ts 、utils/fuga.ts 、utils/hoge.ts で export されている定数を utils/index.ts で再exportしています。 // utils/test.ts export const test = 1; // utils/fuga.ts export const fuga = 2; //
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
