Winston: O winston pode ser usado no front-end (ou seja, navegador) para registro?

Eu não tentei, mas isso pode ajudar https://github.com/farpoint/meteor-winston-client

Isso está relacionado a: https://github.com/flatiron/winston/issues/180

Tem 404 nesse link @joshacheson !!

Você tem algum progresso com este problema?

Com base no feedback de #582, parece que qualquer PR futuro precisaria se concentrar em separar a lógica principal e os transportes, em vez de usar shims como brfs . Essa seria uma grande mudança estrutural e quase certamente precisaria de orientação dos desenvolvedores principais sobre estilo e abordagem, pois eles serão os que continuarão mantendo isso.

A boa notícia é que o código é principalmente limpo e bem estruturado, mas precisaria de alguma orientação dos desenvolvedores principais sobre estilo e abordagem. @indexzero / @pose poderia compartilhar seus pensamentos?

Algum progresso com este problema?

Cara, tenho minhas esperanças muito altas quando vi o pacote e não notei nenhum suporte ao navegador.
Isso seria realmente incrível para mim no navegador para substituir algumas coisas caseiras.

+1

Igual ou eu. Ter a mesma biblioteca de log para frente e verso também ajuda.

Eu estava apenas navegando e parece uma pena que, embora tenha um transporte http, não pareça haver nenhum cliente padrão para o navegador/outro.

Triste que vou ter que usar bunyan

Alguma novidade sobre isso?

Se você realmente quiser usá-lo, basta escrever um transporte personalizado para ele, por exemplo:

const Transport = require('winston-transport');

export default class BrowserConsole extends Transport {
  constructor(opts) {
    super(opts);

    this.name = 'BrowserConsole';
    this.levels = {
        error: 0,
        warn: 1,
        info: 2,
        debug: 4,
    };

    this.methods = {
        error: 'error',
        warn: 'warn',
        info: 'info',
        debug: 'log',
    };

    this.level = opts.level && this.levels.hasOwnProperty(opts.level)
                  ? opts.level : 'info';
  }

  log(method, message) {
    setImmediate(() => {
      this.emit('logged', method);
    });

    const val = this.levels[method];
    const mappedMethod = this.methods[method];

    if (val <= this.levels[this.level]) {
      // eslint-disable-next-line
      console[mappedMethod](message);
    }
  }
}

Então você pode usá-lo desta forma:

import BrowserConsole from './BrowserConsole';

const { createLogger, transports } = require('winston');

const log = createLogger({
  level: 'info',
});

if (process.env.NODE_ENV !== 'production') {
  log.add(new BrowserConsole({
    level: 'info',
  }));
}

Com esse transporte, você recebe um aviso inútil porque é considerado um código herdado. Também seria bonito adicionar a possibilidade de usar outros métodos de console ( table , dir , trace , ...), mas por uma questão de simplicidade é como é.

Obrigado @chrisvoo , tentei esta solução, mas recebi um erro:

ReferenceError: Buffer is not defined
    replacer 
    json.js/module.exports< 
    _transform 
    _stream_transform.js/Transform.prototype._read
    _stream_transform.js/Transform.prototype._write
    doWrite
    writeOrBuffer
    _stream_writable.js/Writable.prototype.write
    log

@dmitry-salnikov Não sei, aliás, não consigo entender por que esse código está usando fluxos. Talvez meu caso de uso fosse muito simples. Tente compartilhar como você está usando.

@chrisvoo Eu copiei a implementação BrowserConsole para um arquivo separado, então em outro arquivo colei a segunda parte do código, e depois de adicionar o código de transporte BrowserConsole (a última linha do seu snippet) eu simplesmente tentei:

log.info('hello world');

Então eu recebi um erro e tentei:

log.log('info, 'hello world');

Ambas as chamadas retornam o mesmo erro.

Meu ambiente que possibilita o uso do Node no navegador é o Meteor.js v1.6 (Node 8.8.1). Também não modifiquei nenhuma linha do seu trecho de código.

BTW: Eu comecei a usar o winston não muito tempo atrás, então pode estar fazendo algo errado.

@dmitry-salnikov que tipo de erro você recebe? Como "informação não é uma função"? Talvez por algum motivo, seja mal importado.

@chrisvoo por favor dê uma olhada:

O conteúdo de BrowserConsole.js (você pode vê-lo na árvore de arquivos) é exatamente como no seu snippet.

E eu concordo com você, sinto que algo está errado com a importação, mas não consigo descobrir o porquê :( Você poderia compartilhar seus pensamentos sobre isso?

Qual é a sua versão do Winston? O meu é:

"winston": "^3.0.0-rc1",
"winston-transport": "^3.0.1"

Na verdade o mesmo

$ npm ls | grep winston
├─┬ [email protected]
│ └── [email protected]
└── [email protected]
$ cat package.json | grep winston
    "winston": "^3.0.0-rc1",
    "winston-transport": "^3.0.1"

Tentando resolver esse problema fiz outro teste:

import winston from 'winston';
import BrowserConsole from '/imports/BrowserConsole.js';

const format = winston.format;
// next line throws exception, see below
const { combine, timestamp, label, printf, colorize, prettyPrint } = format;

const logger = winston.createLogger({
...

e obtive o próximo erro: Cannot find module './combine'

Aqui está o rastreamento de pilha e o código relacionado (captura de tela do navegador):

Parece que algo é realmente mal importado. @chrisvoo poderia dar uma olhada?

No Winston 3.0.0, os transportes são fluxos. No entanto, no browserify-stream, readableStream instanceof Stream não é verdadeiro. Isso faz com que Winston volte a envolver o transporte em um invólucro Legacy e emitir um aviso. Fiz um PR para usar um método diferente para detecção de agilidade: #1145

@Jasu true, notei isso também, enviei um problema anteriormente em relação a isso no winston-transport . Também enviarei uma solicitação de pull em breve para que o transporte do console seja isomórfico.

IGNOREME: Estou comentando aqui para que eu possa encontrar facilmente esse problema novamente no futuro, [já que não posso fazer isso assinando sozinho](https://github.com/isaacs/github/issues/283).

Eu encontrei o mesmo problema, Error: Cannot find module './combine' .

+1

@chrisvoo : abaixo está o erro, quando tento executar seu trecho (winston e winston-transport estão em 3+ versões)
ERRO em winston-transport/index.js
Módulo não encontrado: Erro: Não é possível resolver 'stream' em node_modules/winston-transport'

há alguma chance de que o PR #1145 (aberto em novembro de 2017) seja fundido este ano? :piscar:

@dmitry-salnikov #1145 foi mesclado para master. Ainda não em um lançamento.

FECHADO FECHADO FECHADO.

Obrigado pelo apoio ya batatas

5 anos, pelo menos está se concretizando. Winston ainda é o melhor sistema de log para JavaScript IMO

Obrigado!

Isso permanecerá aberto até que haja testes em nosso conjunto de testes que verifiquem o suporte do navegador. Parece que a maioria dos casos de borda e canto em torno do babel & webpack foram resolvidos no entanto.

Aqui nós amamos winston e precisamos de um middleware de log do lado do cliente.

Um tempo se passou desde que o navegador foi implementado e gostaríamos de usá-lo a partir de agora.

Alguma ideia aproximada do suporte do navegador, antes de esperar os testes de unidade e a cobertura total do navegador?

Tentei importar o winston para o meu projeto e falhei com a seguinte mensagem:
ERRO em ./\~/winston/lib/winston/tail-file.js
Módulo não encontrado: Erro: Não é possível resolver 'fs' em '/Users/me/workspaces/app/node_modules/winston/lib/winston'
@ ./\~/winston/lib/winston/tail-file.js 10:11-24
@ ./\~/winston/lib/winston/transports/file.js
@ ./\~/winston/lib/winston/transports/index.js
@ ./\~/winston/lib/winston.js
@ ./src/app/app.module.ts
@ ./src/main.ts

winston's index.js import Transportes que importam '.file' que requerem 'fs'.

Como faço para cancelar a assinatura deste novo inferno

• Michael

Em terça-feira, 7 de agosto de 2018 às 14h19, Kfir Erez [email protected] escreveu:

Tentei importar winston para o meu projeto e falhou com o seguinte
mensagem:
ERRO em .//winston/lib/winston/tail-file.js
Módulo não encontrado: Erro: Não é possível resolver 'fs' em
'/Users/me/workspaces/app/node_modules/winston/lib/winston'
@ .//winston/lib/winston/tail-file.js 10:11-24
@ .//winston/lib/winston/transports/file.js
@ .//winston/lib/winston/transports/index.js
@ ./~/winston/lib/winston.js
@ ./src/app/app.module.ts
@ ./src/main.ts

winston's index.js import Transportes que importam '.file' que requerem
'f'.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/winstonjs/winston/issues/287#issuecomment-410946148 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AE3lcdZ3aQKEVYvYB2TXjh0dnQ1FaBS2ks5uOTFhgaJpZM4A2vjK
.

@mjcd você está preso aqui para sempre 😆 (j/k, você pode cancelar usando o link no e-mail ou via gh)

Eu tive o mesmo erro que o @KErez teve usando o webpack

Uma maneira comum de resolver isso é colocar node: { fs: 'empty' } na configuração do seu webpack -- e obviamente não tente usar o transporte File do navegador, não funcionará. Seria bom se pudéssemos fazer o pacote winston no webpack sem essa configuração extra, mas não sei se é possível. Outros pacotes populares recomendam a mesma coisa - embora https://github.com/pugjs/pug-loader/issues/8#issuecomment -328331541 sugira que poderíamos corrigir isso no package.json de winston. Alguém quer tentar isso e abrir um PR se resolver esse erro (ou seja, sem alterar a configuração do webpack do seu aplicativo, apenas alterando o package.json do winston)?

Eu estou recebendo um erro devido ao setImmediate... Não entendo porque já que @chrisvoo parece ter sucesso. Talvez porque você usa um polyfill?

Meu problema relacionado: https://github.com/winstonjs/winston/issues/1489

Fiz um pacote baseado no código @chrisvoo (thx tanto) aqui:
https://www.npmjs.com/package/winston-transport-browserconsole.

Além disso, há uma pequena amostra para que você possa comparar com a saída padrão do console winston.

Uma maneira comum de resolver isso é colocar node: { fs: 'empty' } na configuração do seu webpack

Existem planos para oferecer suporte a pacotes de navegador webpack sem a necessidade de fazer essa alteração na configuração do webpack?

Seria bom se pudéssemos fazer o pacote winston no webpack sem essa configuração extra, mas não sei se é possível. Outros pacotes populares recomendam a mesma coisa -- embora pugjs/pug-loader#8 (comentário) sugira que poderíamos corrigir isso no package.json do winston. Alguém quer tentar isso e abrir um PR se resolver esse erro (ou seja, sem alterar a configuração do webpack do seu aplicativo, apenas alterando o package.json do winston)?

@DABH Infelizmente, não acho que seja tão simples. Vocês usam o campo do navegador para definir um ponto de entrada diferente. Acredito que possa ser usado para definir um ponto de entrada diferente OU substituir determinados módulos, conforme descrito nesse ticket - não ambos. Mas como você já está construindo sua própria versão do navegador, talvez ela possa ser removida disso. Vou dar um pico se eu tiver uma chance neste fim de semana.

Algum progresso nisso? Já se passaram 6 anos e amanhã será 2020 :-)

Talvez a solução seja reembalar o winston para que os transportadores sejam próprios do módulo. Parece uma solução melhor

podemos usar Winston em angular? quão ?

@ArpithaGMGowda não com o CLI angular padrão

Então o que podemos usar para o Angular 7 ??
Qualquer ideia

Eu usei js-logger no meu último projeto que funcionou muito bem e me permite enviar logs para elk embora pareça que não teve muita atividade no ano passado: https://github.com/jonnyreeves/js-logger
Existem bons serviços de registro que também podem funcionar para você, como track.js

Estou reescrevendo esta biblioteca em uma nova estrutura que remove a dependência do node. Deve terminar na próxima semana

Problema com o Winston, o código baseado precisa ser modernizado sem quebrar os recursos principais.

A camada de transporte precisa ser dividida em seus próprios submoldes que, em troca, causarão mudanças de ruptura que acho que a equipe não quer causar. Ao ponto, a menos que a equipe esteja disposta a adotar um novo ecossistema. Não tenho certeza se o PR que está sendo reparado será aprovado.

você tentou com NGX-Logger " https://www.npmjs.com/package/ngx-logger "?

@ArpithaGMGowda Acho que, para mim, não gosto de escrever uma base de código que o vincule a uma estrutura definida. O código deve ser o mais agnóstico possível da interface do usuário para as chamadas de serviço. Também gosto da ideia de um mecanismo unificado. Por que ter um caminho para o backend e outro para o frontend

Estou reescrevendo esta biblioteca em uma nova estrutura que remove a dependência do node. Deve terminar na próxima semana

@Jordan-Hall Gostaria de saber se teremos um rc em breve (e obrigado).
Ter que modificar webpacks de terceiros para não quebrar quando eles usam nosso projeto/lib que usa winston está lutando.

@MarcoMedrano É uma mudança fundamental que, em teoria, seria uma nova biblioteca quando eu a terminasse.

@pose Qual é a sua opinião sobre a divisão das camadas de transporte do pacote principal? Eu gosto de Winston, mas o sistema ecológico precisa mudar

Demorou um pouco para escrever isso, mas eu encontrei uma solução um tanto razoável para isso.
O seguinte permitirá que você use os níveis de erro, aviso e informação no navegador (com prefixos personalizados !), e eles ficarão assim:

Para que isso funcione, você precisa instalar winston , logform e winston-transport como dependências.

Aqui está o código que você precisa para implementar isso.
Observe que isso está escrito em typescript, o exemplo de javascript está abaixo.

import * as winston from 'winston';
import {TransformableInfo} from 'logform';
import TransportStream = require('winston-transport');

// enumeration to assign color values to
enum LevelColors {
  INFO = 'darkturquoise',
  WARN = 'khaki',
  ERROR = 'tomato',
}

// type levels used for setting color and shutting typescript up
type Levels = 'INFO' | 'WARN' | 'ERROR';

const defaultColor = 'color: inherit';

//! Overriding winston console transporter
class Console extends TransportStream {
  constructor(options = {}) {
    super(options);

    this.setMaxListeners(30);
  }

  log(info: TransformableInfo, next: () => void) {
    // styles a console log statement accordingly to the log level
    // log level colors are taken from levelcolors enum
    console.log(
      `%c[%c${info.level.toUpperCase()}%c]:`,
      defaultColor,
      `color: ${LevelColors[info.level.toUpperCase() as Levels]};`,
      defaultColor,
      // message will be included after stylings
      // through this objects and arrays will be expandable
      info.message
    );

    // must call the next function here
    // or otherwise you'll only be able to send one message
    next();
  }
}

// creating silent loggers with according levels
// silent by default to be automatically deactivated
// in production mode
export const logger = winston.createLogger({
  transports: [
    new Console({
      silent: true,
      level: 'info',
    }),
  ],
});

// don't log anything in production mode
// probably should go further and return non
// working logger function to reduce
// execution time and improve speed results
// on application
if (process.env.NODE_ENV !== 'production') {
  logger.transports.forEach(transport => (transport.silent = false));
}

e aqui está o exemplo de javascript

import * as winston from 'winston';

import {TransformableInfo} from 'logform';
import TransportStream = require('winston-transport');

// enumeration to assign color values to
const LevelColors = {
  INFO: 'darkturquoise',
  WARN: 'khaki',
  ERROR: 'tomato',
}

const defaultColor = 'color: inherit';

//! Overriding winston console transporter
class Console extends TransportStream {
  constructor(options = {}) {
    super(options);

    this.setMaxListeners(30);
  }

  log(info, next) {
    // styles a console log statement accordingly to the log level
    // log level colors are taken from levelcolors enum
    console.log(
      `%c[%c${info.level.toUpperCase()}%c]:`,
      defaultColor,
      `color: ${LevelColors[info.level.toUpperCase()]};`,
      defaultColor,
      // message will be included after stylings
      // through this objects and arrays will be expandable
      info.message
    );

    // must call the next function here
    // or otherwise you'll only be able to send one message
    next();
  }
}

// creating silent loggers with according levels
// silent by default to be automatically deactivated
// in production mode
export const logger = winston.createLogger({
  transports: [
    new Console({
      silent: true,
      level: 'info',
    }),
  ],
});

// don't log anything in production mode
// probably should go further and return non
// working logger function to reduce
// execution time and improve speed results
// on application
if (process.env.NODE_ENV !== 'production') {
  logger.transports.forEach(transport => (transport.silent = false));
}

Você pode alterar as cores na enumeração LevelColors. Se você quiser alterar a formatação, dê uma olhada na linha 29.

Para adicionar suporte para o nível de depuração. defina level nas opções do console para 'debug' .
Também é possível adicionar suporte para todos os níveis padrão do winston, ou seja: emerg, alert, crit, error, warning, info e debug. Se você quiser usá-los também, você precisa adicionar atribuir este objeto à configuração levels na raiz createLogger

{
   emerg: 0,
   alert: 1,
   crit: 2,
   error: 3,
   warn: 4,
   info: 5,
   debug: 6,
}

e, em seguida, adicione os valores de cor na enumeração LevelColors.

Estou lutando para obter uma imagem clara do status deste problema. Posso usar o Winston no meu aplicativo React?

Na verdade, não estou muito interessado em fazer login no console do navegador - e, honestamente, não entendo o ponto de substituir um winston console transporter quando o console embutido serve ao mesmo propósito ; talvez alguém possa gentilmente me esclarecer.

Minha situação é que meu aplicativo React é executado em um contêiner do Docker atrás de um proxy nginx / Let's Encrypt, então não tenho acesso a nenhuma saída do console JavaScript; Portanto, gostaria de encaminhar qualquer saída de log para um servidor syslog.

Configurei com sucesso um contêiner do Docker syslog-ng que consolida a saída de log do banco de dados, back-end e alguns outros contêineres dos quais meu projeto é feito, mas não consigo encontrar uma abordagem direta / canônica para syslogging saída do frontend do React.

Antes de eu hackear alguma solução caseira idiota, alguém tem algum conselho melhor para mim?
Talvez pegue o código acima e substitua console.log por algum código que envie a mensagem pela rede para o servidor syslog?

@z00m1n Depende principalmente do seu caso de uso. Eu uso winston no navegador para registrar todas as solicitações e chamadas de função que faço. E se estou em um ambiente de produção, limito a saída a apenas erros de impressão.

E usar meu código e trocar a instrução console.log por outra coisa funcionaria.

No entanto, antes de escrever uma solução hacky para fazer isso funcionar, eu proponho usar sentry.

Também depende se você tem controle sobre o webpack. Infelizmente, este pacote incrível está desatualizado arquitetonicamente, o que torna impossível resolver verdadeiramente

@Keimeno você notou algum comportamento estranho ou problemas de desempenho? Realmente quero usar, mas tem que ser super estável, pois alguns registros acontecerão em produção para o meu caso de uso ...

@gcperrin Não tenho certeza se você pode chamar isso de problema de desempenho, mas tenho executado alguns benchmarks e obtive os seguintes resultados:
ambiente dev: registra algo no console
ambiente prod: não registra algo, mas chama a função log

_console.info (ambiente de desenvolvimento)_; 1.863s para 10.000 logs. (0,1893ms cada)
_logger.info (ambiente dev)_: 7.980s para 10.000 logs. (0,7980ms cada)

_logger.info (ambiente de produção)_; 3.731s para 10.000 logs. (0,3731ms cada)

Isso significa que se você usar minha função para silenciar os loggers em produção, ainda terá código síncrono rodando por 0,3731ms (potencialmente ainda maior). Pode não ser um problema de desempenho, mas se você tiver algumas centenas de logs silenciosos na produção, isso poderá causar atraso no aplicativo da web.

Alguma maneira de usar o winston para persistir no sistema de arquivos no lado do navegador?

Eu tenho um aplicativo React e quero armazenar os logs do lado do cliente no sistema de arquivos. Por favor, gentilmente sugerir alguns pensamentos.

Desde já, obrigado.