# confederate

> Narrow road conf-loader suitable for confederates of apps (for instance suits of microserviceses). Dead simple story.

Latest version **0.9.1** (published 2019-03-23) · ISC license · 0 weekly downloads

## Install

```sh
npm install confederate
pnpm add confederate
yarn add confederate
bun add confederate
```

## Health

**Score 25/100 (F)** — status: abandoned.

Positive: has types; no vulnerabilities; high quality score.

Warnings: low downloads; no esm support; pre 1.0.

Negative: abandoned; low maintenance score.

## Facts

| | |
|---|---|
| Version | 0.9.1 |
| Published | 2019-03-23 |
| First published | 2018-02-16 |
| Weekly downloads | 0 |
| License | ISC |
| TypeScript types | bundled |
| Module format | CommonJS |
| Dependencies | 2 |
| Unpacked size | 18.1 KB |
| Known vulnerabilities | 0 |
| Install scripts | no |
| Author | Oscar Campbell / Wace Dev Team |
| Maintainers | ozra |

## Links

- npm: https://www.npmjs.com/package/confederate
- npm.io page: https://npm.io/package/confederate

## Dependencies (2)

- [chalk](https://npm.io/package/chalk.md) ^2.4.1
- [cabler](https://npm.io/package/cabler.md) ^0.8.1

## Recent versions

- 0.9.1 (latest) — 2019-03-23
- 0.8.9 — 2018-03-31
- 0.8.8 — 2018-03-02
- 0.8.7 — 2018-02-16

## README

## Confederate - Tight Conf Loader ##

### Why? ###

We wanted the init of apps tiny and tight. We wanted it aimed at suits of microservices.

Every app has a name configured in code. That's used for identification in logging, and for specific conf file - when needed. Confederate utilizes that. It also looks for a common conf. They're merged — with top-level keys granularity only. That's it. Because "fancy and elaborate" complex chains of inheritence, variable expansion and merging have _avsolutely no place_ in app-confs at run-time. _When_ you need that, you solve it in a conf-build stage. You want to catch problems at build time, not at deploy-time on server, with it's invariably differing setup compared to your dev-situation. Also, we all love yaml, etc — but again, that convenience saves no time in a deployed conf situation. For that: again, add a build-stage for the confs! Don't be lazy in the wrong places!

### Details? ###

It's picky. Pass `my-app --conf the-conf-dir`, `my-app --conf=the-conf-dir` or `CONF=the-conf-dir my-app`. A specific conf-file-path be passed instead of dir.
With the dir, it looks for "the-conf-dir/common-defaults.conf.json" and "the-conf-dir/the-app-name.conf.json" and merges them at _top-level keys granularity only_ — yes, that's a feature — with the app-specific properties naturally taking precedence.

It's written in TypeScript for buildtime insurances.

### In progress... ###

More details to come — and changes. The goal is to reduce it to the least possible amount of code. Don't use this until v1.0.0, you've been warned.

---
_Source: https://npm.io/package/confederate · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._
