-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
Problem Description
Currently, Yarn Berry's configuration parser supports standard environment variable expansion with default values (e.g., ${VAR:-default_literal}).
However, it does not support recursive or nested expansion where the fallback value is another environment variable.
If a user attempts to use a syntax like ${PRIMARY_VAR:-${SECONDARY_VAR}}:
-
Yarn detects PRIMARY_VAR is unset.
-
Yarn reads the fallback value.
-
Yarn treats the fallback ${SECONDARY_VAR} as a literal string instead of expanding it.
Proposed Feature
I request that the .yarnrc.yml parser be updated to support recursive variable expansion. If a fallback value contains ${...} syntax, it should be evaluated rather than returned as a string.
This would bring Yarn's configuration behavior closer to standard shell (Bash/Zsh) parity.
Use Case / Rationale
This pattern is critical for hierarchical CI/CD configurations where precedence is required without complex shell pre-scripting.
Example Scenario: An organization wants to enforce the following precedence for the Registry URL:
-
Specific Override: ${NPM_SERVER} (e.g., for a specific project)
-
Organization Mirror: ${GLOBAL_MIRROR} (e.g., defined in the CI runner)
-
Public Default: https://registry.yarnpkg.com
Current configuration attempt:
npmRegistryServer: "${NPM_SERVER:-${GLOBAL_MIRROR:-https://registry.yarnpkg.com}}"Current Result (Failure): If NPM_SERVER is missing, Yarn attempts to connect to the literal URL "${GLOBAL_MIRROR:-https://registry.yarnpkg.com}", which causes a network error or DNS failure.
Workaround (Why this isn't ideal)
Currently, users must calculate the final variable in a shell script before running Yarn:
export YARN_REGISTRY_FINAL=${NPM_SERVER:-${GLOBAL_MIRROR:-https://registry.yarnpkg.com}}
yarn installThis moves configuration logic out of .yarnrc.yml (where it belongs) and into ephemeral shell environments, making the build setup more brittle and harder to debug.