new auto-inferred VARLOCK_ENV

[theoephraim]

This PR explores the idea of automatically inferring a VARLOCK_ENV that tries to just magically be set to the right thing.

The intention here is that you can use # @currentEnv=$VARLOCK_ENV without defining it and it will "Just Work".

To make this possible, we detect a bunch of known env vars based on various CI/deployment platforms and attempt to normalize them. While these magic vars will always be available, they do not automatically appear in your schema until they are used/references.

The full list of magic vars for now is:

• VARLOCK_ENV - development, preview, staging, production, test
• VARLOCK_IS_CI - true if we are in CI
• VARLOCK_BRANCH - branch name being tested/deployed
• VARLOCK_PR_NUMBER - PR number if this is a PR build
• VARLOCK_COMMIT_SHA/VARLOCK_COMMIT_SHA - current commit sha long/short versions
• VARLOCK_BUILD_URL - url where this will be deployed
• VARLOCK_REPO - current repo in "owner/repo" format (e.g., dmno-dev/varlock)
• VARLOCK_PLATFORM - current platform name (eg, "Github Actions", "Cloudfalre")

Not all platforms populate all of these, so we would just populate whatever we can.

You may reference these vars and they will automatically appear in your schema. For others you want added to your schema, but don't necessarily reference anywhere else, we could let you just define them without a value (e.g., VARLOCK_BRANCH=).

Alternatively, we could have some kind of root decorator that explicitly adds these built-in vars to your schema.

# @useInferredVars(VARLOCK_ENV, VARLOCK_BRANCH)

Or a special infer() function which is only available on these vars. This is clean, although the automatic vars have more than just a value - description, type info, etc...

VARLOCK_ENV=infer()
VARLOCK_BRANCH=infer()

Open to ideas!

---

One other challenge here is that we may not always be able to infer when VARLOCK_ENV is test. This is because in some cases the test runner will automatically set NODE_ENV=test (or another similar env var) after varlock already loads the config. For example varlock run -- some-test-command .... It depends a bit on your test runner and the integration. For vite/vitest if you use the vite plugin instead of varlock run, it should work. The workaround when it cannot be set automatically is to just write VARLOCK_ENV=test varlock run -- your-test-cmd

---

Of course users can also be more explicit and construct their own env flag too - and we'll add a few more utility functions to make that more clear, especially with multi-line function calls now working.

[changeset-bot]

🦋 Changeset detected

Latest commit: 19c56cd

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 7 packages

Name	Type
@varlock/ci-env-info	Patch
varlock	Patch
@varlock/astro-integration	Patch
@varlock/nextjs-integration	Patch
@varlock/vite-integration	Patch
@varlock/1password-plugin	Patch
@varlock/google-secret-manager-plugin	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/dmno-dev/varlock/@varlock/ci-env-info@285

npm i https://pkg.pr.new/dmno-dev/varlock@285

commit: 19c56cd