Failed to fetch dynamically imported module

[azure knoll]

I am trying to build & run my Tanstack Start project with Docker.

Building & running works, but I immediately get a runtime error and a network error:
GET http://localhost:3000/assets/main-WtU-nrR_.js net::ERR_CONTENT_LENGTH_MISMATCH 200 (OK)
Uncaught (in promise) TypeError: Failed to fetch dynamically imported module: http://localhost:3000/assets/main-WtU-nrR_.js

I found another thread about this but nothing there helped: #1347600587012833402 message

Here's my vite.config.ts:

import { tanstackStart } from "@tanstack/react-start/plugin/vite";
import { defineConfig } from "vite";
import tsconfigPaths from "vite-tsconfig-paths";

const config = defineConfig({
  plugins: [
    tsconfigPaths(),
    tanstackStart({
      target: "node-server",
      tsr: {
        // @ts-expect-error - this is a config according to a runtime error I got with experimental.enableCodeSplitting
        autoCodeSplitting: true,
      },
    }),
  ],
});

export default config;

[sturdy nimbus]

does the file exist when you curl it?

[azure knoll]

Yes, but it shows errors too

[sturdy nimbus]

can you provide a complete example repo?

[azure knoll]

I tried to recreate a minimum repro, both by starting fresh and by copy pasting everything over and deleting what I thought was redundant.

However, the error doesn't appear there.
Any ideas what I could do to narrow it down? Could it be the size of the main bundle, which would explain why I can't reproduce it in a smaller repo?

Hold that thought. I might've just reproduced it. Will report back

Okay so what I'm doing which breaks it is to "find + sed" a value in the bundle before starting up, in Docker's ENTRYPOINT. We do this in order to make client side variables work via docker run -e xxx.

find . -type f ( -iname *.js -o -iname *.mjs -o -iname *.html ) -exec sed -i "s#REPLACE_ME_DOCKER_ENVIRONMENT#$VITE_NOONA_ENV#g" {} +

So in our case, there's a variable:
const dockerEnvironment = "REPLACE_ME_DOCKER_ENVIRONMENT";

Which the entrypoint script in theory should find in the code and replace with the runtime environment.

Not sure why this is causing issues though. We've btw been doing it like this in our Next.js and Expo Web apps for years.

I'll simplify the repro even further and link it.

[azure knoll]

@sturdy nimbus here's a repro.
https://github.com/gunnartorfis/tanstack-start-docker-runtime

Sorry about the turborepo complication.

Building:
docker build --file apps/web/Dockerfile -t tanstack-start-app .

Running:
./apps/web/docker-run.sh

[sturdy nimbus]

so you only know when starting the docker container what to put there?

[azure knoll]

Yeah, so we can reuse the docker image in different environments

[brittle sluice]

Could I ask the benefit of doing it this way vs. just using .env files?

[azure knoll]

Using .env files as in injecting an .env file that is created in the entrypoint.sh?

[brittle sluice]

Sure. I think Docker has first-party support for .env files and it's pretty easy to use to create your .env files. Then you can use those .env files during build processes in Vite for example

That way your file checksums and whatnot are correct. I typically dislike messing around with build files. Your changes should be done during the build process not post-build (using Vite etc..)

[azure knoll]

Ideally yeah, I have a workaround currently atm where we hard-code the environment during build time. But we'd ideally want to configure the .env on runtime, which I think would require us to mess around with the build files.

The use case is that we have a "DEV"/QA environment. Then each developer has their own environment via a Kubernetes namespace. The images on our DEV environment are used within each developer environment/namespace to reduce cost - building the same image for each dev would be pretty expensive. In this setup the image is the same except for the environment values.

[brittle sluice]

Yea, imo this definitely sounds like a build configuration thing and shouldn't be left to run-time. The problems you're facing are just a side effect of doing it the way you're doing it, and you'll run into more issues moving forward if you keep doing it this way. My recommendation is just figuring that out for build and everything should just work as expected.

Changing files after build also just completely messes up the checksum, and that's important in some scenarios (caching is a pretty important one that I can think of).