Bug report: Shopify CLI 4.4.0+ bumps Javy 7.0.1→9.0.0 (javyPlugin v3→v4), quadrupling compiled JS Function Wasm size past the 256KB limit

Start by reproducing the size difference with shopify app function build using CLI 4.3.0 and 4.4.0+, then compare dist/function.wasm sections and the published CLI bundle's toolchain version resolution table. Done means identifying a compatible toolchain change or mitigation so unchanged JavaScript Function extensions remain below the 256KB limit.

Summary

Upgrading Shopify CLI from 4.3.0 to 4.4.0 (and all subsequent 4.4.x/4.5.x releases) causes a previously passing JavaScript Function extension to fail shopify app function build / shopify app deploy with:

Wasm file size must be less than 256KB

The extension's source code is unchanged. The compiled .wasm grows from 138,762 bytes to 481,174 bytes (~3.5x) between CLI 4.3.0 and 4.4.0, with the entire size increase isolated to the module's data section, the section holding precompiled QuickJS bytecode under Javy's dynamic-linking model. Rust extensions do not face the same issue. JS seems to be extra vulnerable

Environment

• Extension type: JavaScript/TypeScript Shopify Function
• @shopify/shopify_function: 2.0.0
• api_version: 2026-04
• Extension build config: [extensions.build] command = "" (build is fully managed by the CLI; no local build script)
• Node: 26.3.1
• OS: Linux amd64
• Package manager: npm (global CLI install), autoupgrade disabled

Steps to reproduce

1. With Shopify CLI 4.3.0 installed, run shopify app function build on a JS Function extension. Note the output dist/function.wasm size.
2. Upgrade to Shopify CLI 4.4.0 (or later) with no changes to the extension source, package.json, or shopify.extension.toml.
3. Run shopify app function build again.
4. Compare the two .wasm files.

Expected behavior

Rebuilding identical source with a newer CLI patch/minor version should not meaningfully change the compiled Wasm size, and should not push a previously compliant module over the 256KB platform limit.

Actual behavior

=== function-4.3.0.wasm (CLI 4.3.0) ===
File size: 138,762 bytes (135.5 KB)
Imports: from 'shopify_functions_javy_v3': cabi_realloc, invoke, memory

=== function-4.4.0.wasm (CLI 4.4.0+) ===
File size: 481,174 bytes (469.9 KB)  -- OVER 256KB LIMIT
Imports: from 'shopify_functions_javy_v4': cabi_realloc, invoke, memory

Section by section breakdown of the two builds (byte identical source):

The javy_source custom section which embeds the original JS source is byte for byte identical between the two builds, confirming the source input is unchanged. Only the data section (precompiled QuickJS bytecode, produced by the Javy provider toolchain) grew.

Root cause (identified from the published CLI bundles)

Downloading the @shopify/cli npm tarballs for each version between 4.2.0 and 4.5.2 and inspecting the bundled toolchain version resolution table shows the following defaults change in CLI 4.4.0:

CLI 4.4.0 is the first release where the default javyPlugin moves from 3 to 4, alongside a Javy engine bump from 7.0.1 to 9.0.0 (a two major version jump). This lines up exactly with the shopify_functions_javy_v3 → shopify_functions_javy_v4 import change observed in the compiled module, and is the most likely source of the ~4x bytecode size increase, since a Javy major version bump commonly brings a QuickJS engine update with a different bytecode format/compilation strategy.

Impact

Any JS/TS Shopify Function extension already close to the 256KB budget will fail to build/deploy after an unattended CLI auto upgrade to 4.4.0+, with no code change on the developer's part and no clear signal in the build output pointing at the toolchain bump as the cause. Given CLI 4.0+ auto upgrades by default, this can silently break CI/production deploys.

Workaround

Pin Shopify CLI to 4.3.0 (last version with javyPlugin: 3 / javy: 7.0.1) and disable autoupgrade (shopify config autoupgrade off) until this is addressed.