@thefittingroom/shop-ui 5.0.12 → 5.0.18
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +141 -0
- package/dist/index.js +941 -331
- package/package.json +12 -3
package/README.md
ADDED
|
@@ -0,0 +1,141 @@
|
|
|
1
|
+
# shop-sdk-ui
|
|
2
|
+
|
|
3
|
+
The Fitting Room's browser SDK. A React/TypeScript ESM library that brands embed
|
|
4
|
+
on product pages to render virtual try-on, size recommendations, and avatar
|
|
5
|
+
creation flows. Authenticates against Firebase and talks to `tfr-backend`.
|
|
6
|
+
|
|
7
|
+
Distributed via npm and served to consumers through jsdelivr. The SDK registers
|
|
8
|
+
a `<tfr-widget>` custom element and exposes an `init()` entrypoint.
|
|
9
|
+
|
|
10
|
+
## Install
|
|
11
|
+
|
|
12
|
+
```sh
|
|
13
|
+
npm ci
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
## Scripts
|
|
17
|
+
|
|
18
|
+
| Script | What it does |
|
|
19
|
+
|---|---|
|
|
20
|
+
| `npm run build` | Clean + production build into `dist/` |
|
|
21
|
+
| `npm run check` | Type-check (`tsc --noEmit`) |
|
|
22
|
+
| `npm run watch` | Vite build in watch mode |
|
|
23
|
+
| `npm run serve` | Static-serve the repo on `:5173` with CORS |
|
|
24
|
+
| `npm run watch-serve` | Both `watch` and `serve` together; Ctrl+C stops both |
|
|
25
|
+
| `npm run gen-types` | Regenerate `src/api/gen/*.ts` from `tfr-backend` Go types |
|
|
26
|
+
| `npm run promote-latest [version]` | Move npm dist-tag `latest` onto a published version (defaults to current `package.json` version) |
|
|
27
|
+
|
|
28
|
+
## Release process
|
|
29
|
+
|
|
30
|
+
Releases are explicit, human-initiated steps via a single GitHub Actions
|
|
31
|
+
workflow. No magic on PR merges.
|
|
32
|
+
|
|
33
|
+
**1. Cut a `next` release.**
|
|
34
|
+
|
|
35
|
+
- Go to https://github.com/TheFittingRoom/shop-sdk-ui/actions/workflows/release.yaml
|
|
36
|
+
- Click **Run workflow**
|
|
37
|
+
- Pick the bump type (`patch` / `minor` / `major`)
|
|
38
|
+
- Click **Run workflow**
|
|
39
|
+
|
|
40
|
+
The `release.yaml` workflow does everything in one run:
|
|
41
|
+
|
|
42
|
+
1. Checks out `main`, installs deps, builds (verifies it compiles)
|
|
43
|
+
2. Runs `npm version <bump>` — bumps `package.json` and creates the
|
|
44
|
+
`vX.Y.Z` tag
|
|
45
|
+
3. Rebuilds with the new version embedded
|
|
46
|
+
4. Pushes the bump commit + tag back to `main`
|
|
47
|
+
5. Publishes to npm under dist-tag `next` via
|
|
48
|
+
[npm trusted publishing](https://docs.npmjs.com/trusted-publishers)
|
|
49
|
+
(OIDC, no long-lived secret) with `--provenance` for supply-chain
|
|
50
|
+
attestation
|
|
51
|
+
|
|
52
|
+
The npm trusted-publisher entry for `@thefittingroom/shop-ui` must
|
|
53
|
+
point at `release.yaml`.
|
|
54
|
+
|
|
55
|
+
> **Branch protection note:** the workflow pushes commits + tags
|
|
56
|
+
> directly to `main`. If you enable required-PR branch protection on
|
|
57
|
+
> `main` later, this push will fail until either (a) the workflow uses
|
|
58
|
+
> a credential listed in the branch-protection bypass list, or (b)
|
|
59
|
+
> branch protection allows the workflow to bypass via some other means.
|
|
60
|
+
> The current setup deliberately defers that complication.
|
|
61
|
+
|
|
62
|
+
**2. Promote `next` → `latest` when ready for end users.**
|
|
63
|
+
|
|
64
|
+
`release.yaml` only publishes under dist-tag `next`. To make a version
|
|
65
|
+
the default that consumers get from `npm install @thefittingroom/shop-ui`,
|
|
66
|
+
you have to explicitly promote it:
|
|
67
|
+
|
|
68
|
+
```sh
|
|
69
|
+
git pull origin main # ensure package.json reflects the latest release
|
|
70
|
+
npm run promote-latest # moves dist-tag latest onto current package.json version
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
That runs `npm dist-tag add @thefittingroom/shop-ui@<ver> latest` — no
|
|
74
|
+
new artifact is published; we just re-point `latest` at the already-
|
|
75
|
+
published `next` build. The runner needs to be logged in to npm with
|
|
76
|
+
publish rights to `@thefittingroom/shop-ui` (`npm whoami` to check;
|
|
77
|
+
`npm login` if not).
|
|
78
|
+
|
|
79
|
+
To promote a specific older version: `npm run promote-latest -- 5.0.13`.
|
|
80
|
+
|
|
81
|
+
**3. Verify** with `npm dist-tag ls @thefittingroom/shop-ui`.
|
|
82
|
+
|
|
83
|
+
## Local development
|
|
84
|
+
|
|
85
|
+
Run the SDK against the local backend stack from
|
|
86
|
+
[`local-deployment`](https://github.com/TheFittingRoom/local-deployment).
|
|
87
|
+
|
|
88
|
+
1. Bring up the local stack (Postgres, Redis, MinIO, `tfr-backend`):
|
|
89
|
+
|
|
90
|
+
```sh
|
|
91
|
+
cd /path/to/local-deployment && docker compose up -d
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
2. In this repo, start the watcher and dev server:
|
|
95
|
+
|
|
96
|
+
```sh
|
|
97
|
+
npm run watch-serve
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
This rebuilds `dist/index.js` on every file change and serves the repo at
|
|
101
|
+
`http://localhost:5173/dist/index.js` with CORS enabled.
|
|
102
|
+
|
|
103
|
+
3. Open the test storefront:
|
|
104
|
+
|
|
105
|
+
<https://tfrshop-1346.myshopify.com/products/blackbandana-fitted-dress?tfr-source=local>
|
|
106
|
+
|
|
107
|
+
The `?tfr-source=local` query param tells the storefront's `tfr.js` to load
|
|
108
|
+
the SDK from `http://localhost:5173/dist/index.js` instead of jsdelivr, and
|
|
109
|
+
to initialize it with `environment: 'local'` (see `src/lib/config.ts` —
|
|
110
|
+
that env points at `http://localhost:8080` for the API and the local
|
|
111
|
+
s3proxy bucket for assets at `http://localhost:9000`).
|
|
112
|
+
|
|
113
|
+
Reload the storefront page after a rebuild to pick up changes.
|
|
114
|
+
|
|
115
|
+
### Working with the storefront
|
|
116
|
+
|
|
117
|
+
The test storefront lives in the
|
|
118
|
+
[`shopify`](https://github.com/TheFittingRoom/shopify) theme repo. Its
|
|
119
|
+
`development` branch syncs to `tfrshop-1346.myshopify.com` automatically —
|
|
120
|
+
push to `origin/development` and the live demo store updates without any
|
|
121
|
+
`shopify theme push`.
|
|
122
|
+
|
|
123
|
+
The integration glue lives in three places in that repo:
|
|
124
|
+
|
|
125
|
+
- `assets/tfr.js` — bootstraps the SDK. Builds `currentProduct` from
|
|
126
|
+
`window.currentProduct` (set inline by `main-product.liquid`), wires the
|
|
127
|
+
`productLookup` and `getOverlayTopOffset` callbacks, and selects the SDK
|
|
128
|
+
source URL based on `?tfr-source=local`.
|
|
129
|
+
- `layout/theme.liquid` — loads `tfr.js` site-wide.
|
|
130
|
+
- `<tfr-widget>` embeds across `sections/main-product.liquid`,
|
|
131
|
+
`sections/header.liquid`, and `snippets/card-product.liquid`.
|
|
132
|
+
|
|
133
|
+
When iterating with `?tfr-source=local`, the SDK comes from your watcher
|
|
134
|
+
and the theme from the live demo store — you only need to push to
|
|
135
|
+
`shopify` when changing markup, the bootstrap script, or merchant
|
|
136
|
+
callbacks (`getSelectedOptions`, `addToCart`, `productLookup`,
|
|
137
|
+
`getOverlayTopOffset`). For SDK-only changes, just rebuild and reload.
|
|
138
|
+
|
|
139
|
+
If you're using `local-deployment`, both repos are cloned side-by-side
|
|
140
|
+
under `local-repo/` for you. See `local-repo/shopify/AGENTS.md` for the
|
|
141
|
+
theme conventions.
|