When SITE_CONFIG_PATH is set but invalid, it silently falls through to try the default path instead of erroring immediately.
This means for the following flows:
SITE_CONFIG_PATH defined |
SITE_CONFIG_PATH exists |
defaultPath exists |
Result |
| ✅ |
✅ |
N/A |
No error. Site config path returned. |
| ✅ |
❌ |
✅ |
No error. Default path returned. |
| ✅ |
❌ |
❌ |
Error saying env var path is invalid, no mention of default path. |
| ❌ |
❌ |
✅ |
No error. Default path returned. |
| ❌ |
❌ |
❌ |
Error saying default path is invalid. |
The main issue here is that the error messaging doesn't accurately reflect what's happening. No mention of falling back to the default path, and only showing the env var error message when both the env var path and the default path are invalid.
|
// They supplied something but we can't figure out what it is. Exit with an error. |
|
if (siteConfigPath !== undefined) { |
|
console.error(`Invalid site config path (${siteConfigPath} specified as an environment variable. Aborting.`); |
|
} else { |
|
console.error(`Default site config file (${defaultPath}) does not exist. Aborting.`); |
|
} |
When
SITE_CONFIG_PATHis set but invalid, it silently falls through to try the default path instead of erroring immediately.This means for the following flows:
SITE_CONFIG_PATHdefinedSITE_CONFIG_PATHexistsdefaultPathexistsThe main issue here is that the error messaging doesn't accurately reflect what's happening. No mention of falling back to the default path, and only showing the env var error message when both the env var path and the default path are invalid.
frontend-base/tools/webpack/utils/getResolvedSiteConfigPath.ts
Lines 21 to 26 in d511970