Qual é o recurso?

Esta é uma proposta de manipulação diferenciada de objetos (JSON/array/other) para casos de uso mais versáteis.

Em suma, esta proposta abrange duas coisas.

1. Dividir a análise info.meta de logform.splat
2. Crie uma nova transformação que mova objetos para options.meta

Qual problema o recurso pretende resolver?

Vários usuários (por exemplo, #1377, #1381, eu mesmo) notaram que o tratamento de objetos/matrizes é diferente em V3 de V2. Na V2 esses tipos de objetos seriam armazenados no campo options.meta e poderiam ser processados ​​separadamente da mensagem, nível e objetos.

Na V3, há apenas um cenário/transformação em que options.meta é processado da mesma forma que na V2. Isso ocorre ao usar a transformação logform.splat. O Splat analisará corretamente o meta somente quando um token estiver presente no log. POR EXEMPLO:
logger.log('info', 'this is a string I want to splat %s', 'together', {an: 'object'})
vai resultar em:
info: this is a string I want to splat together {"meta":{"an":"object"}} // with .simple() transform

Se os usuários não quiserem usar o logform.splat, o info.meta não será processado. Em vez disso, os objetos meta serão deixados intocados em info[SPLAT].

Adicionar um formulário de log que copia todas as informações[SPLAT] para info[meta] atenderá às expectativas dos usuários da V2 e será mais flexível. (Como alternativa, adicionar diretamente o info[SPLAT] à saída do registrador e fornecer documentação sobre info[meta] => info[SPLAT] pode ser aceitável.)

Uma nova transformação (por exemplo, logform.captureAllMeta apenas para nomear) pode ser tão simples quanto:

// file captureAllMeta.js psuedo-code

module.exports = transform((info, opts) => {
  if (info[SPLAT]) {
    info.meta = info[SPLAT]
  return info;
});

O equivalente de

format.combine(
        format.splat(),
        ...
    )

se tornaria

format.combine(
        format.splat(),
        format.captureAllMeta(),
        ...
        // still need to have a formatter for options.meta.  maybe a separate feature request.
    )

O código extraSplat pode ser removido de splat(), pois é tratado na transformação subsequente (nova).

Um benefício adicional é que, se os usuários não quiserem usar format.splat(), eles ainda poderão incluir format.captureAllMeta() como uma transformação independente.

A ausência desse recurso está bloqueando você ou sua equipe? Se sim, como?

Agora sabendo que info[SPLAT] armazena o que está faltando em info[meta], isso pode ser considerado uma lacuna de conhecimento/documentação.

Esse recurso é semelhante a um recurso existente em outra ferramenta?

Estende a compatibilidade V2 para V3.

Este é um recurso que você está preparado para implementar, com nosso suporte?

Sim, eu posso fazer o meu melhor para apoiar isso.

Para reproduzir o problema

• _ winston versão?_
  
  
  
  • [ ] winston@2
  
  
  • [X] winston@3
  
  
• _ node -v saídas:_ 6.10.0
• _Sistema Operacional?_ (Windows, macOS ou Linux) Qualquer
• _Idioma?_ (todos | TypeScript XX | ES6/7 | ES5 | Dart) todos

Qual é o problema?

Aqui está uma amostra de um código de transporte V2 com saída:

        logger = winston.createLogger({
            transports: [
                new (winston.transports.Console)({
                    timestamp: function () {
                        return dateFormat(Date.now(), "HH:MM:ss.l");
                    },
                    formatter: function (options) {
                        // Return string will be passed to logger.
                        return options.timestamp() + ' ' + winston.config.colorize(options.level, options.level.toUpperCase()) + ' ' + (undefined !== options.message ? options.message : '') +
                            (options.meta && Object.keys(options.meta).length ? '\n\t' + JSON.stringify(options.meta) : '');
                    },
                    colorize: true,
                    level: container.settings.get('logLevel') || 'info',
                    stderrLevels: [],
                    handleExceptions: true,
                    humanReadableUnhandledException: true
                })
            ]
        });


// results of Winston<strong i="33">@2</strong>
08:31:30.363 DEBUG Server starting complete.
        ["Server https started.","Server http started.","Server SSDP started.","Server MDNS started."]

Na V3, tentei replicar isso com o código a seguir, mas o resultado não exibiu o array.

    const processObj = logform.format(info => {
             console.log('raw: ', raw)
            return info
        }
    )

    const myFormat = printf(info => {
        info.timestamp = dateFormat(Date.now(), "m/d/yy HH:MM:ss.l")
        return `${info.timestamp} ${info.level}: ${info.message}`;
    });

        logger = createLogger({
            level: container.settings.get('logLevel') || 'info',
            format: combine(
                processObj(),
                format.json(),
                timestamp({format: () => new Date().toLocaleString()}),
                format.colorize(),
                format.align(),
                format.splat(),
                myFormat
            ),
            transports: [new transports.Console()]
        });
        logger.exceptions.handle()
        logger.exitOnError = false;

results = [ 'Not starting https server.', 'Server http started.', 'Server SSDP started.', 'Server MDNS started.']
logger.debug('Server status', results)

// results of winston<strong i="6">@3</strong> -- missing the results array
6/25/18 08:16:30.501 debug:     Server starting complete.