config_manager 0.4.0

A JSON-based configuration manager with path-based access to nested values, singleton pattern, and mixin support.

0.4.0

• get becomes generic (get<T>(key, {sector})) across IConfigBase, ConfigManagerBase, and ConfigExtension. T defaults to dynamic when omitted, preserving existing call sites; when specified (e.g. get<String>(['appName'])), the value is cast to T before being returned. Since the underlying JSON carries no type information, a mismatched T throws a TypeError at call time rather than at compile time.
• set now enforces type consistency: writing a non-null value for a key whose type is already known (see below) and differs from it throws the new ConfigTypeMismatchException instead of overwriting it. Writing null, or writing to a key with no known type yet, is unrestricted.
• Add an optional per-sector type schema on IConfigManager: setSchema(schema, {sector}) registers expected types as a tree mirroring the configuration's shape (Type at the leaves, e.g. {'database': {'port': int}}), and typeOf(key, {sector}) queries it. set and every loadFromJson/loadFromString/loadFromMap call also extend the schema on their own with the runtime type of every non-null value they write or load — so the very first write or load for a key is enough to have it checked from then on, with no separate declaration needed. Each of those four calls validates against whatever schema is already known for the target sector before applying its own change, throwing ConfigTypeMismatchException on a mismatch. clear also removes the schema for the cleared sector(s). A schema leaf declared as dynamic opts that key out of checking entirely and is never overwritten by the type actually observed, so it stays unrestricted.

0.3.0

• Breaking: dot-notation String keys are removed. get, set, and containsKeys now take an explicit List<String> key path instead (e.g. ['database', 'host']), so a literal . inside a key name is never ambiguous with nesting. A single top-level key is a one-element list (['appName']); an empty list addresses the whole configuration map.
• operator []/operator []= accept the same List<String> path.

0.2.3

• Add isLoaded({sector}) to check whether a sector currently has a loaded configuration.
• Add containsKeys(keys, {sector}) to check whether a set of keys (with the same dot/list-index notation as get) are all present in a sector.
• loadFromJson, loadFromString, and loadFromMap accept a force parameter (defaults to true); when force: false and the target sector is already loaded, the call is a no-op.

0.2.2

• Extract shared load/read/write logic into ConfigManagerBase, an abstract IConfigManager implementation; ConfigManagerSingleton now extends it instead of duplicating the sector store. This lets consumers create their own non-singleton config managers with an independent default sector.
• set becomes generic (set<DataType>(key, data, {sector})) across IConfigBase, ConfigManagerBase, and ConfigExtension.
• The singleton's constructor now also tolerates a malformed default config.json, starting empty instead of leaving the singleton unconstructable.

0.2.0

• Add sector-based configuration: each sector holds its own configuration and operations accept an optional sector argument, falling back to the default sector when omitted.
• Introduce IConfigManager and IConfigBase interfaces, splitting the manager contract from the shared load/read operations.
• Simplify IConfigExtension to a marker interface over IConfigBase; value access is provided by the inherited get(key, {sector}).

0.1.0

• Initial release.
• JSON configuration file loading.
• Dot-notation access to nested values.
• List support with index access.
• Singleton-based configuration access.
• Mixin-based configuration extension.