本記事では、ブラウザ拡張機能開発を加速させる、個人的に注目な3つの拡張機能開発フレームワーク・ツール（WXT、Plasmo、Extension.js）を紹介します。 サンプル拡張機能の実装を通して、それぞれの特徴、セットアップ方法、実際の開発フローを見ていきます。お好みの拡張機能開発ツールが見つかれば嬉しいです。 各フレームワーク・ツールの紹介 WXT WXTは、Viteベースのブラウザ拡張フレームワークです。次のような特徴を持っています（トップページから抜粋）。 クロスブラウザ対応 Chrome、Firefox、Edge、Safari、その他Chromiumベースのブラウザ Manifest V2、V3の両方に対応 開発モードでのHMRと、開発用ブラウザの自動起動 内部的にChrome Launcher等を使用 ファイルベースのエントリーポイントでマニフェストを自動生成 Nuxt風の自動

近年、TypeScript を取り巻くエコシステムでは、ユーザーに明示的な型注釈を求めることで、推論や型生成のコストを下げるというアプローチが注目されています。TypeScript 5.5 beta で　発表された --isolatedDeclarations オプションはその代表的な機能ですし、Deno の提供する新しいパッケージレジストリ JSR が提唱している slow types という考え方も同様のアプローチを求めるものです。 この記事では、上記のようなアプローチが提案された経緯や解決したい課題について、TypeScript を利用するエコシステムの状況も踏まえて整理します。 TypeScript を取り巻くツールチェインと型情報を利用する上でのパフォーマンス 皆さんがご存知の通り、TypeScript の型推論は非常に賢く、その機能は日々アップデートされています。特に以下のよう

React Compiler React 19 Beta から React Compiler が導入され利用可能となりました。 ※単体での検証としては次の記事が参考になります。 Next.js での利用 React Compiler のドキュメント内には、各種バンドラやフレームワークで利用する方法も記載されています。 というわけで、Next.js で実際に試してみよう、というのがこの記事の主旨です。 事前準備 / セットアップ 基本的にドキュメントに従って進めます。注意点としては、執筆時点での Next.js の Stable バージョン 14.2 ではまだ React 19 が利用できないため、canary バージョンの利用が必要です。 適当なディレクトリを作成し、その中で create-next-app を実行します。 実験用のためオプションは適当に選択しますが、せっかくなので Tur

React Aria Components は Adobe によって提供されている Headless UI コンポーネントライブラリです。振る舞いや国際化に, アクセシビリティに関する機能を備えており、Button や Input, TextField, Label などのシンプルな要素から、DatePicker や ComboBox などの様々なコンポーネントが提供されています。 今回は React Aria Components の設計について紹介します。 React Aria Components のコンポーネントの設計 React Aria Components の API はコンポジションを中心に設計されています。これにより、パターン間で共通のコンポーネントを共有することも、個別に使用することも可能です。なお、コンポジションについては React Component Compos

社内の人から、自分が以前書いた次の記事が「便利で助かった！書いた時から何かアップデートある？」ってメッセージがきた。 そんな便利だなんてどうもありがとうございますウフフ、と思いながら書いた日を見てみると 2022-08-09 だった。もうすぐ 2 年経とうとしてる。時の流れが早くて怖い。 この記事に書かれた実装例はリポジトリにまとめていたんだけど、当然、何かメンテをしていたわけもなく、2022 年当時の状態がそのまま残っていた。 せっかく便利に思ってくれる人がいたので、内容をアップデートする。 アップデートまとめ メジャーバージョンのリリースやビルドツールの統一の観点で Jest から Vitest に移行 useFakeTimers({ shouldAdvanceTime: true }) @testing-library/reactを v15 にバージョンアップ MSW を v2 にバ

SPA モードの Remix を GitHub Pages にデプロイする方法が Remix のアカウントでポストされていたので、ふとそのリポジトリを見てみると、GitHub Actions を使った GitHub Pages へのデプロイが簡単に行えるようになっていて驚いた。 このポストを見ると GitHub Actions から提供されている Action など知らなかったものがいくつかあったので、Remix SPA モードのデプロイ方法など含め、内容を紹介したい。 動作確認した環境 関連がありそうな依存を記す。 "dependencies": { "@remix-run/node": "^2.8.1", "@remix-run/react": "^2.8.1", "@remix-run/serve": "^2.8.1", "react": "^18.2.0", "react-dom"

このドキュメントは、次の Biome のブログの日本語訳になります。 細かい内容については、ぜひ原文の方を読んでもらえると嬉しいです。 ロードマップ 2024 コアコントリビューターとメンテナーが 2024 年にフォーカスしようとしていることを共有できることはとても嬉しいです。一方で、Biome はコミュニティ主導のプロジェクトであるため、取り上げている全てのアイデアのリリースを約束することはできません。 もしいくつかのアイデアに共感し、それらの開発を加速させたいと思った際には、次のような方法でサポートすることができます。 プロジェクトとコミュニティに参加する。アイデアを実装するためのサポートをすることができます。 スポンサーになる。Biome をお使いの会社では、スポンサーになることができます。Biome は CI の時間を削減し、費用を節約できるほど速いです。パフォーマンスは、プロジェ

Next.js の公式ブログの How to Think About Security in Next.js という記事で Next.js 14 で導入される React Taint APIs について紹介されていました。 この記事では、Next.js 14 で React Taint APIs 実際に試してみて、どのような機能なのかを確認してみたいと思います。 React Taint APIs とは？ React Taint APIs とは、React が experimental バージョンで提供する新しいセキュリティ保護機能の一つです。このAPIを使用することで、誤って Client Component にセキュリティ上の重要なデータが渡されることを防げるようになります。 具体的には、以下の2つの API が提供されています。 experimental_taintObjectRefe

この記事では、Playwright の VSCode 拡張を使って GUI 操作のみでテストの記録や実行する方法について紹介します。 Playwright の VSCode 拡張とは？ Playwright の VSCode 拡張は、Playwright の作成元である Microsoft が公式に提供している拡張機能で、VSCode 内で直接ブラウザテストの記録や実行を支援するための便利なツールです。 GUI 操作を中心に、テストの記録や実行を手軽に行うことが可能となります。 VSCode 拡張のインストールは、以下のリンクから行うことができます。 VSCode 拡張を活用してテストを書く 本記事では、シンプルな ToDo アプリを例にテストの作成方法を説明します。Playwright のインストール方法は、公式ドキュメントをご参照ください。その後、VSCode に Playwright

Biome では、現在約 150 個程度の JavaScript・TypeScript に関する lint ルールを実装しています。 これらのルール多くは既存の ESLint 関連で実装されているルールと同じものになっているのですが、ルールの名前が異なることもあり、その対応関係がわかりにくくなっています。 そこでこの記事では、フロントエンド開発をする場合によく設定していそうな次の lint ルールについて、Biome で実装されているかどうかの対応表を紹介します。 eslint (eslint:recommended) typescript-eslint (plugin:@typescript-eslint/recommended) eslint-plugin-jsx-a11y (plugin:jsx-a11y/recommended) eslint-plugin-react (plugi

Next.js Server Actions Next.js 13.4 に、新機能として Server Actions が追加されました。 2023 年 5 月現在では α 版ですが、Next.js でのアプリケーション設計方法に大きく影響を与えそうな気配をガンガン醸し出しています。 Server Actions？ Server Actions 自体が何かについては、すでに多くの方が記事を投稿されているため、詳細な説明は省きますが、とりあえずは「"use server" を付与したバックエンド処理を含む関数をクライアント側から直接呼び出すかのように振る舞う機能」と認識しておけばよいかと思います。（もちろんそのまま直接実行はできないため、実際には Next.js の仕組みで間接的にバックエンドと通信して実行しています。） Next.js の公式ドキュメントにも Server Actions

3 行まとめ Next.js の App Router では <Suspense> を使ったストリーミングがサポートされている React には、Node.js Streams と Web Streams に対応する Server API がある Streams APIの ReadableStream を使ってサーバーサイドから値を段階的に受け取る(ストリーミングする)方法を紹介 Streaming with Suspense Next.js の App Router では <Suspense> を使ったストリーミングがサポートされています。 <Suspense> を使ったストリーミングではページの HTML を小さな塊に分解し、その塊をクライアントに順次送信できます。この <Suspense> を使うことで、ページの一部をより早く表示できます。 Next.js のドキュメントにあるExa

先日 Vercel の@leeerob氏が次のようなツイートをしていました。 I'm working on updated testing docs for the @nextjs App Router. next@canary supports Jest for server & client components, metadata, server-only, and more なんと next@canary で、Server Components の Jest でのテスト実行がサポートされているとのことです！これは試さないと！ next@13.4.19 時点での Server Components テストの課題 Next.js App Router で開発するときの大きな課題の一つがテストで、現状では Server Components と testing-library を組み合わ

Next.js 13には、LayoutとTemplateというよく似た機能が存在します。 この記事では、それぞれの特徴と使い分け方についてまとめてみました。 Layoutとは？ Layoutは複数のページに渡って共有されるUIのことを指します。 特徴としては画面遷移が行われた際に、その状態を保持し、再レンダリングは行われません。またLayoutはネスト（入れ子）にして使用することも可能です。 Layoutの定義方法 appディレクトリ配下で layout.tsx ファイルを定義するとLayoutとして定義できます。 例えば、以下のようなLayoutを定義することができます。 // app/posts/layout.tsx export default function Layout({ children, }: { children: React.ReactNode; }) { retur

Next.js Server Actions Next.js 13.4 で、新機能として Server Actions[1] が追加され、バックエンド側のコードをあたかもクライアントから直接呼び出せるかのようにコードを書くことができるようになりました。 リリースブログに掲載されていた Server Actions のコードを見てみましょう。 // app/post/[id]/page.tsx (Server Component) import kv from "./kv"; export default function Page({ params }) { async function increment() { "use server"; await kv.incr(`post:id:${params.id}`); } return ( <form action={increment}

typescript-eslint v6 リリース！ 2023/07/10 に typescript-eslint の v6 がリリースされました。 メジャーバージョンアップということで多くの BreakingChange があるのですが、その中でもReworked Configuration Namesと呼ばれる変更は利用者に大きな影響を与えそうです。 Reworked Configuration Namesはざっくり言うと「config に書くrecommendedのようなルールセットの名前や枠組みが変わるよ」という変更です。 ルールセットの名前だけでなく、含まれるルールや分類自体に変更があるので、設定ファイルを v5 のままアップデートしてしまうと意図したルールセットと異なる設定になってしまいます。 ここでは上記の記事にある変更点を紹介しつつ、なるべく既存の設定のままアップデートする

最近、Boshen さんが開発している Oxc に注目しています。 社内で Oxc の近況を slack に投稿していたところ、「Oxc は Rome で話題になっていますか？」や「Oxc はうまくいくと思いますか？」と聞かれたことで Rome の現状を整理するいいきっかけになったので、記事に残しておこうかなと思います。 Rome と Oxc の違い Rome と Oxc はどちらも linter、formatter、transpiler などを提供するつもりではあるので、ユーザーからみた違いは分かりにくいかなとは思います。現時点での大きな違いは、次の２点だと思っています。 プロジェクトのスコープ Rome: JS/TS に限らず Web 開発に関連する言語全般にツールを提供することを試みている Oxc: JS/TS に関するツールにフォーカスしている 提供するツールの拡張性に対する考え方

ちょっと時間が経ってしまったのですが Rome の core contributor になったので、なるまでの振り返りと現在の Rome の状況について少し書きたいと思います。 Rome とは Rome は、増え続けている JavaScript の開発に必要なツールチェーンを統一し、開発者体験を改善しようということで始まった OSS です。現在は、JS (JSX)・TS・JSON に対する formatter と linter を提供しています。 Babel の生みの親である Sebastian McKenzie さんが 2017 年頃からプライベートで開発を始め、2020 年頃からは OSS として開発が進められています。2021 年の 7 月ごろまでは、3rd party の npm パッケージを極力利用せずに TypeScript で実装されていました。[1] 2021 年の 7 月