python-dotenv is a production-grade Python library that reads key-value pairs from .env files and sets them as environment variables, following the 12-factor configuration principles. It is widely used in development and deployment workflows to separate configuration from code. The library provides both programmatic APIs and a command-line interface for managing environment variables without manual file editing. The architecture centers on the `DotEnv` class, which orchestrates parsing, variable interpolation, and environment loading. Parsing is handled by a custom streaming parser (`parser.py`) that uses a `Reader` with position tracking and regex-based tokenization to handle single/double quoted values, comments, escape sequences, and UTF-8 BOM stripping. Variable expansion (`variables.py`) implements POSIX-style `${VAR:-default}` interpolation using an `Atom` abstract base class with `Literal` and `Variable` strategies. The core library has zero external dependencies; the CLI (built on `click`) and IPython integration are optional extras. Key entry points include `load_dotenv()` (loads .env into `os.environ`), `dotenv_values()` (returns a dict without touching the environment), `set_key()`/`unset_key()` for programmatic file manipulation, and `find_dotenv()` for locating .env files. The CLI offers `list`, `get`, `set`, `unset`, and `run` subcommands, with support for JSON/shell/export output formats. The IPython `%dotenv` magic provides interactive loading. Data flows from file or stream through the parser into an ordered dict, with optional interpolation and override control. External dependencies are minimal: `click` for the CLI, `IPython` for the magic extension, and standard library modules (`os`, `io`, `re`, `tempfile`, `pathlib`, etc.). The library supports Python 3.10–3.14 (including free-threaded 3.14t) and PyPy 3.11, with comprehensive CI testing across Linux and Windows.
dotenv.net is a lightweight .NET library for loading environment variables from .env files. It provides both a static API (DotEnv.Load, DotEnv.Read) and a fluent builder (DotEnv.Fluent) for configuring options such as file paths, encoding, trimming, overwrite behavior, directory probing, export syntax support, inline comment stripping, and variable expansion/interpolation. The library supports hierarchical environment cascade loading (e.g., .env, .env.local, .env.{Environment}) and integrates with Microsoft.Extensions.Configuration via a separate package (dotenv.net.Configuration). Internally, it consists of a parser that handles single/double quoted values, multi-line values, and escape sequences; a variable expander that resolves ${VAR}, $VAR, and default fallback syntax with circular dependency detection; and a reader that reads from files or streams, probes parent directories, and merges key-value pairs. The codebase is well-structured with comprehensive unit tests covering edge cases, and targets netstandard2.0/2.1 for broad compatibility.
Viper is a mature, widely-used Go configuration library that provides a unified API for reading configuration from multiple sources: files (YAML, JSON, TOML, dotenv), environment variables, command-line flags (via pflag), remote key-value stores (etcd, Consul, Firestore, NATS), and explicit overrides. It implements a priority-based merging system where later sources override earlier ones. The library offers nested key access with dot notation, aliasing, live file watching, and unmarshaling to structs via mapstructure. The architecture is a single Viper struct with internal maps for each source, plus a pluggable encoding layer and a finder interface for config file discovery. It is designed as a library to be embedded in Go applications, not as a standalone service.
react-native-config is a native module library that exposes environment variables from a .env file to React Native applications on iOS, Android, macOS, and Windows. At build time, platform-specific scripts (Ruby for iOS/macOS, Gradle for Android, Node.js for Windows) parse the .env file and inject the key-value pairs as generated constants — BuildConfig fields on Android, a #define'd NSDictionary on iOS, and C++ string constants on Windows. At runtime, a single JavaScript entry point (index.js) calls a synchronous TurboModule method (getConfig()) to retrieve the config object, which is then exported as the default 'Config' constant. The library supports per-environment configurations via ENVFILE or per-build-configuration settings, and includes thorough diagnostics: if the .env file is missing or empty, the runtime logs a detailed message naming exactly which paths were tried. The codebase is well-structured across all four platforms, with a strong test suite for the iOS codegen scripts (Ruby Minitest) and a clean separation between build-time codegen and runtime reading.
This repository is `@nuxtjs/dotenv`, a small Nuxt.js (v2) build-time module that reads a `.env` file, parses it with the `dotenv` library, and injects the variables into Nuxt's `this.options.env`. Nuxt then exposes those values to the application through `process.env` and `context.env`. The module supports custom filenames, custom paths, an allowlist via the `only` option, and optional merging of system environment variables via `systemvars`. It deliberately does not override environment values already defined in `nuxt.config.js`, and it warns instead of crashing when no `.env` file is present. Architecturally this is a tiny npm library, not an application or data pipeline: the core is a single Nuxt module function in `lib/module.js` plus a `consola`-based logger in `lib/logger.js`. It is invoked during Nuxt builds and has no CLI, web server, or long-running process. The test suite uses `@nuxtjs/module-test-utils` to boot fixture Nuxt applications and assert on rendered HTML, covering basic loading, custom file names, custom paths, missing files, and the `only` allowlist behavior. The code is clean, well-tested, and easy to understand, but the surrounding ecosystem has moved on. Nuxt 2 is end-of-life, and the README itself recommends migrating to Nuxt's built-in runtime config. Dependencies such as `dotenv@^8.2.0` and Nuxt 2 edge are old, and the project is effectively in maintenance limbo despite occasional repository activity.