Docs

Quickstart ​

You want to go from nothing to a build you can hand to someone else. This walk does that: create, run, connect, build, share, publish.

1. Create an extension ​

This walk starts from a template. Two other lanes reach the same place: generate one from a description, or import a repository you already have.

bash
npx extension@latest create my-extension --template=init
cd my-extension

Or open extension.dev/new and choose a template there, which works signed out and creates the repository for you. The catalog at templates.extension.dev covers popups, sidebars, content scripts, and framework combinations. See Templates.

2. Run it locally ​

bash
npm run dev

The dev server launches a browser with the extension loaded and reloads it on every file change. This step is the Extension.js framework, documented at extension.js.org. Nothing has touched the platform yet.

3. Connect the project ​

Open extension.dev/new, sign in with GitHub, and choose the repository from the repo lane. The import analyzes the tree, finds the manifest, detects the browsers the extension declares, and infers a build command and output directory per browser.

See Import for what the analysis reads, Projects for what a project owns, and Workspaces for who can see it.

4. Build for every browser ​

Push a commit. The project builds one artifact per configured browser from that commit, in the project's managed build repository, and records the build under Builds in the console. Build minutes burn on the platform's org, never on yours.

Each build carries the commit it came from, the browsers it produced, and the integrity hash of every artifact, so a build can be verified later without trusting the console that served it.

5. Share the build ​

A build does not need to be released to be looked at. Publish a share link from the build in the console, or from an agent with the MCP server configured, call extension_preview_web with share: true. Either way the link renders the exact bytes of that build in a browser emulator. A link lives 30 days on either plan, and revoking one is permanent.

See Share an unpublished build for review.

6. Promote and publish ​

A new project has one release channel, preview, and every build lands there. stable always accepts a promotion, and any other channel is one you create. Promotion checks the build's environment stamp against the target channel's binding, see Environments and Promote gates.

When a build sits in stable, submit it to the stores from the project's Stores tab in the console, from an agent with extension_submit, or with POST /api/cli/stores/submit and a project token. Store credentials are held by the project, entered once in project settings. See Channels and Publishing.

When it fails ​

  • npm run dev errors before the platform is involved. That is the framework. Debug it with the docs at extension.js.org.
  • The project exists but shows no builds. Builds start on push. Push a commit, then watch Builds in the console.
  • A share link stopped opening. Links expire after 30 days. Share the same build again: an expired address is reused with a fresh window, so the link you already sent starts working rather than being replaced.
  • Promotion to stable is refused. The build's environment stamp does not match the channel's binding. Build for the target channel, then promote. See Promote gates.

Next ​