/commerce-react-storefront-create

name: commerce-react-storefront-create
description: "Stand up the commerce-b2b-headless reference React storefront in a Salesforce B2B Commerce org, end to end — discover the org's WebStores, pick one, fill the four org-specific values (WebStore Id, BuyerGroup Id, buyer permission set group, Vite org alias), build + deploy the UI Bundle, assign the site guest user the auth permission set, and hand back the live Experience Cloud storefront URL. Use whenever the user says \"create a react storefront in my org\", \"set up the headless B2B storefront\", \"deploy commerce-b2b-headless\", \"stand up a React storefront for <org-alias>\", \"get me a hosted headless commerce storefront\", or points at a cloned commerce-b2b-headless repo and wants it running against their org."
metadata:
  relatedSkills:
  - experience-ui-bundle-deploy
  version: "1.0"
  minApiVersion: "65.0"
  domains:
  - "Commerce"
  - "Experience"
  cliTools:
  - tool:
    - "git"
    semver: ">=2.0"
  - tool:
    - "jq"
    semver: ">=1.6.0"
  - tool:
    - "npm"
    semver: ">=8.0.0"
  - tool:
    - "sf"
    semver: ">=2.130.0"

create-react-storefront

What this does

Deploys the **commerce-b2b-headless** reference React storefront (a React 19 + Vite `UIBundle` served from the Experience Cloud Site Container) into a user's B2B Commerce org and returns the hosted storefront URL. The repo is a *reference implementation* — it ships four org-specific values as `<…_Placeholder>` strings that throw at runtime until replaced. This skill's whole job is to resolve those four values against the target org, then drive build → deploy → guest-user entitlement so the storefront actually renders.

The repo's `scripts/org-setup.mjs` (`npm run setup`) automates login → build → deploy → permset → dev-server, but it does **not** discover the WebStore, replace the placeholders, or entitle the site's guest user (the README's own "Limitations" say there is no auto-discovery). Those gaps are exactly the manual work below — do them, and the deploy is reliable.

**Requires:** Node 22+, `sf` CLI 2.130+, and a target org with B2B Commerce + Multi-framework React enabled (API version `67.0+`). Only work against orgs the user owns or is authorized to modify — deploy, Apex edits, and permission-set assignment are real, side-effecting writes.

Fixed facts about the repo (don't re-derive these)

| Thing | Value | |---|---| | Repo clone URL | `https://github.com/trailheadapps/commerce-b2b-headless.git` (ask for an existing clone first; a new clone goes to a user-confirmed path under the cwd — Step 3) | | UI Bundle dir (`$BUNDLE`) | `force-app/main/default/uiBundles/commerceb2bheadless` | | WebStore config file | `$BUNDLE/src/config/commerce.ts` | | Registration Apex | `UIBundleRegistration.cls` (in the repo's Apex classes folder) | | Vite config | `$BUNDLE/vite.config.ts` | | Auth permission set | `UIBundleApexAccess` (grants the 6 auth Apex classes) | | Site name | `commerceb2bheadless` — also the storefront URL path: `https://<site-domain>/commerceb2bheadless` | | Connect `urlPathPrefix` | `commerceb2bheadlessvforcesite` (internal match key for Step 7 — **not** the URL path) | | Default API version | `v67.0` (leave unless the org runs a different version) |

The four values you must set

Everything else in the repo is portable. These four are environment-specific — resolve each against the target org, then write it into the file. Steps 4a–4d below do this.

| # | Value | File / symbol | Prefix | |---|---|---|---| | 1 | WebStore Id | `commerce.ts` → `WEBSTORE_ID` | `0ZE` | | 2 | Default BuyerGroup Id | `UIBundleRegistration.cls` → `DEFAULT_BUYER_GROUP_ID` | `0ZI` | | 3 | Buyer permission set group | `UIBundleRegistration.cls` → `BUYER_PERMISSION_SET_GROUP` (DeveloperName) | — | | 4 | Vite org alias (optional) | `vite.config.ts` → `salesforce({ orgAlias: '…' })` | — |

---

Workflow

Narrow with `sf` queries before you ask the user anything, and don't ask what a query can answer. Two choices are always the user's to make, even when there is only one option: **which store** (Step 2) and **where the repo lives** (Step 3). Confirm the plan (which org, which store, what will be written and deployed) before the first write.

Step 1 — Resolve the target org

If the user gave an org alias, use it. Otherwise list what's connected and ask which one:

sf org list --json | jq -r '.result.nonScratchOrgs[]?.alias, .result.scratchOrgs[]?.alias'

Confirm it's reachable: `sf org display --target-org <alias>`. If not connected, log in: `sf org login web --alias <alias> --instance-url https://<my-domain>.my.salesforce.com`.

Step 2 — Discover the org's WebStores, let the user pick

sf data query --target-org <alias> \
  --query "SELECT Id, Name, Type FROM WebStore WHERE Type = 'B2B' ORDER BY Name"

The storefront is B2B-only, so list only `Type = 'B2B'` stores. **Always ask the user which store to deploy against — show every B2B store by Name and let them choose, even when there is only one. Never pick a store on the user's behalf**, and don't fold the choice into a later plan confirmation: the store decides which catalog, buyer groups, and pricing the deployed storefront serves. Capture the chosen store's `Id` (`0ZE…`); this is **value #1** and also scopes the BuyerGroup lookup in Step 4b. If the query returns nothing, the org has no B2B store provisioned — stop and point the user at the `b2b-commerce-org-setup` plugin to create one first.

Step 3 — Ask where the repo is, or clone it

**Ask the user first** — don't probe default locations or assume a path: do they already have a clone of `commerce-b2b-headless` (and where is it), or should you clone it from `https://github.com/trailheadapps/commerce-b2b-headless.git`?

**Existing clone** — set `$REPO` to the path the user gives, then verify it's the right repo:

ls "$REPO/README.md" "$REPO/force-app/main/default/uiBundles/commerceb2bheadless" >/dev/null && e