Tanstack Start build size

[rossknudsen]

I've been trying to build an app using Tanstack Start, Powersync and publish it to Cloudflare Workers. However, I'm running into issues with the resulting build size being too big to release to CF. After looking at the build output, the culprit seems to be that the server build includes a bunch of wasm files that are required by the Powersync on the client. The source of these wasm files is the NPM package @journeyapps/wa-sqlite which the Tanstack installation guide specifies.

Now these wasm files are not required on the server, to my knowledge, since they are a dependency of Powersync which is intended to run on the client only (note, the wasm files are in the client and server build output). I've tried a number of different options to elimintate these wasm files from the server output but have failed. I'm not sure which component is the best place to start with this issue. I'm just assuming that the compiler is the best place to start.

To repro this issue, I grabbed a Powersync community maintained example and followed the Cloudflare deployment docs. Here is the result on my fork of the example. If you build this, you should find that the server build contains all of the wasm files as discussed above.

Any thoughts on where I'm going wrong?

[DucMinhNe]

The issue stems from how Vite / Vinxi traces and bundles imports during the SSR build pass (.output/server).

Even if your code checks typeof window !== 'undefined' or only mounts PowerSync inside a client component, having top-level static imports like import { PowerSyncDatabase } from '@powersync/web' causes the bundler to analyze and pull the transitive dependency @journeyapps/wa-sqlite (and its .wasm binaries) directly into the Cloudflare Worker server output bundle. Cloudflare Workers enforces a strict script size budget, and packaging SQLite WASM into the worker script itself quickly exceeds that limit.

To keep the server worker lightweight, here are the most effective ways to resolve it:

1. Dynamic import on the client (Recommended)

Avoid importing PowerSync or initializing the database at module scope in route files. Instead, load PowerSync lazily inside a client hook or <ClientOnly> component boundary:

import { useState, useEffect } from 'react';
import type { PowerSyncDatabase } from '@powersync/web';

let dbInstance: PowerSyncDatabase | null = null;

export function useClientPowerSync() {
  const [db, setDb] = useState<PowerSyncDatabase | null>(dbInstance);

  useEffect(() => {
    if (dbInstance) return;
    let isMounted = true;

    // Dynamic import ensures Vite excludes wa-sqlite and wasm from the SSR bundle
    import('./powersync-setup').then(async ({ initPowerSync }) => {
      const instance = await initPowerSync();
      dbInstance = instance;
      if (isMounted) setDb(instance);
    });

    return () => { isMounted = false; };
  }, []);

  return db;
}

Because import('./powersync-setup') is dynamic and only called inside useEffect, Vite's SSR pass leaves it out of the server entry graph, keeping wa-sqlite completely client-side.

2. Externalize in app.config.ts

If you have shared utilities or server functions that touch modules referencing @powersync/web, tell Vite to externalize @journeyapps/wa-sqlite during the SSR build:

// app.config.ts
import { defineConfig } from '@tanstack/start/config';

export default defineConfig({
  vite: {
    ssr: {
      external: ['@journeyapps/wa-sqlite', '@powersync/web'],
    },
  },
});

3. Verify Cloudflare Workers static asset configuration

Ensure that client WASM assets are served via Cloudflare Workers Static Assets rather than getting pulled into the worker execution context. In your wrangler.jsonc (or wrangler.toml), make sure assets points to the client distribution directory:

{
  "assets": {
    "directory": ".output/public"
  }
}

This serves the .wasm files from Cloudflare's asset CDN edge instead of loading them into worker memory.

[rossknudsen]

Hi @DucMinhNe,

Thanks for your detailed response, you definitely helped with my understanding of the situation. However, I'm having trouble implementing your solution. I've updated my repro with your changes and tried to remove all other code to isolate the problem. I added a GH Workflow to demonstrate the build issue, see the latest run here. The output from the run:

NOTE: as per the comment in workspace.tsx, when I remove the reference to useClientPowerSync from the file entirely, then the build doesn't incude the wasm files. So I'm interpreting this to mean that this is the sole place that determines if they are included or not.

Regarding externalizing the dependencies, I had to adjust the code you suggested to work with the repro codebase:

export default defineConfig({
  ...
  ssr: {
    external: ["@journeyapps/wa-sqlite", "@powersync/web"],
  }
});

But when I build this, I get an error specifically saying that this is not compatible with Cloudflare Vite plugin:

> tanstack-start-powersync-postgres-tanstack-db@ build ~\src\postgres-tanstack-db-starter
> vite build

error during build:
Error: The following environment options are incompatible with the Cloudflare Vite plugin:
        - "ssr" environment: `resolve.external`: ["@journeyapps/wa-sqlite","@powersync/web"]
To resolve this issue, avoid setting `resolve.external` in your Cloudflare Worker environments.

    at validateWorkerEnvironmentOptions (file:///~/src/postgres-tanstack-db-starter/node_modules/.pnpm/@cloudflare+vite-plugin@1.5_f4f65499ae1d94de87705204c410f096/node_modules/@cloudflare/vite-plugin/dist/index.mjs:69086:9)
...

The last suggestion builds, but doesn't seem to make a difference to the output at the moment. It might be more useful once other steps are working.

Your useClientPowerSync code looks like it could be production code? Maybe you could compare it to my implementation to see what I've missed?

[barry166]

I was able to reproduce this with the current example. The important detail is that this is not fixed by ClientOnly or by moving the call into useEffect: those change rendering/runtime, but Vite still emits the client-only dynamic-import branch during the SSR build.

With @cloudflare/vite-plugin@1.52.1, Vite 7.3.2, and Wrangler 4.123.0, the generated server output has no PowerSync entries in dist/server/.vite/manifest.json, and the server chunks do not reference PowerSync. Nevertheless, the Cloudflare-generated config uses:

"rules": [{ "type": "ESModule", "globs": ["**/*.js", "**/*.mjs"] }],
"no_bundle": true

That makes Wrangler scan every JS module under dist/server, including the orphan PowerSync worker files; their dynamic WASM imports then account for the ~7 MiB attachment. This is why SSR resolve.external is not a useful fix here (and the Cloudflare plugin rejects it).

A practical workaround is a post-build cleanup step that keeps dist/server/index.js, .vite/manifest.json, wrangler.json, and the files reachable from the server manifest/entry imports, then removes the remaining files under dist/server/assets. Keep the unmodified dist/client directory. In my reproduction, that removed the four SQLite WASM files and their worker/helper chunks from the server output while retaining the client copies. wrangler deploy --dry-run then went from:

• Total Upload: 9022.98 KiB / gzip: 3121.12 KiB
• to Total Upload: 1047.95 KiB / gzip: 175.15 KiB

The generated broad rule can remain when the orphan files are gone. I would not remove the rule entirely: with no_bundle: true, doing so also prevents the server's imported JS modules from being uploaded. This looks like a Cloudflare Vite-plugin/Wrangler output-pruning issue rather than a PowerSync schema or @journeyapps/wa-sqlite configuration issue.

[rossknudsen]

@barry166 thanks for the detailed breakdown and actually running the repro at your end. I had a look at dist/server/.vite/manifest.json and walked back through each of the commits I made in the repro and can see how manifest changes in response to the code changes. I can see how @DucMinhNe's suggestions make the build work correctly and it seems to go wrong with the Wrangler output as you have noted.

I also had AI generate a script to recursively walk through the imports and output a visual. It is helpful to see the changes also. I guess there might be existing tools that can be used to achieve the same thing.

I should raise an issue with Cloudflare to see if they can fix the underlying issue and in the meantime I guess I'll write a post-build script to patch the output as suggested.

[rossknudsen]

Actually found a recent open issue that seems to match this behaviour:
cloudflare/workers-sdk#14972