FeathersJS production.json: duplicate full nested objects or switch to a custom deep-merge config setup?

Our FeathersJS app relies on the npm config module with default.json defining a nested authentication object (JWT secret plus options like expiresIn and algorithm). In production we only want to override the secret, but the config module merges shallowly: setting authentication.jwt.secret in production.json replaces the whole nested object, silently dropping the options. Locally everything works because default.json is complete on its own.

We see two documented directions and are unsure which to standardize on:

• Keep the stock config module and fully redefine every nested object in production.json, accepting duplication and the risk of drifting out of sync with default.json.
• Replace or wrap the config loading with custom code (deep merge plus startup validation of required keys) so partial overrides are safe and missing secrets fail at boot instead of at first request.

Assume a recent FeathersJS 5 (Dove) app generated by the CLI, deployed to a container platform where NODE_ENV=production is set explicitly.

Is full duplication in production.json the intended pattern for the config module, or is a custom deep-merge layer the common practice in production FeathersJS deployments? If we keep the stock module, is there a documented way to validate required nested keys at startup rather than discovering missing values at runtime? Are there known pitfalls with either approach when NODE_CONFIG_DIR differs between local and container environments?