DEV Community: operix

`npx wix release` does not build: how we shipped yesterday's `dist/` by mistake

operix — Fri, 06 Nov 2026 01:08:43 +0000

Wix CLI, September to November 2026, measured on three of our own apps. CLI behaviour may change.

npx wix release uploads whatever is in dist/ and creates a version. It doesn't run your build. If that sentence is obvious to you, the rest of this post is about how to prove what actually went live, which turned out to be less obvious than it sounds.

What happened

On 2026-09-19 we fixed a dashboard bug in our calendar app, ran the test suite (green, type check included), and released:

npx wix release -t minor -c "..."
...
Uploaded successfully
Preview created
Version 2.17.0 was created

There is no build step in that log. We didn't notice. We opened the dashboard to confirm the fix and saw the old behaviour.

To rule out a cache, we downloaded the bundle from the new deployment host and compared it with the local dist/:

cmp /tmp/live-wrapper.js dist/<path>/wrapper.CeNtilzv.js && echo identical

Identical, byte for byte. The local dist/ was from the previous evening at 20:22, before the fix. npm run build changed the chunk hash from wrapper.CeNtilzv.js to wrapper.5MoEAcz1.js, and version 2.18.0 carried the fix. We burned a version number, no merchant was affected, and we've kept one rule since: test, build, release, in that order.

Why it is easy to miss

The release output looks complete. "Uploaded successfully" reads like "built and uploaded". And a stale dist/ is a perfectly valid artifact: it uploads fine, the version is created, the dashboard loads. Nothing fails. The only symptom is that your change is not there, and the first explanation that comes to mind is a cache.

How to prove what is live

We nearly fooled ourselves twice while checking 2.17.0, so here is the checklist we use now.

Step 1, find the current deployment host. Every release gets a new host, <prefix>-<app-slug>.wix-host.com. The dashboard runs on the latest deployment the moment the release completes, so the first segment of the dashboard iframe's hostname is the current prefix. Old hosts stay online and keep answering 200 for their old assets, so measuring against an old prefix will say "nothing changed" for ever. Our first attempt took two prefixes from .wix/debug.log. Both were dead and returned 500 for everything.

Step 2, use a control group. On the host you believe is current, request three things: a path that does not exist, the old bundle filename, and the new bundle filename.

Request on the current host	Expected
a path that does not exist	500
old chunk `wrapper.CeNtilzv.js`	500
new chunk `wrapper.5MoEAcz1.js`	200

If all three are 500, your host is wrong, not your release. Without that first row, a 500 for the old bundle looks like proof the new code is live. It isn't, and we were one step from writing that down.

Step 3, don't grep -c a minified bundle. It is one line, so the count is 0 or 1. We read a "1" as "the new string is in there". grep -o '<string>' bundle.js | wc -l on the same file said 0. The most reliable check is cmp against your local dist/.

Step 4, ship a build stamp. Our build now writes its timestamp into a static file under public/, which each deployment host serves at /_wix/extensions/public/build. Comparing a host with your local build becomes one request. We still run cmp on the bundle for anything that matters.

Running it from a script

wix release draws an interactive UI. From a non-interactive shell it dies with a raw-mode error (NonInteractiveTerminal, or a complaint about isRawModeSupported) and creates no version, which is at least a clean failure. Two flags are both required to make it non-interactive: --version-type and --comment. With only -t minor it still stops at the comment prompt.

From a plain bash with no TTY we wrap it in script:

npm test && npm run build && \
script -q /tmp/release.txt npx wix release -t minor -c "What changed, in one line" < /dev/null > /dev/null 2>&1
tr -d '\r' < /tmp/release.txt | grep -E 'Version .* was created'

Two things we hit. Piping the output to tail shows nothing until the process exits, so you cannot tell "stuck" from "working"; read the typescript file instead. And --version-type accepts only major and minor. Passing patch is rejected with argument 'patch' is invalid. Allowed choices are major, minor. Every fix is therefore a minor bump, and after a 2.0.0 the next minor is 2.1.0, not 2.0.1.

Our release scripts also check that HEAD is the intended commit and the working tree is clean before calling release, tee the output into a dated report file, and grep for the "was created" line. Every call to wix release creates a version. If the line is missing, read the Versions page in the Dev Center before running it again.

What deploys without a release, and what needs one

Backend event handlers deploy immediately, independent of the version you release. The CLI prints a warning about this, and the warning is accurate.
Listing descriptions need a release to reach the published listing. On 2026-10-16 we edited the description and the pricing-benefit lines of one app and clicked "Update Market Listing". The benefit lines went live at once; the description stayed old in the published record, and the version indicator kept saying "Up to date". A wix release -t minor with unchanged code pushed the new description to all nine languages within seconds.
Pricing edits can lock releases. On 2026-10-12 a change to a plan's benefit text put the app into "App submitted for review", and wix release failed with Failed Precondition … App with app id '…' is not editable for more than two days. A later pricing edit on another app did not trigger the lock. We don't know what decides it; we just finish code releases before touching pricing fields.
wix preview lets you look before you create a version. npm run build && npx wix preview prints a versionOverrideId. Open the dashboard with ?apps-override=<that id> to see the build without releasing.

Where it still bites

The upload is only the start. For storefront widgets, visitors receive the new deployment when Wix next renders their page, and that render can be cached for hours (we have measured up to 35; that is a separate post). Verify with a cache-busting query on your own site, then cmp.
Tests that look at dist/ test the dist/ you have. Some of ours scan the build output for secret names and absolute local paths. Run those after the build, or a green run is reporting on yesterday's artifact.
Our build does more than wix build. It also strips absolute local paths out of dist/ before anything is uploaded. If you add steps like that, wix release will not run them for you either.

The whole lesson fits in one line of a shell script: put the build in the script, because the release command won't do it for you.

Written by a backend engineer with ten years of experience, building small Wix and Shopify apps as operix.

The calendar app from the 2.17.0 story is on the Wix App Market: https://www.wix.com/app-market/a5d62bae-8405-4635-a985-8743d9ad50d7?utm_source=blog&utm_medium=article&utm_campaign=wix-release-does-not-build

Your Wix widget loads from whichever deployment rendered the page, and that render can be cached for 35 hours

operix — Fri, 06 Nov 2026 01:06:38 +0000

Observed September to November 2026 on apps built with the Wix CLI. This is platform behaviour we measured from the outside, not a documented contract. It may change.

If you build Wix apps with the CLI, every npx wix release creates a new deployment. Your dashboard page picks it up immediately. Your storefront widget, the custom element merchants drop onto their pages, often doesn't. For a week we believed merchants had to republish their sites to receive a widget fix. That was wrong, and the real mechanism is more useful to know.

What we measured

Each release of a CLI app gets a new static host of the form <prefix>-<app-slug>.wix-host.com. The prefix changes on every release. Old deployments stay online.

On 2026-09-23 we released version 1.63.0 of our search widget and, twenty minutes later, ran a read-only census over the external sites that had it installed. We found the widget on 31 published home pages. Nine of them already referenced the new prefix. Nine merchants do not republish within twenty minutes of a release they know nothing about, so "republish to receive the update" could not be the rule.

We then fetched three of the sites that still referenced old prefixes, twice each: once plainly, once with a random query string.

Request	`server-timing`	`age` (seconds)	Prefix in HTML
plain GET, site A	`cache;desc=hit`	24,582 (about 6.8 h)	old
plain GET, site B	`cache;desc=hit`	50,198 (about 13.9 h)	old
plain GET, site C	`cache;desc=hit`	125,021 (about 34.7 h)	old
same URL + `?nocache=<random>`, all three	`cache;desc=miss`	none	current (1.63.0)

So the widget's script host is not baked into the page when the merchant publishes. Wix inserts the deployment that is current when it renders the page, and the rendered HTML is then served from a cache. The oldest cached render we have seen was 125,021 seconds old, a little under 35 hours. We haven't found a documented TTL, and we've seen much shorter ones: on our own development sites the HTML switched to a new prefix within 2 to 4 minutes.

Two months later the picture was the same at a larger scale. On 2026-11-03, about an hour after a release of our calendar widget, we fetched the home page of 126 external sites that run it. They referenced eight different deployments of the same app on the same afternoon. The distribution was 50, 38, 22, 8, 3, 2, 2 and 1 sites per deployment. The release from an hour earlier was on two of them.

Why we got it wrong first

On 2026-09-18, right after a release, we checked one live site: old prefix. We published that site from the editor: new prefix. We wrote down "widgets update when the merchant republishes." Three days later, right after another release, two sites served two different old bundles, and then both switched to the new one within minutes while nobody touched them. The lesson for us: one read of a cached page right after a change doesn't tell you the rule. We should have read it again a few hours later and looked at the headers.

How to reproduce it on your own app

You need a published site with your widget on it and the slug part of your app host.

# 1. Which deployment does the cached render reference, and how old is it?
curl -sD - -o /tmp/page.html 'https://<a-site-with-your-widget>/' \
  | grep -iE '^(age|server-timing):'
grep -oE '[a-z0-9]+-<your-app-slug>\.wix-host\.com' /tmp/page.html | sort -u

# 2. Force a fresh render by changing the URL
curl -sD - -o /tmp/fresh.html "https://<a-site-with-your-widget>/?nocache=$RANDOM$RANDOM" \
  | grep -iE '^(age|server-timing):'
grep -oE '[a-z0-9]+-<your-app-slug>\.wix-host\.com' /tmp/fresh.html | sort -u

If step 1 shows cache;desc=hit, a large age and an old prefix, and step 2 shows cache;desc=miss and the prefix of your latest release, you are looking at the same mechanism.

To learn which prefix is current without a browser, fetch a fresh render of your own test site the same way. If you prefer the dashboard, the first segment of the hostname of your app's dashboard iframe is the current prefix, because the dashboard always runs on the latest deployment:

[...new Set([...document.querySelectorAll('iframe')].map(f => {
  try { const h = new URL(f.src).hostname; return h.includes('wix-host') ? h.split('-')[0] : null; }
  catch { return null; }
}))].filter(Boolean)

One thing to watch: the hashed chunk filenames inside the bundle are resolved by Wix's loader at run time and are not in the HTML. To see which chunk a visitor actually loaded, use performance.getEntriesByType('resource') in the page.

What we changed

We stopped telling merchants to republish. Our dashboard used to say the site had to be "published again." It now says: Your site's cached pages still load the older version. Wix refreshes them on its own over time; publishing the site refreshes them right away. That one is true. The old one asked merchants to do work because we had misread a cache.

We also compare prefixes now, and we allow "unknown". The dashboard fetches the merchant's published home page (and, if the widget is not there, a few pages listed in the sitemap), extracts our prefix, and compares it with the prefix the dashboard itself is running from. On the client that is new URL(import.meta.url).origin. Don't use the server's Host header for this; on Wix hosting it is not the public host. The result is tri-state: current, stale, or unknown when either side could not be read. A wrong "stale" sends a merchant off to republish for nothing, and a wrong "current" hides a fix that never arrived, so when we can't read one side we'd rather show nothing.

We ship a build stamp. The build now writes its timestamp into a static file under public/, so every deployment host answers GET /_wix/extensions/public/build with its own build time. Comparing two deployments no longer means diffing minified bundles. A small script fetches each known site's home page, collects the prefixes, probes each prefix's build stamp, and prints a histogram. That is where the "eight deployments across 126 sites" number came from.

Another thing we stopped doing: storing a deployment host anywhere. A GitHub Actions cron of ours called our server through a repository variable that held a host. Over four days and five releases it kept running a stale build, while we believed a server fix was live for every merchant. The host is now resolved at run time.

And we verify releases with a cache-busting fetch. After each release we open our own site with a fresh query string and compare the served bundle with the local dist/ byte for byte, using cmp. Opening the page plainly and seeing the old bundle is not evidence that the release failed.

What still trips us up

Cart and checkout plugins behave differently. For the site plugin slots (cart, checkout), republishing alone did not change the bundle. The host changed only after the merchant updated the app through the app installer and then published again (measured 2026-09-22). Those slots appear to pin the app version into the published site.
The query-string trick is not guaranteed. One of our test sites kept serving the previous day's build even with ?nocache=. Publishing from the editor refreshed it. We don't know what made that cache stickier.
Prefix is not version. A site that had installed major version 2 of our calendar served a deployment host from the version 3 line. The host tells you which build served the file. What the widget then does depends on your own code paths, not on the host. Don't read "new prefix" as "this merchant is on the new major".
The browser has its own cache. Even after Wix re-renders, your browser may hold the old page. Add a query parameter when you check.
Old hosts answer 200 forever. If you measure against an old prefix you'll keep seeing "nothing changed", for as long as you like.

So this is how we think about it now: a widget release reaches a visitor when Wix next renders that page, which depends on the site's cache and not on anything the merchant did. We plan our checks around that, and we wrote the dashboard text around it too.

Written by a backend engineer with ten years of experience, building small Wix and Shopify apps as operix.

The calendar widget whose 126-site spread appears above is on the Wix App Market: https://www.wix.com/app-market/a5d62bae-8405-4635-a985-8743d9ad50d7?utm_source=blog&utm_medium=article&utm_campaign=wix-widget-cached-render-35h