Skip to content

v0.0.14

v0.0.14: feat: add loggerKey + loggerPath convenience to shouldLog
@jdwyah jdwyah tagged this 23 Apr 13:25 
Add an additive, Reforge-style higher-level log-level API on top of the
existing shouldLog({configKey, ...}) primitive.

Design:
- New constructor option `loggerKey` (e.g. "log-level.app-quonfig") stored
  on the Quonfig instance and inherited by BoundQuonfig.
- New shouldLog({loggerPath, desiredLevel, defaultLevel?, contexts?}) overload
  on both Quonfig and BoundQuonfig. Internally uses the init-time loggerKey
  as the configKey and injects the logger path into contexts under
  `contexts["quonfig-sdk-logging"] = { key: loggerPath }`.
- The "quonfig-sdk-logging" context name and nested `key` property are load-
  bearing: the existing example-context telemetry auto-captures contexts
  that carry a `key`, so logger paths flow to the dashboard for free.
- No normalization. Native identifiers such as "MyApp::Services::Auth" are
  passed through unchanged; authors write rules against the exact shape they
  log. (sdk-node never normalized; sdk-ruby did and is being removed.)
- The existing shouldLog({configKey, ...}) primitive is untouched and
  remains the escape hatch.
- Calling shouldLog({loggerPath}) without setting loggerKey at init throws a
  clear error steering the caller to either configure loggerKey or use the
  configKey form.

Exports QUONFIG_SDK_LOGGING_CONTEXT_NAME as a convenience constant.

Version bumped 0.0.13 -> 0.0.14. Non-breaking for 0.0.13 callers.
Assets 2
Loading