Describe the bug
When a Nuxt layer contains .js server route files, Nitro scans and registers them correctly but then fails to load them via the nitro-handler-meta virtual module with an ENOENT error. The file physically exists at the reported path. Renaming the file to .ts fixes the issue immediately.
Error message
[nitro 4:39:32 PM] ERROR Error: Could not load nitro-handler-meta:file:///pathToProject/Client/packages/Payment/server/api/payment/bankRegister2.post.js (imported by virtual:#nitro-internal-virtual/server-handlers-meta): ENOENT: no such file or directory, open 'file:///pathToProject/Client/packages/Payment/server/api/payment/bankRegister2.post.js'
undefined
To reproduce
Nuxt monorepo with multiple layers in extends
One layer contains a .js server route (e.g. server/api/hello.post.js)
Run nuxt dev
Nitro throws the ENOENT error above
Expected behavior
.js server route files in layers should load correctly, the same as .ts files.
Actual behavior
Nitro registers the .js handler during scan but fails to open the file when building server-handlers-meta. .ts files in the exact same location work without any issue, indicating the file path is valid and the problem is specific to how the handler-meta virtual plugin resolves .js files from layer directories.
Workaround
Rename all .js server route files in layers to .ts.
Another scary workaround
error disappear for .js files if layer folder name has the same start characters which basic layer. So if in my monorepo I have layers organized as:
/packages/App
/packages/Base
/packages/Auth
and I am running app from App which has extend:['../Auth','../Base'] in nuxt.config
the error emerges for first .js server route found in Auth layer,
when I change layer folder name (!) to BaseAuth (or BaseAnything) :
/packages/App
/packages/Base
/packages/BaseAuth
and I am running app from App which has now extend:['../BaseAuth','../Base']
error is gone...
Environment
nuxt info
│ │ Operating system macOS 25.5.0 │
│ │ CPU Apple M4 Pro (12 cores) │
│ │ Node.js version v22.22.2 │
│ │ nuxt/cli version 3.37.0 │
│ │ Package manager pnpm 11.24.0 │
│ │ Nuxt version 4.5.2 │
│ │ Nitro version 2.13.4 │
│ │ Builder vite 8.2.2 │
│ │ Config $meta, compatibilityDate, devtools, experimental, extends, ssr │
│ │ Modules - │
Describe the bug
When a Nuxt layer contains .js server route files, Nitro scans and registers them correctly but then fails to load them via the nitro-handler-meta virtual module with an ENOENT error. The file physically exists at the reported path. Renaming the file to .ts fixes the issue immediately.
Error message
To reproduce
Nuxt monorepo with multiple layers in extends
One layer contains a .js server route (e.g. server/api/hello.post.js)
Run nuxt dev
Nitro throws the ENOENT error above
Expected behavior
.js server route files in layers should load correctly, the same as .ts files.
Actual behavior
Nitro registers the .js handler during scan but fails to open the file when building server-handlers-meta. .ts files in the exact same location work without any issue, indicating the file path is valid and the problem is specific to how the handler-meta virtual plugin resolves .js files from layer directories.
Workaround
Rename all .js server route files in layers to .ts.
Another scary workaround
error disappear for .js files if layer folder name has the same start characters which basic layer. So if in my monorepo I have layers organized as:
/packages/App
/packages/Base
/packages/Auth
and I am running app from App which has
extend:['../Auth','../Base']in nuxt.configthe error emerges for first .js server route found in Auth layer,
when I change layer folder name (!) to BaseAuth (or BaseAnything) :
/packages/App
/packages/Base
/packages/BaseAuth
and I am running app from App which has now
extend:['../BaseAuth','../Base']error is gone...
Environment
nuxt info
│ │ Operating system macOS 25.5.0 │
│ │ CPU Apple M4 Pro (12 cores) │
│ │ Node.js version v22.22.2 │
│ │ nuxt/cli version 3.37.0 │
│ │ Package manager pnpm 11.24.0 │
│ │ Nuxt version 4.5.2 │
│ │ Nitro version 2.13.4 │
│ │ Builder vite 8.2.2 │
│ │ Config $meta, compatibilityDate, devtools, experimental, extends, ssr │
│ │ Modules - │