Files
Alejandro Gutiérrez 3527e732d4 feat: turbostarter boilerplate
Production-ready Next.js boilerplate with:
- Runtime env validation (fail-fast on missing vars)
- Feature-gated config (S3, Stripe, email, OAuth)
- Docker + Coolify deployment pipeline
- PostgreSQL + pgvector, MinIO S3, Better Auth
- TypeScript strict mode (no ignoreBuildErrors)
- i18n (en/es), AI modules, billing, monitoring

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-04 01:01:55 +01:00

4.9 KiB

title, description, url
title description url
Manifest Learn how to configure the manifest of your extension. /docs/extension/configuration/manifest

Manifest

As a requirement from web stores, every extension must have a manifest.json file in its root directory that lists important information about the structure and behavior of that extension.

It's a JSON file that contains metadata about the extension, such as its name, version, and permissions.

You can read more about it in the official documentation.

Where is the manifest.json file?

WXT abstracts away the manifest file. The framework generates the manifest under the hood based on your source files and configurations you export from your code, similar to how Next.js abstracts page routing and SSG with the file system and page components.

That way, you don't have to manually create the manifest.json file and worry about correctly setting all the fields.

Most of the common properties are taken from the package.json and wxt.config.ts files:

Manifest Field Abstractions
icons Auto generated with the icon.png in the /assets directory
action, browser_actions Popup window
options_ui Options page
content_scripts Content scripts
background Background service worker
version set by the version field in package.json
name set by the name field in wxt.config.ts
description set by the description field in wxt.config.ts
author set by the author field in wxt.config.ts
homepage_url set by the homepage field in wxt.config.ts

WXT build process centralizes common metadata and resolves any static file references (such as popup, background, content scripts, and so on) automatically.

This enables you to focus on the metadata that matters, such as name, description, OAuth, and so on.

Overriding manifest

Sometimes, you want to override the default manifest fields (e.g. because you need to add a new permission that is required for your extension to work).

You'll need to modify your project's wxt.config.ts like so:

export default defineConfig({
  manifest: {
    permissions: ["activeTab"],
  },
});

Then, your settings will be merged with the settings auto-generated by WXT.

Environment variables

You can use environment variables inside the manifest overrides:

export default defineConfig({
  manifest: {
    browser_specific_settings: {
      gecko: {
        id: import.meta.env.VITE_FIREFOX_EXT_ID,
      },
    },
  },
});

If the environment variable could not be found, the field will be removed completely from the manifest.

Locales

TurboStarter extension supports extension localization out-of-the-box. You can customize e.g. your extension's name and description based on the language of the user's browser.

Locales are defined in the /public/_locales directory. The directory should contain a messages.json file for each language you want to support (e.g. /public/_locales/en/messages.json and /public/_locales/es/messages.json).

By default, the first locale alphabetically available is used as default. However, you can specify a default_locale in your manifest like so:

export default defineConfig({
  manifest: {
    default_locale: "en",
  },
});

To reference a locale string inside your manifest overrides, wrap the key inside __MSG_<key>__:

export default defineConfig({
  manifest: {
    name: "__MSG_extensionName__",
    description: "__MSG_extensionDescription__",
  },
});

Apart of this, we also configure in-extension internationalization out-of-the-box to easily translate your components and views.