#Implementation guide

Build browser-extension features with the Extension.js runtime model in mind, not just the bundler model.

This section explains the contracts that matter when you are authoring real extension features: what manifest.json controls, which entrypoints Extension.js rewrites, where special folders fit, which behaviors are safe for automation, and where browser-extension constraints still apply even when the build pipeline is helping.

#Start by need

#What this section focuses on

• Authoring contracts that are easy to miss from CLI docs alone.
• Source-backed runtime behavior that affects how your extension loads and reloads.
• Browser-extension architecture concerns that still matter after bundling, such as permissions, messaging, storage, and context boundaries.
• Practical guidance for both human developers and automation agents.

#Important mental model

Extension.js helps with compilation, path normalization, manifest rewriting, and development ergonomics. It does not remove the underlying browser-extension boundaries:

• Content scripts still run with page-context constraints.
• Background service workers still have lifecycle limitations.
• Web-accessible resources still need explicit exposure.
• Permissions still determine what the extension is allowed to do.
• Messaging and storage still need explicit design.

#Good reading order for a new feature

1. Start with manifest.json to understand the extension surface you are declaring.
2. Read the feature-specific page, such as content scripts or background.
3. Add supporting pieces: permissions, messaging, storage, and web accessible resources.
4. Validate path assumptions in Predictable path resolution.
5. Review Dev update behavior before changing entrypoints during active watch mode.

#Next steps

• Start with manifest.json.
• Build page integrations with Content scripts.
• Review runtime boundaries in Security checklist.