fix(nuxt): lazily access runtimeConfig #32428
Conversation
|
|
WalkthroughThe change modifies the way the application configuration is accessed in the publicPathTemplate by replacing the direct constant 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (4)
✨ Finishing Touches
🧪 Generate Unit Tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/nuxt/src/core/templates.ts (1)
501-503: Consider memoising the dev-mode object to avoid needless allocations
Every call togetAppConfig()in dev mode returns a brand-new object literal. While harmless, this can become a minor hotspot becausebaseURL(),buildAssetsDir()andpublicAssetsURL()can be invoked frequently. You can provide the same laziness while still returning a single shared object:-const getAppConfig = () => ${JSON.stringify(nuxt.options.app)} +const _devAppConfig = ${JSON.stringify(nuxt.options.app)} +const getAppConfig = () => _devAppConfigThis keeps the change zero-cost in prod while removing redundant allocations during local development.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/nuxt/src/core/templates.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: codeql (javascript-typescript)
- GitHub Check: codeql (actions)
- GitHub Check: build
- GitHub Check: code
🔇 Additional comments (1)
packages/nuxt/src/core/templates.ts (1)
504-506: Guard against missing runtime values to prevent unexpectedundefinedin URLs
baseURL(),buildAssetsDir()andpublicAssetsURL()assume the relevant keys always exist ongetAppConfig(). If either is empty/undefined inruntimeConfig.app,joinRelativeURLwill happily concatenate the string"undefined", leading to broken asset URLs.Recommend a defensive fallback:
-export const baseURL = () => getAppConfig().baseURL -export const buildAssetsDir = () => getAppConfig().buildAssetsDir +export const baseURL = () => getAppConfig().baseURL || '/' +export const buildAssetsDir = () => getAppConfig().buildAssetsDir || ''and inside
publicAssetsURL:- const publicBase = appConfig.cdnURL || appConfig.baseURL + const publicBase = appConfig.cdnURL || appConfig.baseURL || '/'Please double-check that an empty string is a valid value in all contexts, and add a small unit test to cover the undefined case.
Also applies to: 509-513
There was a problem hiding this comment.
Pull Request Overview
This PR updates the publicPathTemplate to lazily access runtimeConfig via a getAppConfig function, avoiding an ambient call to useRuntimeConfig() before it’s initialized.
- Replace direct
appConfiginitialization with agetAppConfig()arrow function in both dev and prod. - Update exported URL helpers (
baseURL,buildAssetsDir,publicAssetsURL) to callgetAppConfig()at runtime. - Ensure
publicAssetsURLpullscdnURLorbaseURLfrom the lazy config inside the function body.
Comments suppressed due to low confidence (1)
packages/nuxt/src/core/templates.ts:501
- The dev-mode arrow function uses braces around the object literal without an explicit
return, so it’s parsed as a function body, not a returned object. Wrap the JSON in parentheses (e.g.,() => (${JSON.stringify(...)})) or addreturninside a block to ensure the object is returned.
? `const getAppConfig = () => ${JSON.stringify(nuxt.options.app)}`
@nuxt/kit
nuxt
@nuxt/rspack-builder
@nuxt/schema
@nuxt/vite-builder
@nuxt/webpack-builder
commit: |
CodSpeed Performance ReportMerging #32428 will not alter performanceComparing Summary
|
🔗 Linked issue
📚 Description
this addresses a regression spotted in CI (in runtime test environment), where
useRuntimeConfig()is called ambiently before it's been correctly set.on the client,
useRuntimeConfig()just accesses an object anyway, so this should be safe.