How can I access an environment variable in package.json when using varlock?

[unikitty37]

In my package.json, I currently have this from before migrating from dotenv to varlock:

{
  "scripts": {
    "test:e2e:ui": "playwright install && playwright test --ui-host=0.0.0.0 --ui-port=$(grep '^LEWP_PLAYWRIGHT=' .env | cut -d '=' -f2)",
  }
}

This is a bit kludgy, to say the least — and it doesn't allow for varlock's multiple environments, of course.

Playwright doesn't seem to allow setting UI mode's port from within the config file — only at the CLI (unless the docs have this hidden somewhere obscure!)

Is there a way I can get the correct value of LEWP_PLAYWRIGHT in this command?

[yudin-s]

For this particular package.json case, I would use varlock printenv or put the shell expansion inside the command that varlock run starts.

The direct form is:

{
  "scripts": {
    "test:e2e:ui": "playwright install && playwright test --ui-host=0.0.0.0 --ui-port=$(varlock printenv LEWP_PLAYWRIGHT)"
  }
}

printenv is meant for exactly this kind of shell interpolation: it prints one resolved variable, and the command spec also supports --path / -p if you need to point at a specific env file or directory.

If you prefer to inject the whole resolved environment into the Playwright process, keep the expansion inside a child shell after varlock run has injected the variables:

{
  "scripts": {
    "test:e2e:ui": "varlock run -- sh -c 'playwright install && playwright test --ui-host=0.0.0.0 --ui-port=\"$LEWP_PLAYWRIGHT\"'"
  }
}

The important detail is the placement of expansion. A script like this is usually wrong:

varlock run -- playwright test --ui-port=$LEWP_PLAYWRIGHT

because the outer npm shell can expand $LEWP_PLAYWRIGHT before varlock run has a chance to inject it. printenv avoids that, and varlock run -- sh -c ... delays the expansion until the varlock-managed child process is running.

For UI mode specifically, your assumption about Playwright looks right: --ui-port is a CLI option, so resolving the value in the script is the practical place to do it.

If this solves it, please mark the answer so others migrating package scripts from dotenv can find the pattern quickly.