Skip to content

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 #127

Description

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):

Section CLI 4.3.0 CLI 4.4.0+ Δ
data 119,594 462,006 +342,412 (3.9x)
custom (incl. javy_source) 18,724 18,724 0
code 182 182 0
import 113 113 0
export 93 93 0
all other sections identical identical 0

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 version Published javyPlugin javy (engine) functionRunner
4.2.0 2026-06-16 3 7.0.1 9.1.2
4.3.0 2026-06-23 3 7.0.1 9.1.2
4.4.0 2026-07-06 4 9.0.0 9.2.0
4.5.0 2026-07-13 4 9.0.0 9.2.0
4.5.1 2026-07-14 4 9.0.0 9.2.0
4.5.2 2026-07-17 4 9.0.0 9.2.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_v3shopify_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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions