nuxt: Cannot access 'renderer$1' before initialization is:closed
Environment
- Operating System:
Darwin - Node Version:
v18.12.1 - Nuxt Version:
3.4.3 - Nitro Version:
2.3.3 - Package Manager:
pnpm@7.30.0 - Builder:
vite - User Config:
ssr,app,css,modules,schemaOrg,windicss,build,runtimeConfig - Runtime Modules:
nuxt-schema-org@2.1.2,nuxt-windicss@2.6.1,@vueuse/nuxt@9.13.0,@pinia/nuxt@0.4.9 - Build Modules:
-
Reproduction
I’ve run npx nuxi upgrade --force as advise on a project previously running Nuxt 3.0.0.
Describe the bug
My previously running site is showing a 500 error, whereas before it was working:
Cannot access 'renderer$1' before initialization
I can’t seem to pin point the exact reason or cause, but it looks to be failing potentially on a server side route because a library used is maybe not ES compatible …
However, it was working before … so it leads me to think maybe a breaking change has been introduced to Nuxt 3.4.3 …
Additional context
No response
Logs
[nitro] [dev] [uncaughtException] ReferenceError: require is not defined in ES module scope, you can use import instead 12:16:18 PM
at requireContext (file:///Users/michael/Developer/kinandconscious/kindandconscious-nuxt3/.nuxt/dev/index.mjs:2235:35)
at file:///Users/michael/Developer/kinandconscious/kindandconscious-nuxt3/.nuxt/dev/index.mjs:6114:18
at file:///Users/michael/Developer/kinandconscious/kindandconscious-nuxt3/.nuxt/dev/index.mjs:6134:3
at ModuleJob.run (node:internal/modules/esm/module_job:193:25)
at async Promise.all (index 0)
at async ESMLoader.import (node:internal/modules/esm/loader:530:24)
at async loadESM (node:internal/process/esm_loader:91:5)
at async handleMainPromise (node:internal/modules/run_main:65:12)
[nuxt] [request error] [unhandled] [500] Cannot access 'renderer$1' before initialization 12:16:18 PM
at ./.nuxt/dev/index.mjs:518:65
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async Object.handler (./node_modules/.pnpm/h3@1.6.4/node_modules/h3/dist/index.mjs:1247:19)
at async Server.toNodeHandle (./node_modules/.pnpm/h3@1.6.4/node_modules/h3/dist/index.mjs:1322:7)
[nuxt] [request error] [unhandled] [500] Cannot access 'renderer$1' before initialization 12:16:19 PM
at ./.nuxt/dev/index.mjs:518:65
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async Object.handler (./node_modules/.pnpm/h3@1.6.4/node_modules/h3/dist/index.mjs:1247:19)
at async Server.toNodeHandle (./node_modules/.pnpm/h3@1.6.4/node_modules/h3/dist/index.mjs:1322:7)
[nuxt] [request error] [unhandled] [500] Cannot access 'renderer$1' before initialization 12:16:19 PM
at ./.nuxt/dev/index.mjs:518:65
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async Object.handler (./node_modules/.pnpm/h3@1.6.4/node_modules/h3/dist/index.mjs:1247:19)
at async toNodeHandle (./node_modules/.pnpm/h3@1.6.4/node_modules/h3/dist/index.mjs:1322:7)
at async Object.ufetch [as localFetch] (./node_modules/.pnpm/unenv@1.4.1/node_modules/unenv/runtime/fetch/index.mjs:9:17)
at async Object.errorhandler [as onError] (./.nuxt/dev/index.mjs:485:30)
at async Server.toNodeHandle (./node_modules/.pnpm/h3@1.6.4/node_modules/h3/dist/index.mjs:1329:9)
On startup of the dev server:
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 2
- Comments: 25 (5 by maintainers)
I’m closing this issue, as for me although I haven’t had time to fully investigate it looks to be any issue with something on the server.
I don’t feel like this should be closed tbh. Only because we haven’t figured out the cause yet doesn’t mean it’s not an issue/doesn’t exist
I had a similar issue when using the
nuxt-authpackage in conjunction withimport GoogleProvider from "next-auth/providers/google";. We might need to append.defaultto the one we imported, though I’m unclear on the exact reason. For example:without
.defaultwe will got that error. I hope this helps!no code calling this endpoint (accessing via browser). literally pasted the whole code. “healthcheck$1” error refers to api/healthcheck.ts (the filename), also seen ‘render$1’ error, but honestly i can’t recall what differently i had at the time
using fresh nuxt 3 on pnpm, no other logic, project just initialized. by default api endpoints aren’t working.
nuxt js guide doesnt mention it, nor linter/ide notes it, but after i added EventHandler import to the top line (not defineEventHandler) i no longer see the error:
if youre using prisma do npx prisma generate, it then downloads the rust engine i was able to solve this, i used npkill to delete my node modules i think that could be cause but yeah i fixed it with npx prisma generate
I was able to solve this by running
npx prisma generate. But if your project doesn’t use Prisma, there might be going on something else unfortunately…Well, I had the same issue and then I removed the autoImport that I set on nuxt.config.js and the endoint started to work.
imports: { autoImport: false, },experiencing similar issue
Hi. I was getting this error and it is solved now. What I was doing wrong is I was using the env file (in the server folder ‘APIs’) which I have deleted before. So I just commented on the line where I was using the env file to get some information. Maybe you are using some variable for another library like API key etc. which is making this issue
absolutely not. If i create a file with in server/api directory, called healthcheck.ts, that being the only file in server directory with content as such:
export default defineEventHandler(() => ({ “test”: “test” }));
error still occurs. Cannot access ‘healthcheck$1’ before initialization
In our case also the issue is with one of one of the server routes. Also we have specified the wrong keys in .env which prevented the server routes from starting.
Même problème avec le serve de Nuxt / Nitro
@michealroberts @honeyp-snyk I was getting this same error. Tracked it down to a bad file in
/server/api– is that something you have looked into? It’s not obvious from the error but start by checking the files in that directory. I imagine problems could arise if you have non-route handler files that are maybe trying to be exported as route handlers.