Remote @import

[theoephraim]

Varlock now supports @import() to import schema/values from local files. This lets us share config across monorepos, break up large schemas, or even pull data from locations outside the repo, for example from your home folder.

The next step here is to support importing from remote sources, which we plan to do in a style similar to Deno. This opens the door for publishing pre-built detailed schemas of config, which end users can then reuse. Imagine if all the PaaS services published these env vars in a standardized way with links back to their docs.

It's important that we don't exclusively rely on loading only local files from package.json dependencies / node_modules, because in a non-JS repo, the user may be using the binary, and neither of those things would exist!

• We'll need a location to cache these downloaded files, likely the ~/.varlock directory, which we are already using for some global config, and can also be use for more caching in the future (ie plugins, fetched values)
• We'll need to decide on caching behaviour - does it cache forever? For N seconds? Configurable?
• How to think about integrity checks? Probably let the user add hash, similar to corepack ie "packageManager": "yarn@3.2.3+sha224.953c8233f7a92884eee2de69a1b92d1f2ec1655e66d08071ba9a02fa"
• While importing remote schemas could be considered a security risk, for now if it's only schema info, there is no risk. We'll need to be more careful here if we start thinking about remote sources that could then introduce plugins, etc...

Remote sources

URL

@import(https://env-schemas.varlock.dev/platforms/.env.vercel)

• in this case, a directory is probably not supported?

Package registry (npm/jsr/etc)

@import(npm:package-name@1.2.3/.env.file)

• do you have to specify a file path? or could we check the package.json, and then have some default behavior (like a directory)?

Other??

We will also probably want to allow importing values/schema from specific integrations, but I'm not sure yet whether these would use @import() or would be some other mechanism. For example, lets say you wanted to fetch an item from 1Password, and apply all fields found as values, setting any field set as a "password" type to be sensitive.

Formats

For now, we're talking about importing only .env/@env-spec files, but you can easily imagine loading other file formats into the system, for example json/yaml/toml. It could be that these formats only support values, or that there is a pre-set data shape that allows setting more, or eventually that even comments could be parsed in a similar way to how we handle .env files. You can also imagine creating a JS/TS file that gets executed and loaded somehow, much like DMNO.

• This would likely rely on the (future) plugin system as well to register handlers for these file types, so that we can keep the core very small. But maybe json and js/ts could be handled natively?
• you could infer file type purely from the file name (env.json) or you could imagine explicitly setting the format during the import @import(./some-path, format=toml)

---

Any thoughts? Ideas?