-
Notifications
You must be signed in to change notification settings - Fork 11
basic @import implementation #147
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
Conversation
🦋 Changeset detectedLatest commit: a518f3f The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 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 |
Deploying with
|
Status | Name | Latest Commit | Preview URL | Updated (UTC) |
---|---|---|---|---|
✅ Deployment successful! View logs |
varlock-website | a518f3f | Commit Preview URL Branch Preview URL |
Sep 19 2025, 05:45 AM |
50fdb67
to
f88aa0a
Compare
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
@env-spec/parser
varlock
@varlock/astro-integration
@varlock/nextjs-integration
@varlock/vite-integration
commit: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
give the docs I added a once over and feel free to edit!
This PR is a first implementation of a new
@import
decorator, which allows explicitly importing more data sources (.env files). This will be especially useful in large projects where you want to break up a large .env file, or in a monorepo, where you want shared info at the root, or to pick specific items from a relevant sibling service - single source of truth!!This also starts opening up the door for pre-made schemas for popular platforms and libraries -- e.g. all the env vars injected by vercel, or the env vars that a particular tool/library will be looking for.
--
In order to do this, we did a lot of refactoring around data sources, and moved the logic of automatically loading
.env.*
files into a new "directory data source". This is so that we can explicitly import a directory, and have all the appropriate files loaded. This also forced me to rework how@envFlag
is handled.Some notes:
.env.local
in test mode. We contemplated mimicking this behaviour, but ultimately decided to follow Vite's lead (and load it), but provide a way to explicitly follow that pattern with# @disable=forEnv(test)
WEB_ENV
andAPI_ENV
, and still pull the staging api url into a dev web build. This works by walking up the parent chainNext steps for imports: