Winston: ¿Se puede usar winston en el front-end (es decir, en el navegador) para iniciar sesión?

No lo he probado, pero esto podría ayudar https://github.com/farpoint/meteor-winston-client

Esto está relacionado con: https://github.com/flatiron/winston/issues/180

¡¡Hay 404 en ese enlace @joshacheson !!

¿Tienes algún progreso con este problema?

Según los comentarios del n.º 582, parece que cualquier RP futuro debería centrarse en separar la lógica central y los transportes, en lugar de usar correcciones como brfs . Este sería un gran cambio estructural y casi con seguridad necesitaría la orientación de los desarrolladores principales sobre el estilo y el enfoque, ya que en última instancia serán ellos quienes lo mantengan.

La buena noticia es que el código es en su mayoría limpio y bien estructurado, pero necesitaría alguna orientación de los desarrolladores principales sobre el estilo y el enfoque. ¿Podría @indexzero / @pose compartir sus pensamientos?

¿Algún progreso con este problema?

Hombre, tenía muchas esperanzas cuando vi el paquete y luego noté que no era compatible con el navegador.
Esto sería realmente increíble para mí en el navegador para reemplazar algunas cosas de cosecha propia.

+1

Igual o yo. Tener la misma librería de registro para el anverso y el reverso también ayuda.

Estaba navegando por esto y parece una pena que, aunque tiene un transporte http, no parece haber ningún cliente estándar para el navegador/otro.

Triste que tendré que usar bunyan

¿Alguna noticia sobre esto?

Si realmente desea usarlo, puede escribir un transporte personalizado para él, por ejemplo:

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);
    }
  }
}

Entonces puedes usarlo de esta manera:

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',
  }));
}

Con este transporte, obtiene una advertencia inútil porque se considera un código heredado. También sería hermoso agregar la posibilidad de usar otros métodos de consola ( table , dir , trace , ...), pero por simplicidad es como es.

Gracias @chrisvoo , probé esta solución pero obtuve un error:

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 No sé, por cierto, no puedo entender por qué este código usa transmisiones. Tal vez mi caso de uso era demasiado simple. Intenta compartir cómo lo estás usando.

@chrisvoo Copié y pegué la implementación de BrowserConsole en un archivo separado, luego, en otro archivo, pegué la segunda parte del código, y después de agregar el código de transporte BrowserConsole (la última línea de su fragmento) simplemente he intentado:

log.info('hello world');

Luego recibí un error e intenté:

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

Ambas llamadas devuelven el mismo error.

Mi entorno que hace posible el uso de Node en el navegador es Meteor.js v1.6 (Node 8.8.1). Además, no he modificado ninguna línea de su fragmento de código.

Por cierto: comencé a usar Winston no hace mucho tiempo, por lo que puede estar haciendo algo mal.

@ dmitry-salnikov, ¿qué tipo de error recibe? ¿Como "la información no es una función"? Tal vez por alguna razón, está mal importado.

@chrisvoo , por favor, eche un vistazo:

El contenido de BrowserConsole.js (puede verlo en el árbol de archivos) es exactamente como en su fragmento.

Y estoy de acuerdo contigo, siento que algo está mal con la importación, pero no puedo entender por qué :( ¿Podrías compartir tus pensamientos sobre esto?

¿Cuál es tu versión de Winston? El mio es:

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

en realidad lo mismo

$ 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"

Tratando de resolver este problema he hecho otra prueba:

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({
...

y obtuve el siguiente error: Cannot find module './combine'

Aquí está el seguimiento de la pila y el código relacionado (captura de pantalla del navegador):

Parece que algo está muy mal importado. @chrisvoo , ¿podría echar un vistazo?

En Winston 3.0.0, los transportes son flujos. Sin embargo, en browserify-stream, readableStream instanceof Stream no es cierto. Esto hace que Winston vuelva a envolver el transporte en un envoltorio heredado y emita una advertencia. Hice un PR para usar un método diferente para la detección de flujo: #1145

@Jasu cierto, también noté esto, he presentado un problema anteriormente con respecto a esto en winston-transport . También enviaré una solicitud de extracción pronto para que el transporte de la consola sea isomorfo.

IGNOREME: Estoy comentando aquí para poder encontrar fácilmente este problema nuevamente en el futuro, [ya que no puedo hacer eso suscribiéndome solo] (https://github.com/isaacs/github/issues/283).

Me encontré con el mismo problema, Error: Cannot find module './combine' .

+1

@chrisvoo : a continuación está el error, cuando intento ejecutar su fragmento (winston y winston-transport están en más de 3 versiones)
ERROR en winston-transport/index.js
Módulo no encontrado: Error: no se puede resolver 'flujo' en node_modules/winston-transport'

¿Hay alguna posibilidad de que PR #1145 (inaugurado en noviembre de 2017) se fusione este año? :guiño:

@dmitry-salnikov #1145 se fusionó con el maestro. Sin embargo, aún no está en un lanzamiento.

CERRADO CERRADO CERRADO.

Gracias por el apoyo papas

5 años, al menos está llegando a buen término. Winston sigue siendo el mejor sistema de registro para JavaScript IMO

¡Gracias!

Esto permanecerá abierto hasta que haya pruebas en nuestro conjunto de pruebas que verifiquen la compatibilidad del navegador. Sin embargo, parece que la mayoría de los casos de borde y esquina alrededor de babel y webpack se han resuelto.

Aquí nos encanta Winston y necesitamos un middleware de registro del lado del cliente.

Ha pasado un tiempo desde que se implementó el navegador y nos gustaría usarlo a partir de ahora.

¿Alguna idea aproximada de la compatibilidad del navegador, antes de esperar las pruebas unitarias y la cobertura completa del navegador?

Intenté importar Winston a mi proyecto y fallé con el siguiente mensaje:
ERROR en ./\~/winston/lib/winston/tail-file.js
Módulo no encontrado: Error: no se puede resolver 'fs' en '/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/transportes/index.js
@ ./\~/winston/lib/winston.js
@ ./src/app/app.module.ts
@ ./src/main.ts

Winston's index.js import Transports que importan '.file' que requieren 'fs'.

¿Cómo me doy de baja de este nuevo infierno?

• Miguel

El martes 7 de agosto de 2018 a las 2:19 p. m. Kfir Erez [email protected] escribió:

Intenté importar Winston a mi proyecto y fallé con lo siguiente
mensaje:
ERROR en .//winston/lib/winston/tail-file.js
Módulo no encontrado: Error: No se puede resolver 'fs' en
'/Usuarios/yo/espacios de trabajo/app/node_modules/winston/lib/winston'
@ .//winston/lib/winston/tail-file.js 10:11-24
@ .//winston/lib/winston/transports/file.js
@ .//winston/lib/winston/transportes/index.js
@ ./~/winston/lib/winston.js
@ ./src/app/app.module.ts
@ ./src/main.ts

winston's index.js import Transportes que importan '.file' que requieren
'fs'.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/winstonjs/winston/issues/287#issuecomment-410946148 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AE3lcdZ3aQKEVYvYB2TXjh0dnQ1FaBS2ks5uOTFhgaJpZM4A2vjK
.

@mjcd estás atrapado aquí para siempre 😆 (j/k, puedes darte de baja usando el enlace en el correo electrónico o a través de gh)

Tuve el mismo error que tuvo @KErez al usar el paquete web

Una forma común de resolver eso es poner node: { fs: 'empty' } en la configuración de su paquete web, y obviamente no intente usar el transporte File desde el navegador, no funcionará. Sería bueno si pudiéramos hacer el paquete winston en un paquete web sin esa configuración adicional, pero no sé si es posible. Otros paquetes populares recomiendan lo mismo, aunque https://github.com/pugjs/pug-loader/issues/8#issuecomment -328331541 sugiere que podríamos arreglar esto en winston's package.json. ¿Alguien quiere probar eso y abrir un PR si resuelve ese error (es decir, sin cambiar la configuración del paquete web de su aplicación, solo cambiando el paquete.json de winston)?

Yo recibo un error debido a setImmediate... No entiendo por qué, ya que @chrisvoo parece tener éxito con. ¿Quizás porque usas un polyfill?

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

Hice un paquete basado en el código de @chrisvoo (muchas gracias) aquí:
https://www.npmjs.com/package/winston-transport-browserconsole.

Además, hay una pequeña muestra allí para que pueda compararla con la salida predeterminada de la consola Winston.

Una forma común de resolver eso es poner el nodo: { fs: 'empty' } en la configuración de su paquete web

¿Existen planes para admitir paquetes de navegador de paquete web sin la necesidad de realizar este cambio en la configuración del paquete web?

Sería bueno si pudiéramos hacer el paquete winston en un paquete web sin esa configuración adicional, pero no sé si es posible. Otros paquetes populares recomiendan lo mismo, aunque pugjs/pug-loader#8 (comentario) sugiere que podríamos arreglar esto en el paquete.json de winston. ¿Alguien quiere probar eso y abrir un PR si resuelve ese error (es decir, sin cambiar la configuración del paquete web de su aplicación, solo cambiando el paquete.json de winston)?

@DABH Desafortunadamente, no creo que sea tan simple. Ustedes usan el campo del navegador para definir un punto de entrada diferente. Creo que puede usarse para definir un punto de entrada diferente O reemplazar ciertos módulos, como se describe en ese boleto, no ambos. Pero como parece que ya está creando su propia versión del navegador, tal vez pueda eliminarse de eso. Tomaré un pico si tengo la oportunidad este fin de semana.

¿Algún progreso en esto? Han pasado 6 años y mañana será 2020 :-)

Tal vez la solución sería volver a empaquetar Winston para que los transportadores sean su propio módulo. Suena como una mejor solución

¿Podemos usar Winston en angular? Cómo ?

@ArpithaGMGowda no con la CLI angular estándar

Entonces que podemos usar para Angular 7??
Alguna idea

Usé js-logger en mi último proyecto que funcionó muy bien y me permite enviar registros a elk aunque parece que no tuvo mucha actividad en el último año: https://github.com/jonnyreeves/js-logger
Hay buenos servicios de registro que también pueden funcionar para usted, como track.js

Estoy reescribiendo esta biblioteca en una nueva estructura que elimina la dependencia de node. Debería tenerlo terminado la próxima semana.

Problema con Winston, el código basado necesita modernizarse sin romper las características principales.

La capa de transporte necesita dividirse en sus propios submoldes que, a cambio, causarán cambios importantes que supongo que el equipo no quiere causar. Hasta el punto a menos que el equipo esté dispuesto a adoptar un nuevo ecosistema. No estoy seguro de que se apruebe el PR que se está reparando.

¿Han probado con NGX-Logger " https://www.npmjs.com/package/ngx-logger "?

@ArpithaGMGowda Supongo que para mí, no me gusta escribir una base de código que te vincule a un marco establecido. El código debe ser lo más agnóstico posible desde la interfaz de usuario hasta las llamadas de servicio. También me gusta la idea de un mecanismo unificado. ¿Por qué tener una forma para el backend y otra para el frontend?

Estoy reescribiendo esta biblioteca en una nueva estructura que elimina la dependencia de node. Debería tenerlo terminado la próxima semana.

@Jordan-Hall Me pregunto si pronto tendremos un rc (y gracias).
Tener que modificar los paquetes web de terceros para que no se rompan cuando usan nuestro proyecto/lib que usa winston es un problema.

@MarcoMedrano Es un cambio fundamental que en teoría sería una nueva biblioteca cuando la termine.

@pose ¿ Cuál es su opinión sobre la separación de las capas de transporte del paquete principal? Me gusta Winston pero el sistema ecológico necesita cambiar

Me tomó un tiempo escribir esto, pero se me ocurrió una solución algo razonable para esto.
Lo siguiente le permitirá usar los niveles de error, advertencia e información en el navegador (¡con prefijos personalizados !), y se verán así:

Para que esto funcione, debe instalar winston , logform y winston-transport como dependencias.

Aquí está el código que necesita para implementar esto.
Tenga en cuenta que esto está escrito en mecanografiado, el ejemplo de javascript está a continuación.

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));
}

y aquí está el ejemplo 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));
}

Puede cambiar los colores en la enumeración LevelColors. Si desea cambiar el formato, eche un vistazo a la línea 29.

Para agregar soporte para el nivel de depuración. establezca level en las opciones de la consola en 'debug' .
También es posible agregar soporte para todos los niveles estándar de winston, es decir: emergencia, alerta, crítico, error, advertencia, información y depuración. Si desea usar estos también, debe agregar asignar este objeto a la configuración levels en la raíz createLogger

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

y luego agregue los valores de color en la enumeración LevelColors.

Estoy luchando por obtener una imagen clara del estado de este problema. ¿Puedo usar Winston en mi aplicación React?

En realidad, no estoy muy interesado en iniciar sesión en la consola del navegador y, sinceramente, no entiendo el sentido de anular un winston console transporter cuando el console incorporado tiene el mismo propósito. ; tal vez alguien me podría ilustrar amablemente.

Mi situación es que mi aplicación React se ejecuta en un contenedor Docker detrás de un proxy nginx / Let's Encrypt, por lo que no tengo acceso a ninguna salida de la consola de JavaScript; Por lo tanto, me gustaría reenviar cualquier salida de registro a un servidor syslog.

Configuré con éxito un contenedor Docker syslog-ng que consolida la salida de registro de la base de datos, el backend y algunos otros contenedores de los que está hecho mi proyecto, pero parece que no puedo encontrar un enfoque directo/canónico para el registro del sistema salida de la interfaz React.

Antes de ir a hackear alguna tonta solución casera, ¿alguien tiene algún consejo mejor para mí?
¿Tal vez tome el código anterior y reemplace console.log por algún código que envíe el mensaje a través de la red al servidor syslog?

@ z00m1n Depende principalmente de su caso de uso. Uso winston en el navegador para registrar todas las solicitudes y llamadas de funciones que hago. Y si estoy en un entorno de producción, limito la salida solo a errores de impresión.

Y usar mi código e intercambiar la instrucción console.log con otra cosa funcionaría.

Sin embargo, antes de escribir una solución hacky para hacer que esto funcione, propondría usar centinela.

También depende de si tiene control sobre el paquete web. Lamentablemente, este increíble paquete está desactualizado desde el punto de vista arquitectónico, lo que hace que sea imposible resolverlo realmente.

@Keimeno , ¿ha notado algún comportamiento extraño o problemas de rendimiento? Realmente quiero usarlo, pero tiene que ser súper estable ya que se producirá algún registro en producción para mi caso de uso...

@gcperrin No estoy seguro de si puede llamarlo un problema de rendimiento, pero he estado ejecutando algunos puntos de referencia y obtuve los siguientes resultados:
entorno de desarrollo: registra algo en la consola
entorno prod: no registra algo pero llama a la función de registro

_console.info (entorno de desarrollo)_; 1.863s para 10.000 registros. (0,1893ms cada uno)
_logger.info (entorno de desarrollo)_: 7.980 s para 10.000 registros. (0.7980ms cada uno)

_logger.info (entorno de producción)_; 3.731s para 10.000 registros. (0,3731 ms cada uno)

Esto significa que si usa mi función para silenciar los registradores en producción, aún tendrá un código síncrono ejecutándose durante 0.3731 ms (potencialmente incluso más). Puede que no sea un problema de rendimiento, pero si tiene unos pocos cientos de registros que están en silencio en producción, puede causar que su aplicación web se retrase.

¿Alguna forma de usar Winston para continuar el inicio de sesión en el sistema de archivos en el lado del navegador?

Tengo una aplicación React y quiero almacenar los registros del lado del cliente en el sistema de archivos. Por favor amablemente sugiera algunos pensamientos.

Gracias por adelantado.