Don't modify arguments passed to logging methods

Please tell us about your environment:

• winston version?
  • winston@2
  • winston@3
• node -v outputs: v11.4.0
• Operating System? (Linux)
• Language? (ES6/7)

What is the problem?

Winston modifies objects passed to it!

I have a webservice with error handler:

   handleError(err, req, res, next) {
     winston.warn(err)
     res.status(err.status || err.statusCode || 500).json(err)
   }

I expect, say, a 404 response with body {"message":"Not Found"}, but with the winston.warn call included, it becomes {"message":"Not Found","level":"warn"}. Of course, it’s worse after going through formatters—I get tabs, ANSI color codes, etc.—but out of the box I still get the level property.

What do you expect to happen instead?

No mutation

Other information

[dpurrington]

The log utility we use can’t have side effects. This is a deal-breaker for us, unfortunately.

[indexzero]

This is by design. The README for info clearly states that the objects are mutable. In this particular case, you could avoid the mutability if you wished, but opting not to use the convenience method .warn. Instead:

winston.log({ level: 'warn', ...err });

@sparkida unfortunately there is no easy way to handle all permutations of possible inputs that folks which to provide. In particular the desire of most developers includes:

1. Variable-arity (e.g. logger.log('info', 'Interpolate %s [%j]', 'please', { myData: 'stuff' }))
2. Using errors as “data” objects (as in this case) – despite Error instances having non-enumerable properties.

… and many others. In general from a historical perspective, winston@1, and winston@2 did clone each object that was passed to it. This led to an significantly lower performance – which as a project we sought to fix in winston@3.

There are trade-offs for performance vs. features. We opt for performance whenever possible.