Merged
Conversation
🦋 Changeset detectedLatest commit: 3f23eaf The changes in this PR will be included in the next version bump. This PR includes changesets to release 11 packages
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 |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
theoephraim
force-pushed
the
varlock-env
branch
2 times, most recently
from
4a952a2 to
f2e3f12
Compare
@varlock/ci-env-info
@env-spec/parser
varlock
@varlock/1password-plugin
@varlock/aws-secrets-plugin
@varlock/azure-key-vault-plugin
@varlock/bitwarden-plugin
@varlock/google-secret-manager-plugin
@varlock/infisical-plugin
@varlock/astro-integration
@varlock/nextjs-integration
@varlock/vite-integration
commit: |
theoephraim
force-pushed
the
varlock-env
branch
from
f2e3f12 to
19c56cd
Compare
philmillman
approved these changes
Feb 26, 2026
Member
philmillman
left a comment
philmillman
left a comment
There was a problem hiding this comment.
Good to go once you've given it a final pass and resolved the conflicts @theoephraim
theoephraim
force-pushed
the
varlock-env
branch
from
19c56cd to
1e40f20
Compare
theoephraim
force-pushed
the
varlock-env
branch
from
31ad0fd to
413d33a
Compare
- Add reference/builtin-variables.mdx documenting all VARLOCK_* vars - Add sidebar entry with "new" badge - Add tip in environments guide pointing to VARLOCK_ENV auto-detect - Fix ci-env-info README: correct import path, complete API fields, add varlock context and supported platforms list - Fix ci-env-info package.json engine requirement Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
varlock-website | 3f23eaf | Commit Preview URL Branch Preview URL |
Feb 27 2026, 06:48 AM |
When a user defines a VARLOCK_* var explicitly (e.g., VARLOCK_ENV= to add decorators), the builtin auto-detection resolver now acts as a fallback. Empty static values are skipped in favor of the internal resolver, while explicit values (VARLOCK_ENV=production) still override. - registerBuiltinVar now attaches internal def to existing items - finishLoad scans for user-defined VARLOCK_* keys before processing - valueResolver skips empty static resolvers when internal fallback exists - Updated docs to clarify both usage patterns (reference vs direct define) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR explores the idea of automatically inferring a
VARLOCK_ENVthat tries to just magically be set to the right thing.The intention here is that you can use
# @currentEnv=$VARLOCK_ENVwithout 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/referenced.
The full list of magic vars for now is:
VARLOCK_ENV- development, preview, staging, production, testVARLOCK_IS_CI- true if we are in CIVARLOCK_BRANCH- branch name being tested/deployedVARLOCK_PR_NUMBER- PR number if this is a PR buildVARLOCK_COMMIT_SHA/VARLOCK_COMMIT_SHA- current commit sha long/short versionsVARLOCK_BUILD_URL- url where this will be deployedVARLOCK_REPO- current repo in "owner/repo" format (e.g.,dmno-dev/varlock)VARLOCK_PLATFORM- current platform name (eg, "Github Actions", "Cloudflare")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.
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...Open to ideas!
One other challenge here is that we may not always be able to infer when
VARLOCK_ENVistest. This is because in some cases the test runner will automatically setNODE_ENV=test(or another similar env var) after varlock already loads the config. For examplevarlock 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 ofvarlock run, it should work. The workaround when it cannot be set automatically is to just writeVARLOCK_ENV=test varlock run -- your-test-cmdOf 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.