Winston: Консольный транспорт не записывается в консоль отладки

Созданный на 6 дек. 2018  ·  9Комментарии  ·  Источник: winstonjs/winston

Расскажите, пожалуйста, о вашей среде:

  • _ winston версия? _

    • [] winston@2

    • [x] winston@3

  • _ node -v выходы: v10.1.0
  • _Операционная система? _ Windows
  • _Language? _ TypeScript

В чем проблема?

Когда я использую встроенный транспорт консоли, он будет писать в консоль при нормальной работе (например, node ./dist/index.js ), но не в консоль отладки, когда я отлаживаю из Visual Studio Code. Стандартные вызовы console.log () / warn () / error () записываются в консоль отладки.

Что вы ожидаете вместо этого?

Я ожидаю, что все сообщения будут записываться в консоль отладки, как и в стандартную консоль при нормальной работе.

Дополнительная информация

Проблема, похоже, заключается в использовании _stderr.write () и _stdout.write () в методе log () реализации транспорта. Если я заменю условие в операторах if в пунктах 49, 62 и 77 на false чтобы вызывались стандартные функции console.log () / warn () / error (), вывод действительно достигал вывода консоли . Очевидно, нежелательным побочным эффектом является то, что пользовательский eol игнорируется.

bug help wanted important

Самый полезный комментарий

Я только что столкнулся с этой проблемой и хотел добавить свою очень простую идею: просто используйте console.log , console.warn и console.error 😄

Прямо сейчас Winston проверяет [console._stderr] и [console._stdout], предпочитая писать в эти потоки напрямую, но возвращается к использованию console.warn , console.error и console.log если недоступно. Эти свойства ( _stderr и _stdout ) доступны в экземпляре глобальной консоли в node.js, однако они не задокументированы как часть [console] API и не являются перечисляемыми .

В чем преимущество использования потоков непосредственно в Winston вместо вызова методов? Для меня console в контексте Javascript означает конкретно объект console , а не «консоль» в целом или как прокси для потоков. Разве методы не всегда работают? Тем более, что в Winston есть встроенный транспорт stream , я бы интерпретировал «консоль» как подходящую для локальной разработки.

VS Code имеет _соответствующие свойства (вероятно, потому, что он работает на узле), но его "захват" по умолчанию для консоли отладки - "console", что, вероятно, означает, что они установили хуки специально для вызовов console.log , а не сами потоки. Т.е. VS Code генерирует вывод, но не записывает его. Вероятно, это связано с этим файлом

Как уже упоминалось, вы можете изменить, какой вывод VS Code захватывает, или изменить то, что «консольный» транспорт делает в Winston.

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch Program",
      "program": "${workspaceFolder}/index.js",
      // Capture "std" instead of "console"
      "outputCapture": "std"
    }
  ]
}

Обратите внимание: если вы последуете связанному совету от @ adi7ya , VS Code выведет строку, в которой был вызван console.log - это не то место, где вы вызвали Winston, а строку в вашем замещенном log . Так что это может быть лишь незначительно полезным ...

Все 9 Комментарий

Похоже на ошибку vscode - почему в их консоли отладки есть такие реквизиты, как _stdout если мы не можем успешно писать в нее таким образом? Конечно, у вас может быть модифицированный транспорт, такой как обходной путь, который работает для vscode, но это может быть не идеально. Если вы думаете, что это то, что нужно исправить в Winston, не стесняйтесь предлагать какие-либо идеи :) Но я не думаю, что Winston должен проверять, работает ли он в vscode, скорее похоже, что консоль vscode должна вести себя лучше.

@sirockin Вы разрабатываете расширение vscode? Я столкнулся с подобной проблемой во всоде. В любом случае вы можете переопределить метод журнала для транспорта консоли, чтобы он работал.

Мы должны решить эту проблему, но нам необходимо дополнительное расследование.

Я только что столкнулся с этой проблемой и хотел добавить свою очень простую идею: просто используйте console.log , console.warn и console.error 😄

Прямо сейчас Winston проверяет [console._stderr] и [console._stdout], предпочитая писать в эти потоки напрямую, но возвращается к использованию console.warn , console.error и console.log если недоступно. Эти свойства ( _stderr и _stdout ) доступны в экземпляре глобальной консоли в node.js, однако они не задокументированы как часть [console] API и не являются перечисляемыми .

В чем преимущество использования потоков непосредственно в Winston вместо вызова методов? Для меня console в контексте Javascript означает конкретно объект console , а не «консоль» в целом или как прокси для потоков. Разве методы не всегда работают? Тем более, что в Winston есть встроенный транспорт stream , я бы интерпретировал «консоль» как подходящую для локальной разработки.

VS Code имеет _соответствующие свойства (вероятно, потому, что он работает на узле), но его "захват" по умолчанию для консоли отладки - "console", что, вероятно, означает, что они установили хуки специально для вызовов console.log , а не сами потоки. Т.е. VS Code генерирует вывод, но не записывает его. Вероятно, это связано с этим файлом

Как уже упоминалось, вы можете изменить, какой вывод VS Code захватывает, или изменить то, что «консольный» транспорт делает в Winston.

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch Program",
      "program": "${workspaceFolder}/index.js",
      // Capture "std" instead of "console"
      "outputCapture": "std"
    }
  ]
}

Обратите внимание: если вы последуете связанному совету от @ adi7ya , VS Code выведет строку, в которой был вызван console.log - это не то место, где вы вызвали Winston, а строку в вашем замещенном log . Так что это может быть лишь незначительно полезным ...

Проверка у разработчиков VS Code, чтобы узнать, можем ли мы сделать необходимые настройки vsc для вывода консольного транспорта с сохранением значений по умолчанию: https://github.com/Microsoft/vscode/issues/69959 . В противном случае необходимые изменения настроек vsc связаны с моим комментарием. ^^ Это уместный вопрос для консольного транспорта: если куча популярных редакторов не будет делать «правильные» вещи по умолчанию, то, возможно, нам следует просто изменить поведение консольного транспорта cc @indexzero .

Это тоже укусило меня, я не мог больше согласиться с @victorandree.

Я использую этот самый простой транспорт в своих целях, если кто-то еще сочтет его полезным:

import winston from "winston";
import Transport from "winston-transport";

const { MESSAGE } = require("triple-beam");
const level = process.env.LOG_LEVEL || "info";

class SimpleConsoleTransport extends Transport {
  log = (info: any, callback: any) => {
    setImmediate(() => this.emit("logged", info));

    console.log(info[MESSAGE]);

    if (callback) {
      callback();
    }
  };
}

export const logger = winston.createLogger({
  level,
  defaultMeta: {},
  transports: [new SimpleConsoleTransport()]
});

Пожалуйста, ознакомьтесь с моим предложением по решению этой проблемы в # 1836.

Также столкнулся с этой проблемой, и, похоже, она не связана с VSCode - если я запускаю node --inspect а затем присоединяюсь к нему из Chrome с помощью chrome://inspect я вижу только вызовы console.log/etc и ничего не отправляется в консольный транспорт.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги