Experience UI Bundle Features Generate

UI Bundle Features

Install pre-built, tested feature packages into a Salesforce UI bundle with the @salesforce/ui-bundle-features CLI instead of hand-building them. This file is the framework-neutral workflow spine; the framework-specific detail — example file extensions, the files features rewrite, how a feature's entry component is mounted, and the build command — lives in a per-framework reference under <SKILL_DIR>/references/<framework>/.

Always check for an existing feature before building something from scratch. The CLI is framework-agnostic: it installs the framework-appropriate variant of each feature into the detected bundle. Authentication and search are the most commonly used today; run list --verbose for the full current catalog, since it can grow over time.

Ownership note: Agentforce AI conversation clients and file-upload are owned by separate skills (experience-ui-bundle-agentforce-client-generate, experience-ui-bundle-file-upload-generate). If the catalog also lists an Agentforce or file-upload entry, do not install it from both places — confirm with the user which delivery path they want, and never install the same capability twice in one bundle.

Package name: @salesforce/ui-bundle-features is the canonical package name. Some older templates/samples still reference the deprecated @salesforce/ui-bundle-features-experimental name — never use the -experimental suffix. If a command fails to resolve, confirm the published version with npm view @salesforce/ui-bundle-features version before assuming the package name is wrong.

Step 0: Determine the framework

<SKILL_DIR> = the absolute path to this skill's own directory (the folder holding this SKILL.md); resolve it from the skill path in context.

The framework is normally already decided by the calling context — passed down by the coordinator skill that invoked this one, or stated in the user's request. Use that.

The frameworks this skill supports are exactly the reference folders under <SKILL_DIR>/references/, each containing a features.md (so react → <SKILL_DIR>/references/react/features.md). This is the single source of truth — adding a framework means adding a reference folder, nothing here changes.

• If the framework is known — open <SKILL_DIR>/references/<framework>/features.md and keep it alongside this spine. It supplies the example extensions, the integration targets, the mount example, and the build command.

• If it is unknown (a standalone run where nobody said which) — run the deterministic detector on the UI bundle root before asking anyone:

  bash "<SKILL_DIR>/scripts/detect-framework.sh" "<path-to-uiBundles/<name>/ dir>"

  Branch on the exit code (do not parse prose):

  • react or angular (exit 0) → use that framework. Do not ask the user — detection is deterministic. Open <SKILL_DIR>/references/<framework>/features.md.
  • ambiguous (exit 2) → both frameworks present. List <SKILL_DIR>/references/ and ask the user which bundle to install into. If they name a framework with no matching reference folder, it is not supported here — stop.
  • unknown (exit 3) → no supported framework detected. Terminate. Report that neither React nor Angular signals were found in the bundle, so features cannot be installed, and stop. Do not guess.

Throughout the steps below, <framework> means the folder chosen here.

Workflow

1. Search project code first — check src/ for existing implementations before installing anything. Scope searches to src/ to avoid matching node_modules/ or dist/.

2. Search available features — use npx @salesforce/ui-bundle-features list with --search <query> to filter by keyword. Use --verbose for full descriptions.

3. Describe a feature — MANDATORY before wiring. Run npx @salesforce/ui-bundle-features describe <feature> and read the feature's README via npm view <package> readme (using the Package: name from that output) before wiring it. The README is the contract: it tells you how the feature is meant to be wired — including any drop-in entry component and the file each integration example belongs in. Cross-check against the copied-in source under describe's Copy Operations destination — that source (and its JSDoc/comments) is the version-matched truth for what's actually installed, in the detected framework's file types. Do not wire from assumptions about file names or component APIs. Skipping this is the most common reason a feature installs successfully but never actually runs.

4. Install — use npx @salesforce/ui-bundle-features install <feature> --ui-bundle-dir <name>. Key options:

   • --dry-run to preview changes
   • --yes for non-interactive mode (skips conflicts)
   • --on-conflict error to detect conflicts, then --conflict-resolution <file> to resolve them

   Install features before doing custom frontend/layout work in this bundle — features may rewrite the app layout and routing files (see the framework reference for their names), and installing after hand-built layout changes risks collisions.

If no matching feature is found, ask the user before building a custom implementation — a relevant feature may exist under a different name.

Conflict Handling

In non-interactive environments, use the two-pass approach:

1. Run install with --on-conflict error to detect conflicts without applying them.
2. Before writing the resolution file, read references/common/conflict-resolution-schema.json for the allowed keys and enum values.
3. Write a resolution file at <ui-bundle-dir>/conflict-resolution.json (path is relative to the UI bundle directory being installed into, not the repo root). Key it by the exact paths the CLI printed as conflicts in pass 1, verbatim:

   {
     "src/appLayout.tsx": "overwrite",
     "src/routes.tsx": "skip"
   }

   (The conflict paths are whatever the CLI printed for the detected framework — the keys above are illustrative.) Any conflicting path not listed defaults to skip — the CLI will not overwrite a file you didn't explicitly mark overwrite.
4. Re-run install with --conflict-resolution <path-to-that-file>.