@acebuilder/component-tagger

Dev-only Next.js loader that injects data-acebuilder-* attributes on JSX elements for AceBuilder element selection.

Install

pnpm add -D @acebuilder/component-tagger

Usage

Wrap your Next config (injected automatically in AceBuilder sandboxes):

// next.config.mjs
import componentTagger from '@acebuilder/component-tagger'

/** @type {import('next').NextConfig} */
const nextConfig = {}

export default componentTagger()(nextConfig)

Bundler support

| Mode | Tagging | |------|---------| | next dev --turbopack (default in Next 16) | Build-time tagging via Turbopack loader rules | | next dev --webpack | Build-time tagging via webpack pre-loader | | next build | Build-time tagging (webpack) |

The tagger runs on all bundles — client, SSR, and RSC (server components). Structural ids (file.tsx@Component>div[0]>...) are deterministic, so server and client compiles emit identical data-acebuilder-* attributes: server-rendered HTML matches hydrated client output by construction (no hydration mismatches), and App Router server components carry selection ids too. suppressHydrationWarning remains as a safety net for mid-compile structural skew.

Turbopack rules omit the as field on *.tsx / *.jsx — including it caused broken module paths (welcome.tsx.tsx).

When merging into templates that already define turbopack.rules, the tagger emits explicit browser / { not: 'browser' } rule pairs (both carrying the tagger loader) so Next 16 accepts the config. AceBuilder sandboxes with complex pro-template turbopack configs still fall back to next dev --webpack as a safety net.

AceBuilder sandboxes

Platform deploy injects automatically:

• package.json devDependency: "@acebuilder/component-tagger": "latest"
• next.config wrapper via AST injection
• SDK <Script> in root layout

User templates stay unchanged.