@tamer4lynx/tamer-env
Rspeedy / Rsbuild plugin for loading .env files during rspeedy build and rspeedy dev, and injecting values into the Lynx bundle.
Why
The t4l bundle / native pipeline does not run lynx.config.ts with your shell environment the same way as local npm run build. Using pluginTamerEnv keeps env handling in one place and bakes public values into the bundle at compile time (same idea as explicit source.define, but driven by .env files).
Install
Included in t4l add-core, or:
The package ships ./tamer.config: when you use pluginTamer() in lynx.config.ts, tamer-plugin discovers @tamer4lynx/tamer-env in node_modules and merges pluginTamerEnv({}) (defaults).
To override options (or avoid registering the plugin twice), pass tamerEnv into pluginTamer — your instance wins over the package default:
To disable the bundled env plugin (e.g. you only use source.define by hand): pluginTamer({ tamerEnv: false }).
Usage
Minimal (defaults from the package only):
With custom options (recommended when you need defineFromEnv or non-default root):
process.env (prefixed)
By default, only variables whose names start with TAMER_PUBLIC_ are exposed as process.env.TAMER_PUBLIC_* in the bundle. Override the prefix with publicPrefix, or list extra keys with include.
__FOO__ compile-time globals
If your code uses injected globals (e.g. __OAUTH_CLIENT_ID__) instead of process.env, use defineFromEnv to map each global to an env var name, and optional envDefaults for fallbacks when a key is missing:
Values in source.define in lynx.config still override the plugin for the same keys (merge order: plugin first, then your config).
Files loaded
In order (later overrides earlier), when skipDotenv is not set:
.env.env.local.env.developmentor.env.production(fromNODE_ENV).env.<mode>.local
Then process.env wins over file values for any key set in the environment (CI, shell).
See also
- Configuration —
paths.lynxAdditionalBundlesfor multiple bundles witht4l start/t4l bundle - tamer-plugin — load
tamer.configinto Rsbuild
