Skip to content

[Feature] Support recursive environment variable fallback in .yarnrc.yml #6998

@lilithyang2018

Description

@lilithyang2018

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}}:

  1. Yarn detects PRIMARY_VAR is unset.

  2. Yarn reads the fallback value.

  3. 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:

  1. Specific Override: ${NPM_SERVER} (e.g., for a specific project)

  2. Organization Mirror: ${GLOBAL_MIRROR} (e.g., defined in the CI runner)

  3. 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 install

This 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions