Tanstack Start: Asset hash mismatch between client and server-side (SSR) assets in Dockerfile build

[58bits]

I thought I'd post this here, as I'm not sure whether this is Tanstack Start issue or a Vite issue, or something we're doing wrong.

I've made the repo to reproduce the problem below public - which can be found here...

https://github.com/Modulus-Learning/registry

It's a fairly simple Tanstack Start project that we started from the basic example. There are no secrets required.

pnpm install, pnpm build, pnpm start - is all that's required to install and run the project locally.

The problem is that when trying to build our Dockerfile (in _docker/web/production/Dockerfile) for this project, we get a mismatch in asset hash names between a 'real' asset in...

.output/public/assets/global-DOuTEoU0.css

And the entry that is placed in the ssr chunk in...

.output/server/chunks/_/ssr.mjs

In the Docker container - the entry for appCss in .output/server/chunks/_/ssr.mjs is...

const appCss = "/assets/global-KecCYkUG.css"; - which does NOT exist in the assets directory.

However, in all local builds it is and should be:

const appCss = "/assets/global-DOuTEoU0.css"; - which DOES exist in the assets directory.

If we manually shell into the running container and edit the ssr.mjs file - and change the const appCss = "/assets/global-KecCYkUG.css"; to point to const appCss = "/assets/global-DOuTEoU0.css"; - and then restart the container, everything is fine.

We've spend a full day working on this and have tried:

1. Ubuntu base image in Dockerfile builds instead of Alpine
2. All-in-one single stage Dockerfile builds instead of multistage
3. Updated vite.config.ts with diagnostic rollupOptions so that we can see the source base filenames for CSS files.
4. As described above - shell'ing into the running container and updating the entry for const appCss in ssr.mjs
5. We've just tried using npm for the build and run, and the same problem occurs.

The Dockerfile can be built from the root of the project by calling:

./_docker/build-prod.sh

followed by...

./_docker/exec-prod.sh up

.. to start the container.

you can shell into the running Docker container via:

docker exec -it modulus_registry_app sh

Does anyone out there have any ideas? Thoughts or suggestions greatly appreciated.

[58bits]

We've also just tried using npm, instead of pnpm inside the container build and run, and while the hash values are different, the exact same problem occurs - const appCss in .output/server/chunks/_/ssr.mjs is pointing to an asset that doesn't exist in the assets folder. So this is not an pnpm or pnpm symlink problem.
@tannerlinsley ¯_(ツ)_/¯

[58bits]

We've also just tried this with the simplest possible Dockerfile...

# Stage 1: Build the application
FROM node:lts-alpine AS builder
#FROM node:20-alpine AS builder
WORKDIR /app

# Copy package files and install dependencies
COPY package*.json ./
RUN npm install

# Copy the rest of the application source code
COPY . .

# Build the application
RUN npm run build

# Stage 2: Create the production image
FROM node:lts-alpine
# FROM node:20-alpine
WORKDIR /app

# Copy package files and install only production dependencies
COPY package*.json ./
RUN npm install --omit=dev

# Copy the built application from the builder stage
COPY --from=builder /app/.output ./.output

# Expose the port the app runs on
EXPOSE 3000

# The command to run the application
CMD ["npm", "start"]

And are still seeing the same mismatch between the client asset for the global stylesheet and the entry in ssr.mjs.

I've placed this test Dockerfile, and docker-compose.yml as well as steps to build and run in Dockerfile-test.txt in the root of the project.

Completely stumped as this application builds fine, with all asset hashes and start all working fine on a local machine (i.e. without Docker).

[58bits]

Have just tried updating our tailwind.css file with an @source directive as suggested by @schiller-manuel - but so far this hasn't worked. Will experiment further.

[58bits]

Hi @schiller-manuel - I've tried what I think were most path depth and source combinations but am still receiving the same error when attempting to start our Docker container. Any advice or suggestions greatly appreciated. If you think this would be better as an issue then I'd be glad to raise one.

[schiller-manuel]

please create an issue including a complete minimal example that reproduces this. although this is most likely not a start issue but a tailwind one, but who knows.

[58bits]

Okay will do.

[58bits]

Moved to this issue here... #4959