I agree with your concerns -- it would probably be better if colorizer accepted a force option which would set colors.enabled=true; if true, but otherwise winston doesn't mess with colors. That way by default colorizer will do whatever colors thinks is the right thing, which is usually correct :) . Want to make a quick PR for that change?

Have the same problem and the same question "why".
However, I prefer to do a different workaround to delegate colors module to decide rather than provide environment variables.

Here, if anyone finds my (simplified) example useful:

'use strict';
// IMPORTANT! colors.enabled value must be captured before Winston imported!
const colorsEnabled = require('colors/safe').enabled;
const winston = require('winston');

winston.add(
    new winston.transports.Console({
        format: winston.format.combine(
            colorsEnabled // the rest is pretty much the same idea as @aldofunes
                ? winston.format.colorize({ all: false })
                : winston.format(i => i)(),
            winston.format.simple()
        )
    })
);

winston.warn('Some warning');

@DABH, once I have a chance to do PR, what would be the force desirable default? Naturally I would expect false but not sure how bad that is from backwards compatibility behavior standpoint.

Maybe it's worth to note that unless colors are forced, an app running in a docker container will not produce a colorized output if -t, --tty is not specified in docker run command