Skip to content
This repository has been archived by the owner on Apr 6, 2023. It is now read-only.

fix(schema): preserve top-level undefined keys in runtime config #4459

Closed
wants to merge 1 commit into from
Closed

fix(schema): preserve top-level undefined keys in runtime config #4459

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions packages/schema/src/config/_common.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -720,14 +720,19 @@ export default {
* @version 3
*/
runtimeConfig: {
$resolve: (val: RuntimeConfig, get) => defu(val, {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you e2e tested this? c12 and nitro use default multiple times.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, we have a chance to map all NITRO_ and NUXT_ values into runtime config without explicit definition.

Copy link
Member Author

@danielroe danielroe Apr 20, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it will need PRs to c12 & nitro. Issue is only at top-level IIRC so nested values with undefined are fine.

Tricky thing about automatic mapping is that it doesn't work both ways (ie. given a value in the config object, we can find the env variable name, but not vice versa).

For example, NUXT_BASE_URL maps to all of the following:

{
  base: {
    url: ''
  },
  baseURL: '',
  baseUrl: '',
  base_url: '',
  BaseUrl: '',
  // etc.
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can alternatively require fallback values in runtimeConfig?

Copy link
Member

@pi0 pi0 Apr 20, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can make a convention work as top-level camelCase. using undefined as default is not a solution I would keep forever... But let's merge it in last minutes. We can document to use empty string also for fallbacks instead of undefined.

$resolve: (val: RuntimeConfig, get) => ({
...get('publicRuntimeConfig'),
...get('privateRuntimeConfig'),
public: get('publicRuntimeConfig'),
...val || {},
public: {
...get('publicRuntimeConfig'),
...val?.public || {},
},
app: {
baseURL: get('app').baseURL,
buildAssetsDir: get('app').buildAssetsDir,
cdnURL: get('app').cdnURL,
...val?.app || {},
}
})
},
Expand Down