Cannot read properties of undefined (reading 'cdnURL')

[AlexanderBredun]

I used this Nuxt Storybook starter, but when I try to add any image from the public directory, I get the following error: When I checked the console, it pointed me to this part of the code and showed that there is a problem with useRuntimeConfig:

Node 18.18.2, npm 9.8.1, windows 10

[guim4dev]

@AlexanderBredun did you manage to find a workaround?

[AlexanderBredun]

@guim4dev no unfortunately

[obulat]

To replicate, build the showcase app that has /pages in it:

pnpm dev:prepare & pnpm example:showcase:storybook:build

Go to the build folder (storybook/examples/showcase/storybook-static) and run an http server in it: npx http-server

Check the logs in the console.

[tobiasdiez]

Thanks @obulat for the reproduction. I get the error there now as well. This only occurs in the static build, and not when looking in console for the dev build ( example:showcase:dev > Storybook), right?

That makes debugging this a bit harder...

[obulat]

Thanks @obulat for the reproduction. I get the error there now as well. This only occurs in the static build, and not when looking in console for the dev build ( example:showcase:dev > Storybook), right?

That makes debugging this a bit harder...

I think that this is related to #761, and the errors there can be masking these errors. router is definitely part of the problem here.

[doppelmutzi]

I have a similar problems. Occurs with the autogenerated Docs view when I have multiple exports in a stories file.

[guim4dev]

adding some extra info here

@doppelmutzi I had the same problem. It only occurs in autogenerated docs with >1 stories. Single Story autogenerated docs work fine, its probably something related to routing as pointed out by @obulat

I disabled autodocs for now as multi stories are important for our use case and it works fine locally.

Sadly now im getting blocked by chromatic, as the built version of storybook also throws the cdnURL error :/

[d-low]

Could this be a race condition? I set a breakpoint on line 2 in paths.mjs and then stepped into useRuntimeConfig():

// /.nuxt/nitro.client.mjs
export const useRuntimeConfig = () => 
window?.__NUXT__?.config || {}

In useRuntimeConfig() window.__NUXT__ was undefined.

However, when I later check whether this global variable is defined in the console I can see that it is:

[enkot]

@tobiasdiez Thank you for your work on this module 💚

It would be great to prioritise this issue. In my case I can't upgrade to Nuxt 3.13.x because of this error.

I will also try to investigate.

[Limonische]

Encountered this error with latest versions of nuxt and storybook. This helped resolve the issue (only for stories themselves, not docs):

vite: {
    resolve: {
      alias: {
        vue: 'vue/dist/vue.esm-bundler.js',
      },
    },
}

Come to think of it, this is probably related to other issue, but still might be useful to someone

[tobiasdiez]

Thanks for looking into this. If it's indeed a problem with the runtime bundler of vue, then this should be fixed as part of https://github.com/nuxt-modules/storybook/pull/740 (which sadly is stuck in another issue).

[bojanrajh]

As a workaround, because we are not using cdn or changing the base URL, pnpm patch nuxt did the trick, for now:

diff --git a/dist/index.mjs b/dist/index.mjs
index 9fe137cf72916a0ceb3edbae12c9deacd960faed..625bb157338fbf10083760166600e518d81065c5 100644
--- a/dist/index.mjs
+++ b/dist/index.mjs
@@ -5119,7 +5119,8 @@ const publicPathTemplate = {
       "export const buildAssetsDir = () => appConfig.buildAssetsDir",
       "export const buildAssetsURL = (...path) => joinRelativeURL(publicAssetsURL(), buildAssetsDir(), ...path)",
       "export const publicAssetsURL = (...path) => {",
-      "  const publicBase = appConfig.cdnURL || appConfig.baseURL",
+      "  const publicBase = ''",
       "  return path.length ? joinRelativeURL(publicBase, ...path) : publicBase",
       "}",
       // On server these are registered directly in packages/nuxt/src/core/runtime/nitro/renderer.ts

[losbeekos]

When you use Storybook's render function to render out a component (or components) this issue arises as well.

[andresilva-cc]

@d-low for me window.__NUXT__ is always undefined, even after some time.

I've been doing some tests and the function passed to the setup function inside preview.ts is never called, which explains why window.__NUXT__ is always undefined. I see that the setup function is provided by @storybook/vue3, which, according to their code, adds the passed function into globalThis.PLUGINS_SETUP_FUNCTIONS and it's later executed in runSetupFunctions.

I'm having trouble understanding how the 2 packages work together. I know that the Nuxt renderer is a wrapper for @storybook/vue3, but things get complicated inside @storybook/vue3, where it doesn't seem to call the provided setup functions.

Does anyone have an idea of what's happening?

[andresilva-cc]

Reverting commit bcf68df stops the error, but images are broken, maybe it's just a matter of adding staticDirs to .storybook/main.ts.

Ok, so temporary workaround for anyone struggling with this. Add this snippet to your .storybook/preview.ts:

// @ts-expect-error internal Nuxt property
window.__NUXT__ = {
  config: {
    app: {
      baseURL: '/',
      cdnURL: ''
    }
  }
}

And to make images work, add this line to your config in .storybook/main.ts:

staticDirs: ['../public'],

[JoJk0]

Reverting commit bcf68df stops the error, but images are broken, maybe it's just a matter of adding staticDirs to .storybook/main.ts.

Ok, so temporary workaround for anyone struggling with this. Add this snippet to your .storybook/preview.ts:

// @ts-expect-error internal Nuxt property window.NUXT = { config: { app: { baseURL: '/', cdnURL: '' } } } And to make images work, add this line to your config in .storybook/main.ts:

staticDirs: ['../public'],

Looks like this error is not showing up when I remove router.options.ts file so yeah definitely something connected to the router. When I include routes and I apply window.__NUXT__ patch from above, then it solves the issue, however, another one arises:

[danieelbog]

Any new on this? I also have what JoJk0 says

[etsubeta132]

@AlexanderBredun Is the issue fixed ?

[yanniznik]

Same issue, interested in solution!

[GonzaloGPF]

I have same issue, with just fresh installation. Also, if I create a simple app-button.stories.ts, it throws errors too

[bojanrajh]

This is our current pnpm patch nuxt.

diff --git a/dist/index.mjs b/dist/index.mjs
index 7fa92a5cd8f111907c6d991a367d1442eb5c920f..ed13c46841bbaeff30947d4960dc55eddb240b26 100644
--- a/dist/index.mjs
+++ b/dist/index.mjs
@@ -6452,13 +6452,13 @@ const publicPathTemplate = {
     return [
       "import { joinRelativeURL } from 'ufo'",
       !nuxt.options.dev && "import { useRuntimeConfig } from 'nitropack/runtime'",
-      nuxt.options.dev ? `const getAppConfig = () => (${JSON.stringify(nuxt.options.app)})` : "const getAppConfig = () => useRuntimeConfig().app",
-      "export const baseURL = () => getAppConfig().baseURL",
-      "export const buildAssetsDir = () => getAppConfig().buildAssetsDir",
+      nuxt.options.dev ? `const getAppConfig = () => (${JSON.stringify(nuxt.options.app)})` : "const getAppConfig = () => useRuntimeConfig()?.app",
+      "export const baseURL = () => getAppConfig()?.baseURL || '/'",
+      "export const buildAssetsDir = () => getAppConfig()?.buildAssetsDir",
       "export const buildAssetsURL = (...path) => joinRelativeURL(publicAssetsURL(), buildAssetsDir(), ...path)",
       "export const publicAssetsURL = (...path) => {",
       "  const appConfig = getAppConfig()",
-      "  const publicBase = appConfig.cdnURL || appConfig.baseURL",
+      "  const publicBase = appConfig?.cdnURL || appConfig?.baseURL || '/'",
       "  return path.length ? joinRelativeURL(publicBase, ...path) : publicBase",
       "}",
       // On server these are registered directly in packages/nuxt/src/core/runtime/nitro/handlers/renderer.ts

[AndrewBogdanovTSS]

@bojanrajh, the patch worked for me, but do you know if there is any issue inside Nuxt that would address it in the Core, so we won't need to support the patch internally?