Skip to content

createLogger's enabled default makes an absent option mean on #72

Description

@shellicar

enabled defaults to true, so a level whose option is absent logs rather than staying quiet:

const createLogMethod = (level, color, abbrev, enabled = true) => enabled ? log : () => {};

verbose: createLogMethod('debug', colors.blue, 'VERB', options.verbose),
debug:   createLogMethod('debug', colors.gray, 'DEBG', options.debug),
info:    createLogMethod('info', colors.green, 'INFO'),

createLogger({ prefix: 'x' }) returns a logger that writes at debug and verbose level, though both are optional in LoggerOptions and absent reads as off to anyone calling it.

The default exists for info, warn and error, which are always on and pass no argument. verbose and debug pass an option that may be absent, and inherit a default meant for the other case. One default cannot serve both.

build-graphql has the same logger, arrived at independently before these packages shared a repo, and does not have this problem. It decides at the call site instead of in the helper:

debug: options.debug ? createLogMethod('debug') : () => {},
error: createLogMethod('error'),

The option is read where it is known, so absent means off, and the always-on levels simply don't ask. Which suggests moving the decision out of the parameter rather than changing what the parameter defaults to.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    internalNo user-facing effect — refactoring, internal correctness, unreachable code pathspkg: build-cleanBuild plugin — cleans unused output files

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions