cli: Nuxt 3.7+ : net::ERR_CONTENT_LENGTH_MISMATCH with VS Code Devcontainer

Waouuu… I was using Nuxt3 for a project for a while with devcontainers, and it was painfully slow (compared to Nuxt2), with a initial load time (under Chrome) often over a minute (worse than @max06), but I never found anyone speaking directly of this issue, and did with it.

I recently had lot more ERR_CONTENT_LENGTH_MISMATCH errors (after upgrading Nuxt and all dependencies), and the dev was impossible. I added the --no-fork option to the dev command. The website is now loaded in less that 5 seconds, and the err content length mismatch disappeared! After a while dealing with this long loading time, it feels like magic 🧙‍♂️!

Hi, I had the same issue as @marcotuna and it turned out that the problem was VSCode port forwarding. Forwarding the port with my ssh config solved it

@leo-hardy yeah, I confirmed that worked as well. my workaround was to use the --no-fork flag on dev command.

fwiw, this is my working .devcontainer/devcontainer.json. The result is the same for nvm/volta/npm, I only switched to bun for troubleshooting.

{
  "name": "Node.js & TypeScript",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:1-20-bookworm", // bookworm is the aarm64 version of the image
  "features": {
    "ghcr.io/devcontainers/features/docker-in-docker:2": {},
  },

  "forwardPorts": [3000],
  "postCreateCommand": "bash -i -c 'curl -fsSL https://bun.sh/install | bash && source ~/.bashrc && bun i && bun dev'",
  "postStartCommand": "bash -i -c 'bun dev'",
  "customizations": {
    "vscode": {
      "extensions": [
        "Vue.vscode-typescript-vue-plugin",
        "Vue.volar",
        "bradlc.vscode-tailwindcss"
      ]
    }
  },

}

edit: this was running nuxt 3.10.0 btw

Hi again. Sorry hearing you still have issues with DevContainers. It is something we should investigate and fix for CLI proxy.

In the meantime, have you tried with nuxt dev --no-fork? It might fix possible issues.

we’ve given up on .devcontainer for now.

@or2e just curiosity: why not keep devcontainers and stick to Nuxt 3.6.5 in the meantime? Dev containers are so important to me, that I’ll prefer go to React if never solved 😃

As it still works with nuxt 3.6,

It took a while to process this bit… do you mean nuxt 3.6 works fine with the current vscode release?

Hey @pi0 - how’s the change for --no-fork going? I forget about that switch most of the times… 😅

Hi there! Same issue with nuxt 3.8.0 unfortunately. Any progression on this?

Is there anything I can do/try to help debugging? Thanks for your help @pi0

No worries, I’m here to help as much as I can. And I seem to attract bugs whenever I touch something 😅

I probably should have mentioned my docker containers are ipv6 enabled. However I’m totally fine if everything inside docker uses ipv4.

And before I forget it: Thank you very much for your quick fix!

With both flags, both issues disappear (for me).

Compared to

(for once without failed requests)

Browser cache doesn’t seem to make a big difference at all, maybe 20% on the loading time.

can you please try with --no-fork --host 127.0.0.1?

I don’t have the ERR_CONTENT_LENGTH_MISMATCH error anymore, but got another error related to nuxt UI dependency popper.js, but can’t say if it’s related to these flags or not for now.

Disabling cache makes no difference for me.

I reported the ipv6 issue in vscode a while ago and it was already fixed. This shouldn’t matter anymore at least for vscode features.

If nuxt listens on ipv6, that would be another issue to solve.

Regarding your flags: I can confirm it works, but only if I specify both of them. If I only use --host ..., it works, but we’re back to slow speeds (and failed requests). Only using --no-fork causes the 500 errors mentioned above.

Just in case: I’m always testing on vscode insiders

Thanks for helping and upstream issue report dear @max06

I have pushed a .devcontainer setup to this repository. (https://github.com/nuxt/cli/commit/b8f9fd3a0c1ace6c3f548cc8a92d76f4be0eb43d).

After cloning repo, you can reopen it in dev container and then run pnpm install / pnpm build --stub and then you can run any state of repository using pnpm run dev (it opens playground/ in dev mode).

This issue is most likely a combination of IPv6 stack issues with proxy layer. When using --no-fork --host 127.0.0.1 we disable this proxy layer.

I was able to trace the issue down to

root@463d9cf38f77:/workspaces/nuxt# git bisect bad
abd5d857705fa830d6ef019cb8a5ed3c763b7cd5 is the first bad commit
commit abd5d857705fa830d6ef019cb8a5ed3c763b7cd5
Author: Daniel Roe <daniel@roe.dev>
Date:   Fri Aug 25 16:20:32 2023 +0100

    feat(nuxt): migrate to new `nuxt/cli` (#22799)

Let’s see if that helps in finding the issue…

Yep. No problem with this VS Code and Nuxt 3.6.5 (and latest nuxt UI)

Any update on this?

The error actually breaks any repository using Nuxt (like Nuxt UI). I tried to disable the cache but it has no effect.

Thanks! yes I can reproduce it. Seems coming from the vite handler.

GET http://127.0.0.1:3000/_nuxt/node_modules/.cache/vite/client/deps/vue-router.js?v=38dcfad8 net::ERR_CONTENT_LENGTH_MISMATCH 200 (OK)

CLI warning might be related:

[Vue Router warn]: No match found for the location with path "/_nuxt/@vite/client"

Something to add is if you open the network tab and disable the cache, this issue will be gone. (this might be simply a warmup cache timing issue)

/cc @antfu Do you have any guesses?

Side question: if I’m able to build a minimal reproduction repository containing a VS Code .devcontainer file, are you able to run it? (you’d need VS Code and Docker Desktop for this). I’m asking because I suspect the problem can’t be reproduce on a local environment.