Support recursive environment variable fallback in .yarnrc.yml #7005

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Open

pvcresin wants to merge 2 commits into yarnpkg:master

from pvcresin:feature/recursive-env-var

Open

Support recursive environment variable fallback in .yarnrc.yml #7005

pvcresin wants to merge 2 commits into yarnpkg:master from pvcresin:feature/recursive-env-var

+243 −16

Conversation

@pvcresin

Copy link

@pvcresin pvcresin commented Dec 8, 2025 •

edited

Loading

What's the problem this PR addresses?

Support ${PRIMARY_VAR:-${SECONDARY_VAR:-fallback-value}}.
This would bring Yarn's configuration behavior closer to standard shell (Bash/Zsh) parity.
I really need this feature right now.

Resolves #6998

How did you fix it?

Added an implementation to recursively look for environment variables.

Checklist

I have read the Contributing Guide.

I have set the packages that need to be released for my changes to be effective.

I will check that all automated PR checks pass before the PR gets reviewed.

@pvcresin pvcresin force-pushed the feature/recursive-env-var branch from d33fa4d to 2fd4ea3 Compare

December 8, 2025 05:41

pvcresin

pvcresin commented

Dec 8, 2025

View reviewed changes

packages/docusaurus/static/configuration/yarnrc.json

"title": "JSON Schema for Yarnrc files",

"$schema": "https://json-schema.org/draft/2019-09/schema#",

"description": "Yarnrc files (named this way because they must be called `.yarnrc.yml`) are the one place where you'll be able to configure Yarn's internal settings. While Yarn will automatically find them in the parent directories, they should usually be kept at the root of your project (often your repository). **Starting from the v2, they must be written in valid Yaml and have the right extension** (simply calling your file `.yarnrc` won't do).\n\nEnvironment variables can be accessed from setting definitions by using the `${NAME}` syntax when defining the values. By default Yarn will require the variables to be present, but this can be turned off by using either `${NAME-fallback}` (which will return `fallback` if `NAME` isn't set) or `${NAME:-fallback}` (which will return `fallback` if `NAME` isn't set, or is an empty string).\n\nFinally, note that most settings can also be defined through environment variables (at least for the simpler ones; arrays and objects aren't supported yet). To do this, just prefix the names and write them in snake case: `YARN_CACHE_FOLDER` will set the cache folder (such values will overwrite any that might have been defined in the RC files - use them sparingly).",

"description": "Yarnrc files (named this way because they must be called `.yarnrc.yml`) are the one place where you'll be able to configure Yarn's internal settings. While Yarn will automatically find them in the parent directories, they should usually be kept at the root of your project (often your repository). **Starting from the v2, they must be written in valid Yaml and have the right extension** (simply calling your file `.yarnrc` won't do).\n\nEnvironment variables can be accessed from setting definitions by using the `${NAME}` syntax when defining the values. By default Yarn will require the variables to be present, but this can be turned off by using either `${NAME-fallback}` (which will return `fallback` if `NAME` isn't set) or `${NAME:-fallback}` (which will return `fallback` if `NAME` isn't set, or is an empty string). You can also nest this syntax, for example `${PRIMARY:-${SECONDARY:-fallback}}`, which first checks PRIMARY, then SECONDARY, and finally falls back to fallback.\n\nFinally, note that most settings can also be defined through environment variables (at least for the simpler ones; arrays and objects aren't supported yet). To do this, just prefix the names and write them in snake case: `YARN_CACHE_FOLDER` will set the cache folder (such values will overwrite any that might have been defined in the RC files - use them sparingly).",

Copy link

Author

@pvcresin pvcresin Dec 8, 2025

Choose a reason for hiding this comment

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

Added

You can also nest this syntax, for example ${PRIMARY:-${SECONDARY:-fallback}}, which first checks PRIMARY, then SECONDARY, and finally falls back to fallback.

@pvcresin pvcresin mentioned this pull request

Dec 8, 2025

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

Open

@pvcresin

Copy link

Author

pvcresin commented Dec 9, 2025

@arcanis I would like to hear your opinion.

clemyan

clemyan requested changes

Dec 11, 2025

View reviewed changes

packages/yarnpkg-core/sources/miscUtils.ts Outdated

export function replaceEnvVariables(value: string, {env}: {env: {[key: string]: string | undefined}}) {

const regex = /\\?\${(?<variableName>[\d\w_]+)(?<colon>:)?(?:-(?<fallback>[^}]*))?}/g;

const regex = /\\?\${(?<variableName>[\d\w_]+)(?<colon>:)?(?:-(?<fallback>(?:[^}]|}(?=}))*))?}/g;

Copy link

Member

@clemyan clemyan Dec 11, 2025 •

edited

Loading

Choose a reason for hiding this comment

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

This only works if the variable is the last thing in the fallback, so ${A:-${B}x} would fail

As there is no balancing groups in regex in JS, there are just 2 ways to properly support nested variables as far as I can see:

Do multiple passes to replace variables from the deepest-nested one, like how dotenv-expand does it
Actually write a PDA-like parser

Copy link

Author

@pvcresin pvcresin Dec 18, 2025

Choose a reason for hiding this comment

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

@clemyan Thank you for pointing out the case I hadn't considered.
I have modified the algorithm to support it.

Copy link

Member

@clemyan clemyan Dec 30, 2025

Choose a reason for hiding this comment

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

The \${...} syntax isn't really meant to be "escape everything inside", but rather "this brace has no special meaning. It's just that without nested substitution the two end up being equivalent.

Now that I have had some time to dive a little deeper I think the PDA approach would be superior and I'd like to have more robust syntax. Do you mind if I take your tests and take over the implementation? I can probably whip something up in a couple of days

Copy link

Author

@pvcresin pvcresin Dec 30, 2025

Choose a reason for hiding this comment

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

@clemyan I apologize for my shallow understanding. Please take care of the rest of the implementation.

pvcresin added 2 commits

December 18, 2025 15:19

@pvcresin


 feat: nested-variable

4e89eee

@pvcresin


 Run yarn version check --interactive

ee0bf63

@pvcresin pvcresin force-pushed the feature/recursive-env-var branch from 2fd4ea3 to ee0bf63 Compare

December 18, 2025 06:22

@pvcresin pvcresin requested a review from clemyan

December 18, 2025 06:23

Labels

None yet

2 participants

@pvcresin @clemyan

Uh oh!

Support recursive environment variable fallback in .yarnrc.yml #7005

Are you sure you want to change the base?

Support recursive environment variable fallback in .yarnrc.yml #7005

Conversation

@pvcresin pvcresin commented Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What's the problem this PR addresses?

How did you fix it?

Checklist

Uh oh!

@pvcresin pvcresin Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

pvcresin commented Dec 9, 2025

Uh oh!

@clemyan clemyan Dec 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

@pvcresin pvcresin Dec 18, 2025

Choose a reason for hiding this comment

Uh oh!

@clemyan clemyan Dec 30, 2025

Choose a reason for hiding this comment

Uh oh!

@pvcresin pvcresin Dec 30, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

@pvcresin pvcresin commented Dec 8, 2025 •

edited

Loading

@clemyan clemyan Dec 11, 2025 •

edited

Loading