Winston: Kann winston auf dem Front-End (dh Browser) für die Protokollierung verwendet werden?

Ich habe es nicht ausprobiert, aber das könnte helfen https://github.com/farpoint/meteor-winston-client

Dies bezieht sich auf: https://github.com/flatiron/winston/issues/180

Es gibt 404 auf diesem Link @joshacheson !!

Haben Sie Fortschritte bei diesem Problem?

Basierend auf dem Feedback von #582 scheint es, dass sich jede zukünftige PR auf die Trennung von Kernlogik und Transporten konzentrieren müsste, anstatt Shims wie brfs zu verwenden. Dies wäre eine große strukturelle Änderung und würde mit ziemlicher Sicherheit eine Anleitung von Kernentwicklern in Bezug auf Stil und Ansatz erfordern, da sie letztendlich diejenigen sein werden, die dies beibehalten werden.

Die gute Nachricht ist, dass der Code größtenteils sauber und gut strukturiert ist, aber eine Anleitung von Kernentwicklern zu Stil und Ansatz benötigt. Könnte @indexzero / @pose Ihre Gedanken teilen?

Irgendwelche Fortschritte bei diesem Problem?

Mann, ich habe mir wirklich große Hoffnungen gemacht, als ich das Paket sah und dann bemerkte, dass kein Browser unterstützt wird.
Das wäre für mich im Browser wirklich genial, um einige selbstgebaute Sachen zu ersetzen.

+1

Selbe oder ich. Es hilft auch, die gleiche Protokollierungsbibliothek für Vorder- und Rückseite zu haben.

Ich habe das gerade durchsucht und es scheint eine Schande zu sein, dass es anscheinend keinen Standardclient für den Browser/andere gibt, obwohl es einen http-Transport hat.

Schade, dass ich Bunyan verwenden muss

Gibt es Neuigkeiten zu diesem Thema?

Wenn Sie es wirklich verwenden möchten, können Sie einfach einen benutzerdefinierten Transport dafür schreiben, zum Beispiel:

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

Dann können Sie es auf diese Weise verwenden:

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

Bei diesem Transport erhalten Sie eine nutzlose Warnung, da es sich um Legacy-Code handelt. Es wäre auch schön, die Möglichkeit hinzuzufügen, andere Konsolenmethoden zu verwenden ( table , dir , trace , ...), aber der Einfachheit halber ist es so, wie es ist.

Danke @chrisvoo , ich habe diese Lösung ausprobiert, aber einen Fehler bekommen:

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 Ich weiß es nicht, übrigens kann ich nicht verstehen, warum dieser Code Streams verwendet. Vielleicht war mein Anwendungsfall zu einfach. Versuchen Sie zu teilen, wie Sie es verwenden.

@chrisvoo Ich habe die BrowserConsole -Implementierung in eine separate Datei kopiert, dann den zweiten Teil des Codes in eine andere Datei eingefügt und nach dem Hinzufügen des BrowserConsole -Transportcodes (die letzte Zeile Ihres Snippets) I habs einfach probiert:

log.info('hello world');

Dann bekam ich einen Fehler und versuchte:

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

Beide Aufrufe geben denselben Fehler zurück.

Meine Umgebung, die die Verwendung von Node im Browser ermöglicht, ist Meteor.js v1.6 (Node 8.8.1). Außerdem habe ich keine Zeile Ihres Code-Snippets geändert.

Übrigens: Ich habe vor nicht allzu langer Zeit angefangen, Winston zu verwenden, also mache ich vielleicht etwas falsch.

@dmitry-salnikov welche Art von Fehler erhalten Sie? Wie "Info ist keine Funktion"? Vielleicht ist es aus irgendeinem Grund schlecht importiert.

@chrisvoo schau mal:

Der Inhalt von BrowserConsole.js (Sie können ihn im Dateibaum sehen) ist genau wie in Ihrem Snippet.

Und ich stimme Ihnen zu, ich habe das Gefühl, dass etwas mit dem Import nicht stimmt, kann aber nicht herausfinden, warum :( Könnten Sie bitte Ihre Gedanken dazu teilen?

Was ist Ihre Winston-Version? Meins ist:

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

Eigentlich gleich

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

Um dieses Problem zu lösen, habe ich einen weiteren Test gemacht:

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

und bekam den nächsten Fehler: Cannot find module './combine'

Hier ist der Stack-Trace und der zugehörige Code (Browser-Screenshot):

Scheint, als wäre etwas wirklich schlecht importiert. @chrisvoo könntest du bitte einen Blick darauf werfen?

In Winston 3.0.0 sind Transporte Streams. In browserify-stream gilt readableStream instanceof Stream jedoch nicht. Dies führt dazu, dass Winston darauf zurückgreift, den Transport in einen Legacy-Wrapper einzuwickeln und eine Warnung auszugeben. Ich habe eine PR erstellt, um eine andere Methode zur Strömungserkennung zu verwenden: #1145

@Jasu stimmt, das ist mir auch aufgefallen, ich habe diesbezüglich früher ein Problem auf winston-transport gemeldet . Ich werde auch bald eine Pull-Anfrage einreichen, damit der Konsolentransport isomorph ist.

IGNOREME: Ich kommentiere hier, damit ich dieses Problem in Zukunft leicht wiederfinden kann, [da ich das nicht tun kann, indem ich mich allein anmelde] (https://github.com/isaacs/github/issues/283).

Ich bin auf das gleiche Problem gestoßen, Error: Cannot find module './combine' .

+1

@chrisvoo : Unten ist der Fehler, wenn ich versuche, Ihr Snippet auszuführen (winston und winston-transport sind auf 3+ Versionen)
FEHLER in winston-transport/index.js
Modul nicht gefunden: Fehler: „Stream“ kann in „node_modules/winston-transport“ nicht aufgelöst werden

Gibt es eine Chance, dass PR #1145 (eröffnet im November 2017) dieses Jahr zusammengelegt wird? :zwinkern:

@dmitry-salnikov #1145 wurde zum Master zusammengeführt. Allerdings noch nicht in einer Veröffentlichung.

GESCHLOSSEN GESCHLOSSEN GESCHLOSSEN.

Danke für die Unterstützung, ihr Kartoffeln

5 Jahre, zumindest kommt es zum Tragen. Winston ist meiner Meinung nach immer noch das beste Protokollierungssystem für JavaScript

Danke!

Dies bleibt offen, bis es Tests in unserer Testsuite gibt, die die Browserunterstützung bestätigen. Es scheint jedoch, dass die meisten Rand- und Eckfälle rund um babel & webpack gelöst wurden.

Hier lieben wir Winston und brauchen eine clientseitige Logging-Middleware.

Seit der Implementierung des Browsers ist eine Weile vergangen und wir möchten ihn ab sofort verwenden.

Haben Sie eine ungefähre Vorstellung von der Browserunterstützung, bevor Sie auf Komponententests und eine vollständige Browserabdeckung warten?

Ich habe versucht, Winston in mein Projekt zu importieren, und bin mit der folgenden Meldung fehlgeschlagen:
FEHLER in ./\~/winston/lib/winston/tail-file.js
Modul nicht gefunden: Fehler: „fs“ kann in „/Users/me/workspaces/app/node_modules/winston/lib/winston“ nicht aufgelöst werden
@ ./\~/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 Transporte, die '.file' importieren, die 'fs' erfordern.

Wie kann ich mich von dieser frischen Hölle abmelden?

• Michael

Am Di, 7. August 2018 um 14:19 Uhr schrieb Kfir Erez [email protected] :

Ich habe versucht, Winston in mein Projekt zu importieren, und bin mit Folgendem gescheitert
Botschaft:
FEHLER in .//winston/lib/winston/tail-file.js
Modul nicht gefunden: Fehler: „fs“ kann nicht aufgelöst werden in
'/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 Transporte, die '.file' importieren, die erfordern
'fs'.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/winstonjs/winston/issues/287#issuecomment-410946148 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AE3lcdZ3aQKEVYvYB2TXjh0dnQ1FaBS2ks5uOTFhgaJpZM4A2vjK
.

@mjcd du steckst hier für immer fest 😆 (j/k, du kannst dich über den Link in der E-Mail oder über gh abmelden)

Ich hatte den gleichen Fehler wie @KErez bei der Verwendung von Webpack

Ein üblicher Weg, das zu lösen, ist node: { fs: 'empty' } in Ihre Webpack-Konfiguration einzufügen – und natürlich versuchen Sie nicht, den File -Transport vom Browser zu verwenden, das wird nicht funktionieren. Wäre schön, wenn wir das Winston-Bundle im Webpack ohne diese zusätzliche Konfigurationseinstellung erstellen könnten, aber idk, wenn es möglich ist. Andere beliebte Pakete empfehlen dasselbe – obwohl https://github.com/pugjs/pug-loader/issues/8#issuecomment -328331541 vorschlägt, dass wir dies in winstons package.json beheben könnten. Jemand möchte das versuchen und eine PR öffnen, wenn es diesen Fehler behebt (dh ohne die Webpack-Konfiguration Ihrer App zu ändern, nur winstons package.json zu ändern)?

Ich erhalte einen Fehler aufgrund von setImmediate... Ich verstehe nicht warum, da @chrisvoo damit erfolgreich zu sein scheint. Vielleicht, weil Sie eine Füllwatte verwenden?

Mein verwandtes Problem: https://github.com/winstonjs/winston/issues/1489

Hier ein Paket basierend auf @chrisvoo- Code erstellt (vielen Dank):
https://www.npmjs.com/package/winston-transport-browserconsole.

Außerdem gibt es dort ein kleines Beispiel, damit Sie es mit der Standardausgabe der Winston-Konsole vergleichen können.

Ein gängiger Weg, dies zu lösen, ist put node: { fs: 'empty' } in Ihrer Webpack-Konfiguration

Gibt es Pläne, Webpack-Browserpakete zu unterstützen, ohne dass diese Änderung an der Webpack-Konfiguration vorgenommen werden muss?

Wäre schön, wenn wir das Winston-Bundle im Webpack ohne diese zusätzliche Konfigurationseinstellung erstellen könnten, aber idk, wenn es möglich ist. Andere beliebte Pakete empfehlen dasselbe – obwohl pugjs/pug-loader#8 (Kommentar) vorschlägt, dass wir dies in winstons package.json beheben könnten. Jemand möchte das versuchen und eine PR öffnen, wenn es diesen Fehler behebt (dh ohne die Webpack-Konfiguration Ihrer App zu ändern, nur winstons package.json zu ändern)?

@DABH Ich glaube leider nicht, dass es so einfach ist. Ihr benutzt das Browserfeld, um einen anderen Einstiegspunkt zu definieren. Ich glaube, es kann entweder verwendet werden, um einen anderen Einstiegspunkt zu definieren ODER bestimmte Module zu ersetzen, wie in diesem Ticket beschrieben - nicht beides. Aber da Sie anscheinend bereits Ihre eigene Browserversion erstellen, kann sie möglicherweise einfach daraus entfernt werden. Ich werde bei Gelegenheit dieses Wochenende einen Höhepunkt erreichen.

Irgendwelche Fortschritte dabei? Es ist 6 Jahre her und morgen ist es 2020 :-)

Vielleicht wäre die Lösung, Winston neu zu verpacken, damit Transporter ihr eigenes Modul sind. Klingt nach einer besseren Lösung

können wir Winston in eckig verwenden? wie ?

@ArpithaGMGowda nicht mit der standardmäßigen Winkel-CLI

Was können wir dann für Angular 7 verwenden?
Irgendeine Idee

Ich habe js-logger in meinem letzten Projekt verwendet, das sehr gut funktioniert hat und es mir ermöglicht, Protokolle an Elk zu senden, obwohl es so aussieht, als hätte es im letzten Jahr nicht viel Aktivität gegeben: https://github.com/jonnyreeves/js-logger
Es gibt gute Protokollierungsdienste, die auch für Sie funktionieren könnten, wie zum Beispiel track.js

Ich schreibe diese Bibliothek in eine neue Struktur um, die die Abhängigkeit vom Knoten beseitigt. Sollte in der kommenden Woche fertig sein

Problem mit Winston, das auf Code basiert, muss modernisiert werden, ohne die Kernfunktionen zu beeinträchtigen.

Die Transportschicht muss in ihre eigenen Unterformen aufgeteilt werden, was im Gegenzug zu bahnbrechenden Änderungen führen wird, von denen ich denke, dass das Team sie nicht verursachen möchte. Auf den Punkt gebracht, es sei denn, das Team ist bereit, ein neues Ökosystem einzuführen. Ich bin mir nicht sicher, ob der PR, der repariert wird, genehmigt wird.

haben Sie es mit NGX-Logger " https://www.npmjs.com/package/ngx-logger " versucht?

@ArpithaGMGowda Ich denke, ich mag es nicht, eine Codebasis zu schreiben, die Sie in ein festgelegtes Framework einbindet. Der Code sollte von der Benutzeroberfläche bis zu Dienstaufrufen so agnostisch wie möglich sein. Ich mag auch die Idee eines einheitlichen Mechanismus. Warum einen Weg für das Backend und einen anderen für das Frontend haben

Ich schreibe diese Bibliothek in eine neue Struktur um, die die Abhängigkeit vom Knoten beseitigt. Sollte in der kommenden Woche fertig sein

@Jordan-Hall Frage mich, ob wir bald einen RC haben (und danke).
Webpacks von Drittanbietern ändern zu müssen, um nicht zu brechen, wenn sie unser Projekt/Lib verwenden, das Winston verwendet, hat Probleme.

@MarcoMedrano Es ist eine grundlegende Änderung, die theoretisch eine neue Bibliothek wäre, wenn ich sie fertigstelle.

@pose Was halten Sie von der Aufteilung der Transportschichten aus dem Kernpaket? Ich mag Winston, aber das Ökosystem muss geändert werden

Es hat eine Weile gedauert, dies zu schreiben, aber ich habe eine einigermaßen vernünftige Lösung dafür gefunden.
Im Folgenden können Sie die Fehler-, Warn- und Infoebenen im Browser verwenden (mit benutzerdefinierten Präfixen!), und sie sehen folgendermaßen aus:

Damit dies funktioniert, müssen Sie winston , logform und winston-transport als Abhängigkeiten installieren.

Hier ist der Code, den Sie benötigen, um dies zu implementieren.
Beachten Sie , dass dies in Typoskript geschrieben ist, das Javascript-Beispiel ist unten.

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

und hier ist das Javascript-Beispiel

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

Sie können die Farben in der Aufzählung LevelColors ändern. Wenn Sie die Formatierung ändern möchten, werfen Sie einen Blick auf Zeile 29.

Um Unterstützung für die Debug-Ebene hinzuzufügen. setze level in den Konsolenoptionen auf 'debug' .
Es ist auch möglich, Unterstützung für alle Standard-Winston-Stufen hinzuzufügen, d. h.: Notruf, Warnung, Krit, Fehler, Warnung, Info und Debug. Wenn Sie diese ebenfalls verwenden möchten, müssen Sie dieses Objekt der Konfiguration levels im Stammverzeichnis von createLogger zuweisen

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

und fügen Sie dann die Farbwerte in der LevelColors-Aufzählung hinzu.

Ich habe Mühe, mir ein klares Bild vom Status dieses Problems zu machen. Kann ich Winston in meiner React-App verwenden?

Ich bin eigentlich nicht so sehr daran interessiert, mich an der Browserkonsole anzumelden - und ganz ehrlich, ich verstehe nicht den Sinn darin, ein winston console transporter zu überschreiben, wenn das eingebaute console den gleichen Zweck erfüllt ; vielleicht kann mich jemand freundlicherweise aufklären.

Meine Situation ist, dass meine React-App in einem Docker-Container hinter einem nginx / Let’s Encrypt-Proxy ausgeführt wird, sodass ich keinen Zugriff auf die Ausgabe der JavaScript-Konsole habe. Ich möchte daher jede Log-Ausgabe an einen Syslog-Server weiterleiten.

Ich habe erfolgreich einen syslog-ng Docker-Container eingerichtet, der die Protokollausgabe aus der Datenbank, dem Backend und einigen anderen Containern, aus denen mein Projekt besteht, konsolidiert, aber ich kann anscheinend keinen einfachen / kanonischen Ansatz für Syslogging finden Ausgabe vom React-Frontend.

Hat jemand einen besseren Rat für mich, bevor ich eine dumme hausgemachte Lösung hacke?
Nehmen Sie vielleicht den obigen Code und ersetzen Sie console.log durch einen Code, der die Nachricht über das Netzwerk an den Syslog-Server sendet?

@ z00m1n Es hängt hauptsächlich von Ihrem Anwendungsfall ab. Ich verwende Winston im Browser, um alle Anfragen und Funktionsaufrufe zu protokollieren, die ich mache. Und wenn ich mich in einer Produktionsumgebung befinde, beschränke ich die Ausgabe nur auf Druckfehler.

Und die Verwendung meines Codes und der Austausch der console.log-Anweisung mit etwas anderem würde funktionieren.

Bevor Sie jedoch eine Hacky-Lösung schreiben, um dies zum Laufen zu bringen, würde ich vorschlagen, Sentry zu verwenden.

Es hängt auch davon ab, ob Sie die Kontrolle über Webpack haben. Leider ist dieses erstaunliche Paket architektonisch veraltet, was es unmöglich macht, es wirklich zu lösen

@Keimeno sind dir merkwürdige Verhaltens- oder Leistungsprobleme aufgefallen? Ich möchte es wirklich verwenden, aber es muss überstabil sein, da einige Protokollierungen in der Produktion für meinen Anwendungsfall stattfinden werden ...

@gcperrin Ich bin mir nicht sicher, ob Sie es ein Leistungsproblem nennen können, aber ich habe einige Benchmarks ausgeführt und die folgenden Ergebnisse erhalten:
Entwicklungsumgebung: Es protokolliert etwas an der Konsole
prod-Umgebung: Es protokolliert nichts, ruft aber die Protokollfunktion auf

_console.info (Entwicklungsumgebung)_; 1.863s für 10.000 Protokolle. (jeweils 0,1893ms)
_logger.info (Entwicklungsumgebung)_: 7.980s für 10.000 Protokolle. (jeweils 0,7980 ms)

_logger.info (Produktumgebung)_; 3.731s für 10.000 Protokolle. (jeweils 0,3731 ms)

Das bedeutet, wenn Sie meine Funktion verwenden, um die Logger in der Produktion zum Schweigen zu bringen, wird weiterhin synchroner Code für 0,3731 ms (möglicherweise sogar noch länger) ausgeführt. Es ist möglicherweise kein Leistungsproblem, aber wenn Sie einige hundert Protokolle haben, die in der Produktion stumm sind, kann dies dazu führen, dass Ihre Webanwendung verzögert wird.

Gibt es eine Möglichkeit, Winston zu verwenden, um die Anmeldung im Dateisystem auf der Browserseite beizubehalten?

Ich habe eine React-Anwendung und möchte die clientseitigen Protokolle im Dateisystem speichern. Bitte schlagen Sie einige Gedanken vor.

Vielen Dank im Voraus.