Configorama adds variable support to configuration files so environment-specific values can be composed without turning every config into custom JavaScript.
It is the kind of utility that comes from building repeatable systems: keep the config readable, make the dynamic parts explicit, and let the same structure work across local, staging, and production environments.
This repo is a pnpm + lerna monorepo. The published packages live under packages/.
| Package | npm | What it is |
|---|---|---|
configorama | configorama | Variable support for configuration files (the core library + CLI + bundled plugins) |
@davidwells/configx | @davidwells/configx | Resolve a configorama config and run a command with it as environment |
The configorama README (usage, syntax, plugins, API) is in packages/configorama/README.md.
pnpm install # links the workspace (configx uses the local configorama)
pnpm test # run every package's tests (pnpm -r test)
pnpm -r --if-present typecheckPer package:
cd packages/configorama && npm test
cd packages/configx && npm testBecause it's a workspace, configx depends on configorama via workspace:^, so changes to the core are picked up locally without publishing.
Independent versioning per package (see lerna.json). Versions are chosen from conventional-commit messages (feat: → minor, fix: → patch).
Both packages changed — coordinated release:
pnpm run release # lerna publish: versions, tags, and publishes changed packages in orderOne package changed — publish just that package (avoids re-versioning the other):
cd packages/configx && pnpm version patch && pnpm publish && git push --follow-tagsTwo rules that keep releases correct:
npm publish. Only pnpm/lerna rewrite workspace:^ to a real version range in the tarball; npm publish would ship a literal workspace:^ and break installs.pnpm publish must be followed by a matching git tag (<name>@<version>), or lerna's history drifts behind npm and the next lerna publish gets confused.See AGENTS.md for contributor rules (stdout hygiene, type checks, layout).