crxjs

作成者: samber

CRXJS Chrome extension development — true HMR for popup, options, content scripts, side panels, manifest-driven builds, dynamic content script imports (`?script`, `?script&module`), and `defineManifest` for type-safe manifests. Uses Vite as its build tool. Use when the user mentions CRXJS, crxjs, @crxjs/vite-plugin, 'extension with hot reload', 'HMR for chrome extension', or wants to set up a CRXJS-based Chrome extension project with any framework (React, Vue, Svelte, Solid, Vanilla). Also...

npx skills add https://github.com/samber/cc-skills --skill crxjs

CRXJS

CRXJS is a Chrome extension development tool that provides true HMR for popup, options, content scripts, and side panels. It reads your manifest to auto-generate the extension output, handles content script injection, and manages the service worker build. Under the hood it is a Vite plugin (@crxjs/vite-plugin).

Current status

  • Package: @crxjs/vite-plugin (v2.x stable, latest v2.4.0 as of March 2026)
  • Scaffolding: npm create crxjs@latest (always use @latest)
  • Maintained by: @Toumash and @FliPPeDround (since mid-2025)
  • GitHub: github.com/crxjs/chrome-extension-tools (~4k stars)
  • Vite compatibility: v3 through v8-beta

Quick start

# Scaffold new project (picks framework interactively)
npm create crxjs@latest

# Or add to existing Vite project
npm install @crxjs/vite-plugin -D

Vite config by framework

CRXJS is added as a Vite plugin. The setup varies slightly per framework.

React

// vite.config.ts
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import { crx } from "@crxjs/vite-plugin";
import manifest from "./manifest.json";

export default defineConfig({
  plugins: [react(), crx({ manifest })],
});

Use @vitejs/plugin-react (not plugin-react-swc) for best HMR compatibility. If you must use SWC, cast the manifest:

import { ManifestV3Export } from "@crxjs/vite-plugin";
const manifest = manifestJson as ManifestV3Export;

Vue

import vue from "@vitejs/plugin-vue";
import { crx } from "@crxjs/vite-plugin";
import manifest from "./manifest.json";

export default defineConfig({
  plugins: [vue(), crx({ manifest })],
});

Svelte

import { svelte } from "@sveltejs/vite-plugin-svelte";
import { crx } from "@crxjs/vite-plugin";
import manifest from "./manifest.json";

export default defineConfig({
  plugins: [svelte(), crx({ manifest })],
});

Vanilla TypeScript

import { crx } from "@crxjs/vite-plugin";
import manifest from "./manifest.json";

export default defineConfig({
  plugins: [crx({ manifest })],
});

defineManifest — type-safe dynamic manifest

Instead of a static JSON file, use CRXJS's defineManifest for dynamic values and full TypeScript autocompletion:

// manifest.ts
import { defineManifest } from "@crxjs/vite-plugin";
import pkg from "./package.json";

export default defineManifest((config) => ({
  manifest_version: 3,
  name: config.command === "serve" ? `[DEV] ${pkg.name}` : pkg.name,
  version: pkg.version,
  description: pkg.description,
  permissions: ["storage", "activeTab", "scripting"],
  action: {
    default_popup: "src/popup/index.html",
    default_icon: {
      "16": "public/icons/icon16.png",
      "48": "public/icons/icon48.png",
    },
  },
  background: {
    service_worker: "src/background/index.ts",
    type: "module",
  },
  content_scripts: [
    {
      matches: ["https://*/*"],
      js: ["src/content/index.ts"],
      css: ["src/content/styles.css"],
    },
  ],
  options_page: "src/options/index.html",
  side_panel: { default_path: "src/sidepanel/index.html" },
  icons: {
    "16": "public/icons/icon16.png",
    "48": "public/icons/icon48.png",
    "128": "public/icons/icon128.png",
  },
}));

Import in vite.config.ts:

import manifest from "./manifest";
// ... crx({ manifest })

Type declarations

Add to a src/vite-env.d.ts or src/crxjs.d.ts:

/// <reference types="@crxjs/vite-plugin/client" />

This enables types for ?script and ?script&module imports.

HMR behavior by context

ContextHMRHow it works
PopupFull HMRWebSocket-based, state preserved
Options pageFull HMRSame as popup
Side panelFull HMRSame as popup
Content script (manifest)True HMRCRXJS injects loader + HMR client
Content script (dynamic)True HMRVia ?script import
Service workerAuto-reloadChanges trigger full extension reload
Main world scriptsNo HMRSkipped by CRXJS loader

Content script HMR works because CRXJS generates a loader script that imports an HMR preamble, the HMR client, and your actual script — enabling real module-level HMR without full page reload. This is CRXJS's main differentiator.

Dynamic content script imports

For content scripts injected programmatically (not in manifest), CRXJS provides special import suffixes:

// background.ts — ?script gives you a resolved path for executeScript
import contentScript from "./content?script";

chrome.action.onClicked.addListener(async (tab) => {
  await chrome.scripting.executeScript({
    target: { tabId: tab.id! },
    files: [contentScript],
  });
});

For main world injection (no HMR):

import mainWorldScript from "./inject?script&module";

await chrome.scripting.executeScript({
  target: { tabId },
  world: "MAIN",
  files: [mainWorldScript],
});

CRXJS plugin options

crx({
  manifest,
  browser: "chrome", // 'chrome' | 'firefox'
  contentScripts: {
    injectCss: true, // auto-inject CSS for content scripts
    hmrTimeout: 5000, // HMR connection timeout (ms)
  },
});

Development workflow

# Start dev server (outputs to dist/ with HMR)
npm run dev

# 1. Open chrome://extensions
# 2. Enable "Developer mode"
# 3. Click "Load unpacked"
# 4. Select the dist/ directory
# 5. Edit code — popup/content scripts update instantly via HMR
# 6. Service worker changes trigger automatic extension reload

After loading once, subsequent npm run dev sessions reconnect automatically. No need to re-load the extension unless manifest.json changes.

Production build

npm run build    # outputs to dist/

The dist/ directory is ready to zip and upload to Chrome Web Store:

cd dist && zip -r ../extension.zip .

Disable Vite's module preload to avoid CWS rejection of inline scripts:

build: {
  modulePreload: false;
}

Known issues and workarounds

Tailwind CSS HMR in content scripts

New Tailwind classes may not trigger CSS updates in content scripts. Workaround: restart dev server after adding new utility classes. Improved in v2.4.0 but not fully resolved. Ensure injectCss: true in config.

WebSocket connection errors (ws://localhost:undefined/)

Cause: port mismatch between dev server and HMR config. Fix: explicitly set both to the same value:

server: {
  port: 5173,
  strictPort: true,
  hmr: { port: 5173 },
}

"Manifest version 2 is deprecated" warning

If you see this, your manifest is being interpreted as MV2. Fix: ensure "manifest_version": 3 is set.

Content scripts not injecting on file:// URLs

Chrome requires the user to enable "Allow access to file URLs" in the extension settings at chrome://extensions. CRXJS cannot change this.

HMR stops working after Chrome update

CRXJS's HMR relies on injecting a content script that connects to the dev server's WebSocket. Chrome security updates occasionally break this. Fix: update to the latest CRXJS version, which tracks Chrome changes.

CRXJS vs alternatives

FeatureCRXJSWXTPlasmo
Content script HMRTrue HMRFile-based reloadPartial
Framework supportAny Vite frameworkAnyReact-focused
Abstraction levelThin (Vite plugin)Full frameworkFull framework
Messaging helpersNone (use chrome.* directly)Built-inBuilt-in
Storage wrappersNoneBuilt-inBuilt-in
Cross-browserChrome + FirefoxChrome + Firefox + SafariChrome + Firefox
File-based routingNoYesYes
Learning curveLow (know Vite, know CRXJS)MediumMedium

Choose CRXJS when: you want minimal abstraction over raw Chrome APIs and value content script HMR above all. CRXJS stays out of the way — no magic routing, no wrapper APIs, just your code with HMR.

Choose WXT when: you want conventions, built-in utilities, and cross-browser support.

Choose Plasmo when: you're React-focused and want the highest-level abstraction.

Project structure (recommended)

my-extension/
├── src/
│   ├── background/
│   │   └── index.ts
│   ├── content/
│   │   ├── index.ts
│   │   └── styles.css
│   ├── popup/
│   │   ├── index.html        <- CRXJS resolves HTML entry points
│   │   ├── App.tsx
│   │   └── main.tsx
│   ├── options/
│   │   ├── index.html
│   │   └── main.tsx
│   ├── sidepanel/
│   │   ├── index.html
│   │   └── main.tsx
│   └── shared/
│       ├── messages.ts
│       └── storage.ts
├── public/
│   └── icons/
├── manifest.ts               <- or manifest.json
├── vite.config.ts
├── tsconfig.json
└── package.json

CRXJS resolves HTML files referenced in the manifest automatically. Your popup.html can use standard <script type="module" src="./main.tsx"> and it works.

If you encounter a bug or unexpected behavior in CRXJS, open an issue at github.com/crxjs/chrome-extension-tools/issues.

samberのその他のスキル

golang-code-style
samber
We need to translate the given text from English to Japanese, preserving the name "golang-code-style" and other technical terms. The instruction says: "Translate only the text inside <text>. Do not include the name unless it appears in the source text." The name "golang-code-style" appears in the source text? Actually, the source text does not contain the name "golang-code-style" explicitly. The name is given in the context: "Name to preserve: golang-code-style". But the instruction says "Do not include the name unless it appears in the source text." Since it does not appear in the source text, we should not add it. However, the source text contains references like "samber/cc-skills-golang@golang-naming" etc. Those should be preserved as is. We need to translate the description of the skill. The text describes conventions for Go code style. We'll translate into natural Japanese, keeping technical terms like "Go", "linter", "doc comments" etc. Also preserve the arrows and references. Let's break
developmentcode-review
golang-testing
samber
We need to translate the given text from English to Japanese, preserving the name "golang-testing" if it appears. The text is a description of a directory item type "agent skill". The instruction says: "Do not include the name unless it appears in the source text." The name "golang-testing" does not appear in the provided <text>? Actually, looking at the text: it starts with "Production-ready Golang tests — ..." and later mentions "samber/cc-skills-golang@golang-stretchr-testify". The name "golang-testing" is not in the text. So we should not add it. We just translate the content. We need to preserve product names, protocol names, URLs, numbers, technical terms. So "Golang", "testify", "goleak", "CI", "Go", "samber/cc-skills-golang@golang-stretchr-testify" should remain as is. Also "table-driven tests", "testify suites and mocks", "parallel tests", "f
developmenttestingcode-review
golang-design-patterns
samber
慣用的なGo言語のデザインパターン — 関数型オプション、コンストラクタ、エラーフローとカスケード、リソース管理とライフサイクル、グレースフルシャットダウン、耐障害性、アーキテクチャ、依存性注入、データ処理、ストリーミングなど。アーキテクチャパターンを明示的に選択する際、関数型オプションを実装する際、コンストラクタAPIを設計する際、グレースフルシャットダウンを設定する際、耐障害性パターンを適用する際、または特定の問題に適合する慣用的なGoパターンを尋ねる際に適用します。
developmentdesigncode-review
golang-error-handling
samber
We need to translate the given English text into Japanese, preserving the name "golang-error-handling" if it appears, but it does not appear in the text. The text is a description of a skill for idiomatic Go error handling. We must not add any extra commentary, labels, or formatting. Just the translation. The text includes technical terms: "Idiomatic Golang error handling", "creation", "wrapping with %w", "errors.Is/As", "errors.Join", "custom error types", "sentinel errors", "panic/recover", "single handling rule", "structured logging with slog", "HTTP request logging middleware", "samber/oops for production errors", "log aggregation 3rd-party tools", "Go code", "samber/cc-skills-golang@golang-samber-oops". These should be preserved as is or translated appropriately. For example, "Idiomatic Golang error handling" can be translated as "慣用的なGoのエラーハンドリング". But we need to keep technical terms like "errors
developmentcode-review
golang-performance
samber
Golangのパフォーマンス最適化パターンと方法論 - XのボトルネックがあればYを適用。アロケーション削減、CPU効率、メモリレイアウト、GCチューニング、プーリング、キャッシング、ホットパス最適化をカバー。プロファイリングやベンチマークでボトルネックが特定され、それを修正するための適切な最適化パターンが必要な場合に使用。また、パフォーマンスコードレビューを行い、改善点や迅速なパフォーマンス向上を特定するのに役立つベンチマークを提案する場合にも使用。測定方法論には使用しない(→...)
developmentcode-review
golang-security
samber
Golangのセキュリティベストプラクティスと脆弱性防止。インジェクション(SQL、コマンド、XSS)、暗号化、ファイルシステムの安全性、ネットワークセキュリティ、クッキー、シークレット管理、メモリ安全性、ログ記録をカバー。Goコードのセキュリティに関する作成、レビュー、監査時、または暗号、I/O、シークレット管理、ユーザー入力処理、認証を含むリスクのあるコードに取り組む際に適用。セキュリティツールの設定を含む。
securitycode-reviewdevelopment
golang-database
samber
Goデータベースアクセスの包括的ガイド — パラメータ化クエリ、構造体スキャン、NULL許容カラム、トランザクション、分離レベル、SELECT FOR UPDATE、コネクションプール、バッチ処理、コンテキスト伝搬、マイグレーションツール。PostgreSQL、MariaDB、MySQL、SQLiteと連携するGolangコードの作成、レビュー、デバッグ時、データベーステスト時、またはdatabase/sql、sqlx、pgxに関する質問時に使用します。データベーススキーマやマイグレーションSQLは生成しません。
developmentdatabase
golang-lint
samber
GolangプロジェクトにおけるLintのベストプラクティスとgolangci-lintの設定 — リンターの実行、.golangci.ymlの設定、nolintディレクティブによる警告の抑制、Lint出力の解釈、リンターの選択。golangci-lintの設定時、Lint警告やnolint抑制について質問がある時、コード品質ツールのセットアップ時、またはリンターを選択する時に使用します。また、ユーザーがgolangci-lint、go vet、staticcheck、reviveに言及した場合にも使用します。
developmentcode-reviewtesting