Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Property 'fatal' does not exist on type 'Logger' #2188

Open
OxyTJ opened this issue Sep 4, 2022 · 10 comments
Open

[Bug]: Property 'fatal' does not exist on type 'Logger' #2188

OxyTJ opened this issue Sep 4, 2022 · 10 comments

Comments

@OxyTJ
Copy link

OxyTJ commented Sep 4, 2022

🔎 Search Terms

Property 'fatal' does not exist on type 'Logger'

The problem

Custom createLogger logger with custom log levels receives a Property 'fatal' does not exist on type 'Logger' intellisense error for logger.fatal. All other log levels work just fine. Unfortunately, this is causing npm run dev to fail:

api:dev:     return new TSError(diagnosticText, diagnosticCodes, diagnostics);
api:dev:            ^
api:dev: TSError: ⨯ Unable to compile TypeScript:
api:dev: src/index.ts(37,17): error TS2339: Property 'fatal' does not exist on type 'Logger'.

What version of Winston presents the issue?

^3.8.1

What version of Node are you using?

v16.13.0

If this worked in a previous version of Winston, which was it?

N/A

Minimum Working Example

import winston from 'winston';
const { format, transports, addColors, createLogger } = winston;
const { combine, colorize, timestamp, printf } = format;
const { NODE_ENV } = process.env;

const LOG_LEVELS = {
  levels: {
    fatal: 0,
    error: 1,
    warn: 2,
    info: 3,
    debug: 4,
  },
  colors: {
    fatal: 'red',
    error: 'red',
    warn: 'yellow',
    info: 'cyan',
    debug: 'green',
  },
};

const printFormat = printf(({ timestamp, level, message, ...rest }) => {
  let msg = `${timestamp} [${level}] ${message}`;
  if (Object.keys(rest).length > 0) msg += `, ${JSON.stringify(rest)}`;
  return msg;
});

const minLevel = NODE_ENV === 'production' ? 'info' : 'debug';

const consoleTransport = () => {
  return new transports.Console({
    level: minLevel,
    format: combine(
      colorize({ level: true, message: true }),
      timestamp(),
      printFormat
    ),
  });
};

const OPTIONS = {
  levels: LOG_LEVELS.levels,
  transports: [consoleTransport()],
  exceptionHandlers: [consoleTransport()],
  rejectionHandlers: [consoleTransport()],
};

addColors(LOG_LEVELS.colors);

export default createLogger(OPTIONS);

Additional information

No response

@OxyTJ
Copy link
Author

OxyTJ commented Sep 4, 2022

Side note, I had a thought that maybe it was because fatal started at 0, so I incremented all of them by 1, but that did not make a difference, just fyi.

I also installed @types/winston to no avail.

@OxyTJ
Copy link
Author

OxyTJ commented Sep 6, 2022

Using LoggerService.log('fatal', <message>); for the time being.

@kumarayushkumar
Copy link

Facing the same issue

@OxyTJ
Copy link
Author

OxyTJ commented Jan 14, 2024

Facing the same issue

Doesn't look like you can use fatal or custom levels as methods, you'll have to do .log(<fatal-or-custom-level>, <message>);.

@kumarayushkumar
Copy link

Facing the same issue

Doesn't look like you can use fatal or custom levels as methods, you'll have to do .log(<fatal-or-custom-level>, <message>);.

yes, it's working now
thank you

@voilacf
Copy link

voilacf commented Mar 15, 2024

Had the same issue using Typescript. If you don't use the default levels from the Winston npm package, Typescript will throw you an error. My code looks a bit different but after calling "createLogger()" try to add:
"as winston.Logger & Record<keyof typeof LOG_LEVELS['levels'], winston.LeveledLogMethod>;"

Like that you can add whatever level you want, it's more a typescript issue than a Winston issue, when using JavaScript I don't face the same implications.

Take a look at my source, in case you need further explanation: https://stackoverflow.com/questions/53298354/winston-custom-log-levels-typescript-definitions

@OxyTJ
Copy link
Author

OxyTJ commented Mar 15, 2024

Had the same issue using Typescript. If you don't use the default levels from the Winston npm package, Typescript will throw you an error. My code looks a bit different but after calling "createLogger()" try to add: "as winston.Logger & Record<keyof typeof LOG_LEVELS['levels'], winston.LeveledLogMethod>;"

Like that you can add whatever level you want, it's more a typescript issue than a Winston issue, when using JavaScript I don't face the same implications.

Take a look at my source, in case you need further explanation: https://stackoverflow.com/questions/53298354/winston-custom-log-levels-typescript-definitions

Oh, I like this, I'll have to give it a look, thanks! Only concern I have - and again this is a TypeScript issue not Winston issue - is for my LoggerService that I created, I install it in my other applications, and I have methods for allowing creating different log levels for each project, if it were ever required. So, it's basically a wrapper for winston and I'm not aware whether I could change the "as" statement dynamically at run time when the levels would be set in other applications. Rather than setting the levels through a .env, for example, I import my installed service and then call a setLevels method in the server index.ts to apply any custom levels. Could remedy it by using .env, but I'm inclined to only do that for my applications, not my packages.

@voilacf
Copy link

voilacf commented Mar 15, 2024

But why would you want different log levels? Would it not be better to define a standard that applies to each application, ensuring they use the same set of log levels? When thinking about analysing incoming logs, I'd say that will help keeping it consistent. Feel free to share your opinion why I might be wrong.

@OxyTJ
Copy link
Author

OxyTJ commented Mar 15, 2024

You're not wrong at all, and that's what I've done. I do have a standard for all of my applications, in which the wrapper defaults to automatically. However, I still would like to build the package to be flexible enough to work for any other standards other than just mine. Package is private and most likely forever will be, it's soley for the sake of flexibility.

@voilacf
Copy link

voilacf commented Mar 15, 2024

Oh, I see. Now it makes more sense to me. In case you find a solution, you could post it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants