Winston: Winston peut-il être utilisé sur le front-end (c'est-à-dire le navigateur) pour la journalisation ?

Je ne l'ai pas essayé, mais cela pourrait aider https://github.com/farpoint/meteor-winston-client

Ceci est lié à : https://github.com/flatiron/winston/issues/180

Il y a 404 sur ce lien @joshacheson !!

Avez-vous des avancées sur ce problème ?

Sur la base des commentaires de # 582, il semble que tout futur PR devrait se concentrer sur la séparation de la logique de base et des transports, plutôt que sur l'utilisation de shims tels que brfs . Ce serait un changement structurel important et nécessiterait presque certainement des conseils de la part des développeurs principaux sur le style et l'approche, car ce seront finalement eux qui conserveront cela.

La bonne nouvelle est que le code est généralement propre et bien structuré, mais nécessiterait des conseils de la part des développeurs principaux sur le style et l'approche. @indexzero / @pose pourrait-il partager vos réflexions ?

Des progrès sur ce problème ?

Mec, j'ai eu de grands espoirs quand j'ai vu le paquet et que j'ai remarqué qu'il n'y avait pas de prise en charge du navigateur.
Ce serait vraiment génial pour moi dans le navigateur pour remplacer certains trucs locaux.

+1

Idem ou moi. Avoir la même bibliothèque de journalisation pour l'avant et l'arrière aide également.

Je parcourais juste ceci et il semble dommage que même s'il dispose d'un transport http, il ne semble pas y avoir de client standard pour le navigateur/autre.

Triste de devoir utiliser Bunyan

des nouvelles à ce sujet?

Si vous voulez vraiment l'utiliser, vous pouvez simplement lui écrire un transport personnalisé, par exemple :

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

Ensuite, vous pouvez l'utiliser de cette manière :

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

Avec ce transport, vous obtenez un avertissement inutile car il est considéré comme du code hérité. Il serait également intéressant d'ajouter la possibilité d'utiliser d'autres méthodes de console ( table , dir , trace , ...), mais pour des raisons de simplicité, c'est comme ça.

Merci @chrisvoo , j'ai essayé cette solution mais j'ai eu une erreur:

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 Je ne sais pas, d'ailleurs je ne comprends pas pourquoi ce code utilise des flux. Peut-être que mon cas d'utilisation était trop simple. Essayez de partager comment vous l'utilisez.

@chrisvoo J'ai copié l'implémentation BrowserConsole dans un fichier séparé, puis dans un autre fichier collé la deuxième partie du code, et après avoir ajouté le code de transport BrowserConsole (la dernière ligne de votre extrait) je 'ai simplement essayé:

log.info('hello world');

Ensuite, j'ai eu une erreur et j'ai essayé:

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

Les deux appels renvoient la même erreur.

Mon environnement qui rend possible l'utilisation de Node dans le navigateur est Meteor.js v1.6 (Node 8.8.1). De plus, je n'ai modifié aucune ligne de votre extrait de code.

BTW: J'ai commencé à utiliser winston il n'y a pas si longtemps, donc je fais peut-être quelque chose de mal.

@dmitry-salnikov quel genre d'erreur recevez-vous ? Comme "info n'est pas une fonction" ? Peut-être que pour une raison quelconque, il est mal importé.

@chrisvoo s'il vous plaît jeter un oeil:

Le contenu de BrowserConsole.js (vous pouvez le voir dans l'arborescence des fichiers) est exactement comme dans votre extrait.

Et je suis d'accord avec vous, je pense que quelque chose ne va pas avec l'importation, mais je n'arrive pas à comprendre pourquoi :( Pourriez-vous s'il vous plaît partager vos réflexions à ce sujet ?

Quelle est votre version de Winston ? Le mien est:

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

En fait le même

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

En essayant de résoudre ce problème, j'ai fait un autre test:

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

et a obtenu l'erreur suivante : Cannot find module './combine'

Voici la trace de la pile et le code associé (capture d'écran du navigateur) :

On dirait que quelque chose est vraiment mal importé. @chrisvoo pourriez-vous s'il vous plaît jeter un oeil?

Dans Winston 3.0.0, les transports sont des flux. Cependant, dans browserify-stream, readableStream instanceof Stream n'est pas vrai. Cela oblige Winston à emballer le transport dans un wrapper Legacy et à émettre un avertissement. J'ai fait un PR pour utiliser une autre méthode de détection de flux : #1145

@Jasu true, j'ai également remarqué cela, j'ai déjà soumis un problème à ce sujet sur winston-transport . Je soumettrai également une pull request prochainement pour que le transport de la console soit isomorphe.

IGNOREME : Je commente ici afin de pouvoir retrouver facilement ce problème à l'avenir, [puisque je ne peux pas le faire en m'abonnant seul] (https://github.com/isaacs/github/issues/283).

J'ai rencontré le même problème, Error: Cannot find module './combine' .

+1

@chrisvoo : ci-dessous l'erreur, lorsque j'essaie d'exécuter votre extrait (winston et winston-transport sont sur les versions 3+)
ERREUR dans winston-transport/index.js
Module introuvable : erreur : impossible de résoudre le "flux" dans node_modules/winston-transport'

y a-t-il une chance que le PR #1145 (ouvert en novembre 2017) soit fusionné cette année ? :clin d'œil:

@dmitry-salnikov #1145 a été fusionné avec master. Pas encore dans une version cependant.

FERMÉ FERMÉ FERMÉ.

Merci pour le soutien ya des pommes de terre

5 ans, au moins sa concrétisation. Winston est toujours le meilleur système de journalisation pour JavaScript IMO

Merci!

Cela restera ouvert jusqu'à ce qu'il y ait des tests dans notre suite de tests qui vérifient la prise en charge du navigateur. Il semble que la plupart des problèmes de bord et d'angle autour de Babel & Webpack aient été résolus.

Ici, nous aimons Winston et avons besoin d'un middleware de journalisation côté client.

Un certain temps s'est écoulé depuis l'implémentation du navigateur et nous aimerions l'utiliser à partir de maintenant.

Une idée approximative du support du navigateur, avant d'attendre les tests unitaires et la couverture complète du navigateur ?

J'ai essayé d'importer Winston dans mon projet et j'ai échoué avec le message suivant :
ERREUR dans ./\~/winston/lib/winston/tail-file.js
Module introuvable : erreur : impossible de résoudre 'fs' dans '/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 Transports qui importent '.file' qui nécessitent 'fs'.

Comment me désinscrire de ce nouvel enfer

• Michael

Le mardi 7 août 2018 à 14h19, Kfir Erez [email protected] a écrit :

J'ai essayé d'importer winston dans mon projet et j'ai échoué avec ce qui suit
message:
ERREUR dans .//winston/lib/winston/tail-file.js
Module introuvable : erreur : impossible de résoudre 'fs' dans
'/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 Transports qui importent '.file' qui nécessitent
'fs'.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/winstonjs/winston/issues/287#issuecomment-410946148 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AE3lcdZ3aQKEVYvYB2TXjh0dnQ1FaBS2ks5uOTFhgaJpZM4A2vjK
.

@mjcd tu es coincé ici pour toujours 😆 (j/k, tu peux te désabonner en utilisant le lien sur l'email ou via gh)

J'ai eu la même erreur que @KErez en utilisant webpack

Une façon courante de résoudre ce problème est de mettre node: { fs: 'empty' } dans votre configuration Webpack - et évidemment n'essayez pas d'utiliser le transport File depuis le navigateur, cela ne fonctionnera pas. Ce serait bien si nous pouvions créer un bundle Winston dans Webpack sans ce paramètre de configuration supplémentaire, mais idk si c'est possible. D'autres packages populaires recommandent la même chose - bien que https://github.com/pugjs/pug-loader/issues/8#issuecomment -328331541 suggère que nous pourrions résoudre ce problème dans le package.json de winston. Quelqu'un veut-il essayer cela et ouvrir un PR s'il résout cette erreur (c'est-à-dire sans modifier la configuration du pack Web de votre application, en changeant simplement le package.json de Winston) ?

Moi j'obtiens une erreur due au setImmediate... Je ne comprends pas pourquoi puisque @chrisvoo semble réussir avec. Peut-être parce que vous utilisez un polyfill ?

Mon problème connexe : https://github.com/winstonjs/winston/issues/1489

Fait un package basé sur le code @chrisvoo (merci beaucoup) ici :
https://www.npmjs.com/package/winston-transport-browserconsole.

En outre, il y a un petit échantillon là-bas afin que vous puissiez comparer avec la sortie par défaut de la console Winston.

Une façon courante de résoudre ce problème est de mettre node : { fs: 'empty' } dans votre configuration webpack

Est-il prévu de prendre en charge les ensembles de navigateurs Webpack sans qu'il soit nécessaire d'apporter cette modification à la configuration Webpack ?

Ce serait bien si nous pouvions créer un bundle Winston dans Webpack sans ce paramètre de configuration supplémentaire, mais idk si c'est possible. D'autres packages populaires recommandent la même chose - bien que pugjs/pug-loader#8 (commentaire) suggère que nous pourrions résoudre ce problème dans le package.json de winston. Quelqu'un veut-il essayer cela et ouvrir un PR s'il résout cette erreur (c'est-à-dire sans modifier la configuration du pack Web de votre application, en changeant simplement le package.json de Winston) ?

@DABH Malheureusement, je ne pense pas que ce soit aussi simple. Vous utilisez le champ du navigateur pour définir un point d'entrée différent. Je pense qu'il peut être utilisé pour définir un point d'entrée différent OU remplacer certains modules, comme décrit dans ce ticket - pas les deux. Mais puisque vous construisez déjà votre propre version de navigateur, il semble qu'il puisse peut-être simplement être supprimé de cela. Je vais prendre un pic si j'ai une chance ce week-end.

Des progrès à ce sujet? Cela fait 6 ans et demain ce sera 2020 :-)

Peut-être que la solution serait de reconditionner winston afin que les transporteurs soient leur propre module. Cela ressemble à une meilleure solution

peut-on utiliser Winston en angulaire ? comment ?

@ArpithaGMGowda pas avec la CLI angulaire standard

Alors que pouvons-nous utiliser pour Angular 7 ??
Une idée

J'ai utilisé js-logger dans mon dernier projet qui a très bien fonctionné et me permet d'envoyer des journaux à elk bien qu'il semble qu'il n'ait pas eu beaucoup d'activité l'année dernière : https://github.com/jonnyreeves/js-logger
Il existe de bons services de journalisation qui peuvent également fonctionner pour vous, tels que track.js

Je réécris cette bibliothèque dans une nouvelle structure qui supprime la dépendance au nœud. Il devrait être terminé la semaine prochaine

Problème avec Winston, le code doit être modernisé sans casser les fonctionnalités de base.

La couche de transport doit être divisée en ses propres sous-moules, ce qui entraînera en retour des changements de rupture que je suppose que l'équipe ne veut pas provoquer. Au point à moins que l'équipe ne veuille adopter un nouvel éco système. Je ne suis pas sûr que le PR qui est en cours de réparation sera approuvé.

êtes-vous des personnes essayées avec NGX-Logger " https://www.npmjs.com/package/ngx-logger " ?

@ArpithaGMGowda Je suppose que pour moi, je n'aime pas écrire une base de code qui vous lie à un cadre défini. Le code doit être aussi indépendant que possible de l'interface utilisateur aux appels de service. J'aime aussi l'idée d'un mécanisme unifié. Pourquoi avoir un chemin pour le backend et un autre pour le frontend

Je réécris cette bibliothèque dans une nouvelle structure qui supprime la dépendance au nœud. Il devrait être terminé la semaine prochaine

@Jordan-Hall Je me demande si nous aurons bientôt un rc (et merci).
Devoir modifier des webpacks tiers afin de ne pas casser lorsqu'ils utilisent notre projet/lib qui utilise winston est difficile.

@MarcoMedrano C'est un changement fondamental qui serait en théorie une nouvelle bibliothèque le temps que je le termine.

@pose Quel est votre point de vue sur la séparation des couches de transport du package principal ? J'aime Winston mais l'écosystème doit changer

Il a fallu du temps pour écrire ceci, mais j'ai trouvé une solution quelque peu raisonnable à cela.
Ce qui suit vous permettra d'utiliser les niveaux d'erreur, d'avertissement et d'information dans le navigateur (avec des préfixes personnalisés !), et ils ressembleront à ceci :

Pour que cela fonctionne, vous devez installer winston , logform et winston-transport en tant que dépendances.

Voici le code dont vous avez besoin pour implémenter cela.
Notez que ceci est écrit en tapuscrit, l'exemple javascript est ci-dessous.

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

et voici l'exemple 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));
}

Vous pouvez modifier les couleurs dans l'énumération LevelColors. Si vous souhaitez modifier la mise en forme, jetez un œil à la ligne 29.

Pour ajouter la prise en charge du niveau de débogage. définissez le level dans les options de la console sur 'debug' .
Il est également possible d'ajouter la prise en charge de tous les niveaux Winston standard, c'est-à-dire : emerg, alert, crit, error, warn, info et debug. Si vous souhaitez également les utiliser, vous devez ajouter cet objet à la configuration levels dans la racine de createLogger.

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

puis ajoutez les valeurs de couleur dans l'énumération LevelColors.

J'ai du mal à me faire une idée claire de l'état de ce problème. Puis-je utiliser Winston dans mon application React ?

En fait, je ne suis pas tellement intéressé par la connexion à la console du navigateur - et très honnêtement, je ne comprends pas l'intérêt de remplacer un winston console transporter lorsque le console intégré sert le même objectif ; peut-être que quelqu'un pourrait m'éclairer gentiment.

Ma situation est que mon application React s'exécute dans un conteneur Docker derrière un proxy nginx / Let's Encrypt, donc je n'ai accès à aucune sortie de console JavaScript ; Je voudrais donc transmettre toute sortie de journal à un serveur syslog.

J'ai configuré avec succès un conteneur Docker syslog-ng qui consolide la sortie du journal de la base de données, du backend et de certains autres conteneurs dont mon projet est composé, mais je n'arrive pas à trouver une approche simple / canonique de la journalisation systématique sortie de l'interface React.

Avant de commencer à pirater une solution maison stupide, quelqu'un a-t-il de meilleurs conseils pour moi?
Peut-être prendre le code ci-dessus et remplacer console.log par un code qui envoie le message sur le réseau au serveur syslog ?

@ z00m1n Cela dépend principalement de votre cas d'utilisation. J'utilise winston dans le navigateur pour enregistrer toutes les requêtes et tous les appels de fonction que je fais. Et si je suis dans un environnement de production, je limite la sortie aux seules erreurs d'impression.

Et utiliser mon code et échanger l'instruction console.log avec autre chose fonctionnerait.

Cependant, avant d'écrire une solution hacky pour que cela fonctionne, je proposerais d'utiliser sentinelle.

Cela dépend également si vous contrôlez Webpack. Malheureusement, ce package étonnant est obsolète sur le plan architectural, ce qui le rend impossible à résoudre réellement.

@Keimeno avez-vous remarqué un comportement étrange ou des problèmes de performances ? Je veux vraiment l'utiliser, mais il doit être extrêmement stable car une certaine journalisation se produira en production pour mon cas d'utilisation...

@gcperrin Je ne sais pas si vous pouvez appeler cela un problème de performances, mais j'ai exécuté quelques tests de performance et obtenu les résultats suivants :
environnement de développement : il enregistre quelque chose dans la console
environnement prod : il n'enregistre rien, mais il appelle la fonction log

_console.info (environnement de développement)_ ; 1.863s pour 10.000 logs. (0,1893ms chacun)
_logger.info (environnement dev)_ : 7.980s pour 10.000 logs. (0,7980 ms chacun)

_logger.info (environnement de production)_ ; 3.731s pour 10.000 logs. (0,3731 ms chacun)

Cela signifie que si vous utilisez ma fonction pour faire taire les enregistreurs en production, vous aurez toujours du code synchrone en cours d'exécution pendant 0,3731 ms (potentiellement encore plus). Il ne s'agit peut-être pas d'un problème de performances, mais si vous avez quelques centaines de journaux silencieux en production, cela peut entraîner un décalage de votre application Web.

Un moyen d'utiliser winston pour persister à se connecter au système de fichiers du côté du navigateur?

J'ai une application React et je souhaite stocker les journaux côté client dans le système de fichiers. Merci de bien vouloir suggérer quelques réflexions.

Merci d'avance.