JavaScript and TypeScript in extensions

​

Template examples

​

javascript

npx extension@latest create my-extension --template=javascript

pnpx extension@latest create my-extension --template=javascript

yarn dlx extension@latest create my-extension --template=javascript

bunx extension@latest create my-extension --template=javascript

deno run -A npm:extension@latest create my-extension --template=javascript

​

content

npx extension@latest create my-extension --template=content

pnpx extension@latest create my-extension --template=content

yarn dlx extension@latest create my-extension --template=content

bunx extension@latest create my-extension --template=content

deno run -A npm:extension@latest create my-extension --template=content

​

JavaScript capabilities

​

Supported script entrypoints

​

Sample script declaration in manifest.json

{
  "manifest_version": 3,
  "name": "My Extension",
  "version": "1.0.0",
  "background": {
    "service_worker": "./scripts/background.ts"
  },
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["./scripts/content-script.ts"]
    }
  ]
}

​

Development behavior

• Content scripts: Extension.js injects hot module replacement (HMR)/remount flow for fast updates.
• Extension pages: Page scripts follow page HMR behavior.
• Background/service worker: Script updates can trigger a hard extension reload depending on the change type.
• Entrypoint list changes: Changing manifest script structure may require a dev server restart.

​

Script locations and conventions

• Use scripts/ at project root for script-centric extension entries.
• Use pages/ for HTML entrypoints with their own scripts.
• Keep manifest-referenced paths stable; avoid moving entry files without updating manifest.

​

Transform and bundling defaults

• SWC is the default transformer for JS/TS/JSX/TSX.
• Extension.js uses browser-first package.json field resolution (browser, module, main).
• Extension.js emits entries predictably and does not split code into separate output files by default.
• Path resolution rewrites static extension-path literals in supported APIs.

​

Dynamic import caveats

• Content-script dynamic import has runtime constraints; Extension.js uses loader fallbacks where possible.
• Service worker lazy-loading has browser limitations; prefer eager imports in code that must be available immediately when the service worker starts.

​

Best practices

• Keep entry scripts thin and move feature logic into shared modules.
• Prefer static import paths for extension APIs so path resolution can normalize them safely.
• Avoid unnecessary dynamic import in content scripts and service workers.
• Treat manifest script list edits as structural changes in development workflows.

​

Next steps

• Understand update outcomes in dev update behavior.
• Learn how to structure files with Special folders.
• Continue with background scripts and service workers.