Skip to content

FAQ

Is Configuard Tied to a Particular Database?

Section titled “Is Configuard Tied to a Particular Database?”

No. It works with a plain array of IConfigItem rows. A config table is the typical source, but where they come from — MySQL, Postgres, SQLite, a JSON file — is up to you. The reference schema is just a convenient shape.

So backend code can’t mutate live config by accident. The object is deep-frozen by default; pass { lock: false } if you genuinely need a mutable result.

No — both must be synchronous. The build and serialize paths are synchronous end to end. If your KMS is async, fetch/decrypt the values before handing the rows to Configuard.

Yes. serializeFlat() validates each edited value against its type and options, enforces editable, and throws a ConfiguardError on anything invalid — it is validate-then-store, not store-then-hope.

Construction throws immediately. Configuard never silently skips a bad row or builds a partial object.

Configuard is built on notation — that’s what turns a dotted key (device.ui.accent) into a nested property, and backs .get() / .has(). You don’t interact with notation directly.

Can I Filter the Built Object Further, per Role?

Section titled “Can I Filter the Built Object Further, per Role?”

Yes. Configuard’s ABAC decides which rows a client receives. For property-level filtering on top of that, combine it with accesscontrol.

It Won’t Import — “ERR_REQUIRE_ESM” / “cannot use import”

Section titled “It Won’t Import — “ERR_REQUIRE_ESM” / “cannot use import””

Configuard is ESM-only. See this note on consuming ESM packages.