@W-24044590 feat(mrt): add v2 bundle upload command - #646
Conversation
Add `b2c mrt bundle upload-v2` to build and upload a v2-format bundle
(gzip tar rooted under a configurable directory, with SSR config written
inside the archive at `{root-dir}/{config-path}`). This is upload-only;
deploy the returned bundle ID separately.
- New CLI command `mrt/bundle/upload-v2` and shared bundle-flag helpers.
- SDK: v2 archive creation (`createBundleV2`), push/bundle operations,
MRT client + spec updates, and a `matchMode` (strict|ignore_missing)
form field so the server enforces SSR pattern matching.
- Resolve SSR config from the on-disk v2 config file, else
`config.server.ts` (via jiti), else defaults; flags override per key.
- Record project package.json dependencies as bundle metadata.
- Reference/welcome apps: v2 deploy scripts and config.server updates.
- Docs, skills, and a changeset.
| // `if (error)` block. | ||
| const {status} = response; | ||
|
|
||
| if (error) { |
There was a problem hiding this comment.
@kieran-sf Can we guard this with (error || !response.ok)?
If the server returns a 403 with a completely empty body, it leaves the error undefined. Making it look like the upload succeeded
There was a problem hiding this comment.
Good catch — done in 4b2824e. Added the error || !response.ok guard.
One subtlety worth flagging: for a truly empty body openapi-fetch doesn't leave error undefined — it falls back to the raw text, so error ends up as ''. That's still falsy, so the original if (error) skipped it exactly as you described; !response.ok is what catches it. The thrown message now reports Failed to push bundle (HTTP 403): empty response body for that case, and I added a unit test (new HttpResponse(null, {status: 403})) covering it.
…-body failures A non-OK response with an empty body (e.g. a 403 with no payload) leaves `error` falsy — undefined or the empty string openapi-fetch falls back to when there's no JSON to parse. The previous `if (error)` guard let those fall through and surface as a misleading "upload succeeded but omitted a bundle id" error. Guard on `response.ok` as well and report "empty response body" when there's no detail. Addresses PR review feedback.
📘 Docs preview🧹 The preview for this PR has been removed (PR closed). |
|
The new library is already used in the storefront-next repo (jiti) for load typescript files. |
| "fuse.js": "7.1.0", | ||
| "glob": "catalog:", | ||
| "i18next": "25.7.4", | ||
| "jiti": "2.6.1", |
There was a problem hiding this comment.
Can you explain what this is for?
We already have runtime typescript support with tsx for supporting development. Is jiti necessary for runtime features like the config file loading?
EDIT: I see you added the note at the bottom of the summary and the SFNext comment above. So it is a runtime requirement. Approved, ideally we match SFNext's version spec for it.
There was a problem hiding this comment.
I can take a look at tsx and see if I can use that.
There was a problem hiding this comment.
No this is fine if storefront next is using it. That's a good enough reason to align
|
@kieran-sf Just to confirm: we definitely want this to be a unique command |
Yes the upload v1 needs to stay around because v2 isn't widely used yet so we want to keep v1 for backwards compatibility. V2 will be become the default once we start using the SCAPI API for MRT. |
Summary
Adds
b2c mrt bundle upload-v2— build and upload a v2-format bundle to Managed Runtime. This is upload-only; deploy the returned bundle ID separately withb2c mrt bundle deploy <bundleId> -e <env>. Work item: @W-24044590.mrt bundle upload-v2and shared bundle-flag helpers. The v2 archive is a gzip tar rooted under--root-dir(defaultbld/), with SSR configuration written inside the archive at{root-dir}/{config-path}(default.mrt/config.json) rather than sent as request fields.matchMode(strict|ignore_missing) form field so the server enforces SSR pattern matching.config.server.ts(evaluated from source via jiti), else defaults; flags override per key. Projectpackage.jsondependencies are recorded as bundle metadata.config.server.ts.Testing
upload-v2.test.ts) and SDK operations (bundle.test.ts,push.test.ts); the full suite passes apart from one unrelated, pre-existingoauth-commandconfig-isolation test that also fails onmain.bld/, in-archiveconfig.json),matchModehandling, and thatstrictmode rejects SSR patterns matching no files whileignore_missingaccepts them.Dependencies
Adds one net-new third-party dependency:
jiti(2.6.1) in@salesforce/b2c-tooling-sdk, used to evaluate a project'sconfig.server.tsfrom source when resolving SSR configuration. Flagged here for maintainer3pl-approvedreview.3pl-approvedis set by a maintainerpnpm test)pnpm run format)