fix: node_modules paths in runtime configuration payload

[dargmuesli]

Environment

• Operating System: Linux
• Node Version: v20.11.1
• Nuxt Version: 3.12.2
• CLI Version: 3.12.0
• Nitro Version: -
• Package Manager: pnpm@9.4.0
• Builder: -
• User Config: app, runtimeConfig, i18n, site, compatibilityDate, devServer, devtools, modules, nitro, typescript, colorMode, cookieControl, gtag, htmlValidator, linkChecker, robots, security, seo, sitemap, tailwindcss, $development, $production
• Runtime Modules: @dargmuesli/nuxt-cookie-control@8.4.4, @nuxt/devtools@1.3.9, @nuxt/eslint@0.3.13, @nuxt/image@1.7.0, @nuxtjs/color-mode@3.4.2, @nuxtjs/html-validator@1.8.2, @nuxtjs/i18n@8.3.0, @nuxtjs/seo@2.0.0-rc.11, @nuxtjs/tailwindcss@6.12.0, @pinia/nuxt@0.5.1, nuxt-gtag@2.0.6, (), (), nuxt-security@2.0.0-rc.9
• Build Modules: -

Reproduction

will submit if necessary

Describe the bug

The Google search console shows countless "Not found (404)" errors to me for paths to language files that are not available in a production build, i.e. paths to files inside node_modules:

You can check out my website's source code and search for node_modules. You'll see that those paths:

window.__NUXT__.config={
 "public": {
   "i18n": {
     "configLocales": [
       {
         "code": "en",
         "name": "English",
         "iso": "en",
         "files": [
           "../node_modules/.pnpm/@dargmuesli+nuxt-vio@13.2.1_@lezer+common@1.2.1_@types+eslint@8.56.10_@unocss+webpack@0.61.3__onw6a5qdvo7xolh5mymdy7mkeu/node_modules/@dargmuesli/nuxt-vio/locales/en.json",
           "locales/en.json"
         ]
       },
     ],
...

@dargmuesli/nuxt-vio being a layer of mine.

Apparently Google picks those paths up, but I guess they are of no use here as node_modules shouldn't be available in a project built for production, right?

Any reason to keep these paths here? Should they be corrected maybe or removed?
I hope this report helps, would love to assist!

Additional context

I wonder why those paths are picked up, as I don't see any network request being tried to those paths.

Logs

No response

[BobbieGoede]

Hmm I guess Google tries to crawl anything that resembles a link 🤔 Did not think they would also try paths in javascript variables 😂

It's worth looking into removing these paths from production builds as long as these are not used after build.