Posthog/@cli doesn't rewrite nitro asset maps when mutating nitro chunk files for sourcemap injection

Bug Description

This is a weird one that's taken me a long time to track down, and unlikely to be able to give you solid reproduction easily.

In my repo when I was running into intermittent http serving errors of the built code. The only thing I could track it down to in my build pipeline is that after running npm run build on my repo, I followed it by the following posthog/@cli commands to inject the code to generate sourcemaps and upload them onto the server:

npm run build && \
npx @posthog/cli@latest sourcemap inject --directory /app/.output/public && \
npx @posthog/cli@latest sourcemap upload --directory /app/.output/public

But when looking at the http serving errors I had, the served file size was 420 bytes and the output content was truncated, but looking at the built files inside the container it should have been serving, this was 780 bytes on disk and no truncation of content.

The only thing I could finally track down to is the posthog/@cli obviously injects code into each built chunk so it can associate each chunk with the right sourcemap via the posthog cli call.

But nitro serves built files from it's own output/server/chunks/nitro/nitro.mjs script and this script caches the built assets and logs every file size, and etag (file hash) after the build step has completed as part of it's server build tools.

When serving any file nitro uses this file and the cached asset map within it to determine the size and etag of the file it serves up:

const assets = {
"/_nuxt/B3nvVOrL.js": {
    "type": "application/json",
    "etag": "\"74fa-VKz0d0mFbYGP22ECRFyNDEwAXEQ=\"",
    "mtime": "2026-04-22T21:18:39.023Z",
    "size": 420,
    "path": "../public/_nuxt/B3nvVOrL.js.map"
  },
}

It lists every served up built asset in here in this cached array.

But posthog/@cli sourcemap inject transforms every chunk to add it's own instrumentation code and comments, but crucially, it doesn't rewrite the nitro asset map so those cached file sizes and etags are no longer consistent. So, posthog/@cli rewrites the file contents (etag changes) and the file size (size changes), but nitro serves up the etag and file size in this cached asset map which no longer match the file size and contents, hence it serves a weirdly truncated file some times as it cuts off in my case at 420 bytes not the full 750 bytes of the newly mutated file (which was originally 420 bytes before posthog instrumentation). Doesn't happen to all my files served up by nitro but at least one and it feels like a weird edge case.

How to reproduce

1. build a starter vuejs/nuxt project which bundles in nitro
2. run npm run build and inspect the generated output/server/chunks/nitro/nitro.mjs asset map
3. run npx @posthog/cli@latest sourcemap inject --directory /app/.output/public
4. inspect the sizes of the chunk files where posthog added instrumentation
5. compare them to the sizes in the cached asset map - they will be wrong

Not sure if this is directly a posthog/@cli bug or a nitro bug, but it's a weird interaction with both since nitro assumes the post-build generated files won't be mutated and posthog/cli specifically mutates them afterwards, but doesn't complete this mutation across other dependent files, which is why I am reporting it here.

My temporary workaround is to add a build script in my build pipeline after posthog/@cli has mutated nitro chunk files, to rewrite the asset map in nitro.mjs, by re-inspecting the mutated chunk files sizes and generate new hashes to make new etags and rewrite the files sizes. Hopefully this fixes this issue s a temporary workaround.

Start by comparing the mutated files under /app/.output/public with the cached asset map in output/server/chunks/nitro/nitro.mjs after running the documented build and sourcemap inject commands. Trace whether @posthog/cli or Nitro owns the stale size and etag data; done means the affected asset metadata matches the post-injection files and the reported serving failure is covered by a reproducible check.