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.