File logging reconfiguration issue (Error: write after end)

Please tell us about your environment:

• winston version?
  • winston@2
  • [ X] winston@3
• _node -v outputs:_v10.15.0
• _Operating System?_Windows 10
• _Language? JavaScript (pure Node)

What is the problem?

When logger is reconfigured, the open streams are destroyed and winston tries to write to an already destroyed stream.

I created a really simple playground to replicate it (less than 10 lines of actual code): https://github.com/peterbakonyi05/winston-log-rotate-reconfiguration-issue/blob/master/index.js

What do you expect to happen instead?

winston creates a new stream and handles reconfiguration.

Note

Alternatively, instead of reconfiguring winston a new instance can be created, in case someone else has the same issue. Just call .close on the old instance and create a new from scratch.

[JadianZheng]

Still happen in 3.3.3

[apaparazzi0329]

tl;dr Pass by reference in logger.add() function causes the transport object to be altered and thus invalidated when used again in logger.configure()

I think I found the cause of this issue, stemming from the logger.add() function:

add(transport) {
    
    console.log('In add function\n')
    const target =
      !isStream(transport) || transport.log.length > 2
        ? new LegacyTransportStream({ transport })
        : transport;
  
    console.log("Original target:", JSON.stringify(target), "\n")
    if (!target._writableState || !target._writableState.objectMode) {
      throw new Error(
        'Transports must WritableStreams in objectMode. Set { objectMode: true }.'
      );
    }

    // Listen for the `error` event and the `warn` event on the new Transport.
    this._onEvent('error', target);
    this._onEvent('warn', target);
    this.pipe(target);

    console.log("Target after pipe:", JSON.stringify(target))

    if (transport.handleExceptions) {
      this.exceptions.handle();
    }

    if (transport.handleRejections) {
      this.rejections.handle();
    }

    return this;
  }

I added my own print statements to keep track of the target object. As can be seen in output from the print statements; the target object is edited after it is used for piping. Since target is equivalent to the transport parameter through pass by reference, the change to target also changes the transport object and thus makes it invalid for reuse in logger.configure(). This explains why an entirely new but identical transport would work with configure() but editing the original transport would give the error.

Probable Solution: Make a deep copy of the passed in transport object so that the target object is pass by value

This is my first time commenting on an open issue on GitHub so please let me know if I missed anything that would make this more helpful. I would have tried to create a coded solution myself but since object cloning doesn’t seem to be a native tool in JavaScript I figured it would be better for someone with more knowledge of the code base to create an actual solution