JavaScript Function .wasm size ~doubles on @shopify/cli 4.4.0+ → exceeds 256KB, deploy fails with "Version couldn't be created"

Extensions
1

Hello,

Upgrading @shopify/cli from 4.2.0/4.3.0 to 4.4.0 or later roughly doubles the compiled dist/function.wasm size for JavaScript Functions — same source, no code changes. For a Function that was comfortably under the limit, this pushes it over Shopify’s hard 256KB cap, and shopify app deploy fails with the message: Version couldn’t be created.

Validation errors:
• base: Wasm file size must be less than 256KB

Reproduction (identical source, only the CLI version differs)

Function CLI 4.2.0 / 4.3.0 CLI 4.5.2
discount function 181 KB :white_check_mark: 367 KB :cross_mark: (deploy rejected)
rules-engine function 108 KB :white_check_mark: 204 KB

Both JS Functions ~2× on 4.5.x. Rust Functions and small JS Functions are affected proportionally; the increase looks like a larger embedded runtime baseline, independent of app code.

Likely cause:

CLI 4.4.0 shipped Shopify/cli#7871 — “Update Javy related dependencies” — which bumped the Functions build plugin shopify_functions_javy_v3.wasm → v4.wasm. Since Shopify Functions require a single self-contained (statically linked) WASM module, a larger embedded QuickJS runtime in that plugin inflates every JS Function’s output regardless of source. Nothing else between 4.2.0 and 4.4.0 touches Javy per the changelog. wasm_opt is already on by default and doesn’t offset it.

Question:

  1. Is the 4.4.0 Javy plugin size increase a known/expected regression, and is a smaller build planned
  2. For JS Functions near the 256KB cap on current CLI, is Rust migration the only path, or is there a supported way to reduce Javy output size (a build flag, dynamic linking, etc.)?

Thanks,

M

2

bumping @Liam-Shopify @Paige-Shopify can you assist here?

3
  1. Trim Unused GraphQL Input Fields :

Every field requested in run.graphql contributes to the generated GraphQL types and the runtime code used to deserialize the input. Review your query regularly and remove any fields that your function doesn’t consume. Keeping the input schema lean reduces generated code, helps decrease the JavaScript bundle size, and can also improve function execution efficiency.

  1. Consider Rust for Complex Functions :

If your function still approaches the WebAssembly size limit after optimizing your JavaScript or TypeScript code, consider implementing it in Rust. Rust compiles directly to WebAssembly without the JavaScript runtime overhead, typically producing significantly smaller binaries for the same business logic. This makes it a good choice for large rules engines, complex discount calculations, or validation logic that cannot comfortably fit within the JavaScript bundle size constraints.

  1. Stick to Cli 4.3

These three points are the initial steps that shall help.

4

Hi Shrutika,

Thank you for the response, but if you read the issue i am facing is only when i update the cli version to 4.5.2, the javascript is way below and fully optimized, check the comparison table for cli 4.3 and 4.5
Thanks,

M