Loxer - v3.0.0
    Preparing search index...

    Interface Modifiers<Delete>

    interface Modifiers<Delete extends string> {
        pp(
            options?: PropsPrinterOptions,
        ): LogMethods & Omit<Modifiers<Delete | pp>, Delete | pp>;
        printProps(
            options?: PropsPrinterOptions,
        ): LogMethods & Omit<Modifiers<Delete | pp>, Delete | pp>;
        h(doit?: boolean): LogMethods & Omit<Modifiers<Delete | h>, Delete | h>;
        highlight(
            doit?: boolean,
        ): LogMethods & Omit<Modifiers<Delete | h>, Delete | h>;
        m(moduleId?: string): LogMethods & Omit<Modifiers<Delete | m>, Delete | m>;
        module(
            moduleId?: string,
        ): LogMethods & Omit<Modifiers<Delete | m>, Delete | m>;
    }

    Type Parameters

    • Delete extends string
    Index
    •     Loxer.printProps().log('restoring order', payment)
      Loxer.printProps({ depth: 1 }).open('checkout', cart)
      Loxer.printProps().error(error, payment)

      Props are attached to every log that is called with them, and reach the output stream and the history whether or not this is chained. What it decides is whether the built-in console output renders them below the message, connected to the log's box column.

      • chaining it at all is the request: Loxer.printProps() and Loxer.printProps({}) render alike. The parameter carries formatting configuration, not the decision
      • a value is rendered whatever its truthiness, null and 0 included
      • it is a one-shot modifier like Modifiers.highlight and Modifiers.module: the next log renders nothing unless it chains this itself
      • a log without props renders no block
      • an output stream receives the raw lox inside its event and can render it with OutputLoxRenderer or PropsPrinter.of(lox).print(), reading lox.printProps to honor the request

      Parameters

      Returns LogMethods & Omit<Modifiers<Delete | pp>, Delete | pp>

    •     Loxer.highlight().log(...)
      Loxer.highlight().open(...)
      Loxer.highlight().of(...)
      Loxer.highlight().error(...)
      • by default the foregroundColor and backgroundColor of the log will be inverted.
      • an output renderer can select a highlight color with LoxerOutputRendererOptions.colors
      • the parameter doit?: boolean can conditionally highlight the log with true
      • this function can be chained with any other chaining function like .module(...)
      • highlighting error logs does not color the message differently but append the stack to the default console output

      Parameters

      • Optionaldoit: boolean

        should the log be highlighted

      Returns LogMethods & Omit<Modifiers<Delete | h>, Delete | h>

    •     Loxer.module(string).log(...)
      Loxer.module(string).open(...)
      Loxer.module(string).of(...)
      • if you don't chain this function the module is always NONE, which will lead the log to not have the box layout
      • if you chain the function without a parameter like Loxer.module().log(...) the module will be DEFAULT, which will lead the log to have a box layout but no name
      • both of the default modules can be overwritten at LoxerOptions.modules declared in Loxer.init(options)
      • modules can be defined at LoxerOptions.modules declared in Loxer.init(options)
      • this function can be chained with any other chaining function like .highlight(...)
      • the accepted ids are string by default. Augment the LoxerModuleRegistry to have them autocompleted and typo-checked against the modules of your project

      Parameters

      • OptionalmoduleId: string

        the key of the module from LoxerOptions.modules. undefined defaults to module "DEFAULT"

      Returns LogMethods & Omit<Modifiers<Delete | m>, Delete | m>