Update function extension templates to API version 2026-04#394
Update function extension templates to API version 2026-04#394saga-dasgupta merged 3 commits intomainfrom
Conversation
eec1ca1 to
039b191
Compare
| EXT="schemagen-${ID//_/-}" | ||
| LINK="$APP_DIR/extensions/$EXT" | ||
| rm -rf "$LINK" | ||
| ln -s "$RS_DIR" "$LINK" | ||
| cleanup_list+=("$EXT") |
There was a problem hiding this comment.
Why do we need to do this in a separate directory with symlinks instead of just doing it inline?
There was a problem hiding this comment.
Because shopify app function schema walks up from its cwd looking for a shopify.app.toml, then uses that linked app's client_id to make an authenticated call to the Partners API and fetch the schema for the given api_version. So it has to be run from inside a directory that sits under a real linked app, not from this templates repo. The symlink is the cheap way to satisfy that constraint: we put a pointer to the template dir under <linked-app>/extensions/schemagen-* so the CLI can discover it as a function extension of the app, without copying source files around. When schema writes back to the extension dir, we copy the result into all three flavor folders in the repo and delete the symlink. Running inline would mean either (a) treating this repo as a Shopify app (which it isn't), or (b) authenticating against a dummy app and routing the request, both of which add more machinery than a one-line ln -s.
There was a problem hiding this comment.
Could we copy the shopify.app.toml to the root directory of this repo because it is .gitignored? Or do we consider that too potentially risky?
There was a problem hiding this comment.
It's actually what run-wasm-tests.sh does already, writing a stub shopify.app.toml at the root for test discovery. The issue is that shopify app function schema hits the Partners API, so it needs a real client_id a developer has org access to. That means each dev would do shopify app config link once inside this repo to drop their own gitignored shopify.app.toml which I think is a lot more friction than what I have in place right now. And then there's also the issue that the repo root becomes a linked Shopify app. Running something like shopify app deploy from the root would try to deploy every function template as a real extension. I like the solution I have in place more.
Shopify CLI now validates client_id, auth, webhooks, application_url, and embedded even when only used to discover extension directories.
Regenerates every function template's committed schema.graphql against the 2026-04 API version. The new schema adds a nullable `prerequisites: [ProductDiscountCandidatePrerequisite!]` field on ProductDiscountCandidate — added `prerequisites: None` to the Rust struct literal in functions-discount-rs and `"prerequisites": null` to the corresponding fixture's expectedOutput.
447fb93 to
0e5b2d7
Compare
|
Can we update the description based on the removal of the script? |
It already is updated. |
my bad, mixed up the |
Summary
api_versionfrom2026-01to2026-04in all 30 Functions extension templates (JS / RS / Wasm variants across cart-checkout-validation, cart-transform, delivery-customization, discount, fulfillment-constraints, location-rules, order-discounts, payment-customization, product-discounts, shipping-discounts).unstable(discounts-allocator, pickup-point-delivery-option-generators, local-pickup-delivery-option-generators) are intentionally untouched for the version bump, but theirschema.graphqlfiles are refreshed alongside everything else.schema.graphqlfor every function template against the new API version.prerequisites: None/"prerequisites": nullto the one Rust source file and one test fixture that constructProductDiscountCandidateliterals — the 2026-04 schema adds a nullableprerequisites: [ProductDiscountCandidatePrerequisite!]field, and Rust requires every struct field at init even when optional.cargo check --workspaceis clean after the fix.The helper script used to regenerate these schemas is in its own PR: #397.
CI fix: stub
shopify.app.tomlin.github/scripts/run-wasm-tests.shThe Wasm test job installs
@shopify/cli@latestand generates a minimalshopify.app.tomlso the CLI can discover extension directories forbuildFunction. Since PR #383 landed in March, the CLI's app-config validator tightened and now rejects the previous two-field stub with:The script now emits a full valid app config (dummy
client_id,application_url,embedded,[auth],[webhooks]) so validation passes. The values are placeholders — nothing is deployed; the toml only exists for extension discovery.Test plan
cargo check --workspacepasses afteryarn expand-liquid rust