OptionalactiveThe validation contexts active for this run (e.g. ["server", "production"]) -- entirely application-defined; env-cap never
detects or infers these, the caller always computes and passes them
explicitly. A variable whose context isn't in this list is skipped
entirely (no default/processor/validator runs for it, and it stays in
its not-ready state, exactly as if this run had never happened for
it) -- see ADR 0022. A variable with no context always participates,
regardless of what's passed here. Omitted (the default) behaves as an
empty list: only variables with no context participate.
Not part of the validation cache's identity -- validateEnv
remains one-shot per process exactly as before this option existed. A
second call does not re-evaluate activeContexts; it returns the
first call's result outright. Different active contexts belong to
different processes (e.g. a server process and a browser bundle),
never to two calls within the same one.
Every contract to validate -- typically the contracts array imported
from a generated manifest (see build.generateEnvManifest). Pass all of them
in one call: validateEnv only ever initializes once per process, so
a second call returns the first call's cached result without
re-running anything, even if it passes a different manifest.
The raw source of environment values, e.g. process.env or a resolved secrets bag.
env-cap runtime entry point.
Zero dependencies, isomorphic (no
fs, noprocessother than the values the developer passes in). Handles processing, validation, caching, and typed access only -- discovery and manifest generation live in@maverickcer/env-cap/buildand are never imported from here.documentEnvis exported from here, not@maverickcer/env-cap/build, even though it exists purely for documentation: it's meant to be called inline in the same schema file ascreateEnv, which is ordinary runtime code that may end up in any bundle (including a browser one). It must be exactly as cheap and safe to import ascreateEnv-- seedocument.ts.