nuxt: [nuxt] [request error] [unhandled] [500] Cannot read properties of undefined (reading 'modules')

Encountered the same.

The error comes from nuxt-root.vue, so I looked up the transformed code with VITE_NODE_DEBUG_DUMP=true pnpm dev

The snippet of the error code in nuxt3/dist/app/components/nuxt-root.vue:76:16 is:

// ...
// L72
const __vite_ssr_import_5__ = await __vite_ssr_import__("vue");

const _sfc_setup = _sfc_main.setup
_sfc_main.setup = (props, ctx) => {
  const ssrContext = __vite_ssr_import_5__.useSSRContext()
  ;(ssrContext.modules || (ssrContext.modules = new Set())).add("../node_modules/.pnpm/nuxt3@3.1.1-rc.0-27911047.7d812db/node_modules/nuxt3/dist/app/components/nuxt-root.vue")
  return _sfc_setup ? _sfc_setup(props, ctx) : undefined
}
const __vite_ssr_import_6__ = await __vite_ssr_import__("/@id/__x00__plugin-vue:export-helper");

It seems the server did not run in Vue SSR context, where useSSRContext() returns undefined. This also matches the previous errors in the console:

[Vue warn]: inject() can only be used inside setup() or functional components.
[Vue warn]: Server rendering context not provided. Make sure to only call useSSRContext() conditionally in the server build.
[Vue warn]: Unhandled error during execution of setup function

In that sense, disabling SSR would bypass this error:

export default defineNuxtConfig({
  ssr: false
})

Haven’t dive deep into this, but hopefully, this could provide a bit more context

I am reviewing https://github.com/vuejs/core/pull/7590 again, and noticed that the first repro provided by @harlan-zw here is now working properly with Nuxt 3.2+.

Fundamentally, I still believe the “root cause” is that there are duplicated copies of Vue, not that Vue should be made to allow multiple copies working together. The fix in https://github.com/vuejs/core/pull/7590 is more like a band-aid that happens to make some cases work, but isn’t a technically complete fix either. I am trying some alternative implementation along the same veins, but I would like to get an updated minimal repro with latest Nuxt to make sure we are making the right trade-offs.

I made an upstream fix to Vue.js (https://github.com/vuejs/core/pull/7590) that ultimately fixes the root causes of this issue and the ones alike in the future. And confirming locally it does fix some reproductions tried.

I hope we can find a faster fix and deduplicate Vue to using the same instance of Vue in the meantime until that (hopefully) gets landed upstream.

Reproduction: https://stackblitz.com/edit/nuxt-starter-ykdhnn?file=nuxt.config.ts (hacky, see notes).

I started running into this issue quite a bit, I believe it’s related to Nitro v2 and did some digging today.

For me, what I’ve found is that this occurs when your workspace directory is being transpiled.

I have a replication with my nuxt-og-image repo: https://github.com/harlan-zw/nuxt-og-image/tree/temp/bugged-playground (pnpm i && pnpm run dev)

My setup is a playground directory as a subfolder of a module. The playground links the module using a link in package.json

export default defineNuxtConfig({
  modules: [
    'nuxt-og-image',
  ],
})

{
  "dependencies": {
    "nuxt-og-image": "link:../"
  }
}

With my setup it seems like a deeper issue with the node module resolution, pointing to the directory with the package.json instead of the /dist folder, leading it to inline vue again?

The issue was pretty easy to solve in this case, by swapping to a directory path instead of relying on the node module resolving. Don’t think it helps OP in this case.

export default defineNuxtConfig({
  modules: [
    resolve(__dirname, '../src/module'),
  ],
})

I tried to replication this in StackBlitz without much success using a similar setup as the above. I had to just manually point to the workspace dir to be transpiled and I could replicate it, see reproduction.

So in summary, I believe this is a Nitro issue with the inlining of deps, possibly module resolution issue (possibly with symlinks?). Related code would be this function https://github.com/unjs/nitro/blob/main/src/rollup/plugins/externals.ts#LL22C19-L22C19

@pi0 might have some ideas

Hi! Just started and still investigating this issue too since happened with latest content-wind and 3.1.

It seems the root cause is that we are using different “builds” of vue (@vue/runtime-core, also server-renderer) which each use their own global vue context instance variable for getCurrentInstance().

(normally @vue/runtime-core.cjs.js only is required and once)

@harlan-zw I don’t think it is related to Nitro 2 externals. External plugin will be used for production build only in dev it is direct esm import of Nuxt bundle. Using resolved path might be affecting Node Modules search path and preventing duplicate resolutions as hotfix.

@antfu Thanks for debugging tip! I have tried to add an inline check guard to @vitejs/plugin-vue/dist/index.mjs (where the code comes from). You are right the issue is null context because even bypassing that, another composable (useNuxtInstance) fails on server side startup.

A little more on this. It seems that nuxt doesn’t like any directory prefixed with src. For example, I changed my directory name from ‘src’ to ‘code’ and the project works fine. If I change the directory to ‘src-code’ it fails with error above. If I change to something like ‘my-code’ or ‘the-code’ the project runs without error.

First of all, thank you to the others who have added feedback and clues to this report - much appreciated!

I whittled down my project down to almost nothing. The project is attached below as tst.zip. It seems that the issue has little to do with my project in general, as I have it down to a single dependency and basically - hello world. My project root has some dockerfiles and other stuff that is for deployment to our OpenShift environment. The nuxt part of the app is in the ‘src’ directory. Strangely enough, one thing I have noticed on my end is if I change my ‘src’ directory name to something else like - ‘code’, wipe out node_modules, run npm install, and re-run the app via ‘npm run dev’ the app will work without receiving the errors. If I then change my directory back to ‘src’ again and do the same, the app will once again fail with the errors reported above. I have tried this several times with the same result.

tst.zip