Revert to prototypal-based syntax for backwards compatibility

[indexzero]

Following the discussion on winstonjs/winston-daily-rotate-file#154 and #22 this is a proposal to revert Transport and LegacyTransport to the backwards compatible prototypal syntax.

There are a few reasons this makes sense:

1. Avoid common pitfall Since winston-transport is a dependency of winston it is likely (although not guaranteed) that other Transport authors will fail to include it in their own dependencies.
2. Optimize against gotchas There are a plethora of winston@2 transports out there that use Transport.call(this, opts). Even as those transports upgrade over the next while there will still be a lot of "example" code out there for folks to stub their toes on. Moving to this syntax avoids those potential gotchas.
3. Simplify upgrade path There is a great discussion in Transports and v2 to v3 migration winston#1331 that brings to light a challenge for transport authors: how to make things work with winston@2 and winston@3 while the community migrates their code? By keeping the inheritance patterns the same we make this easier for them.

@ChrisAlderson @DABH @jcrugzz @mattberther thoughts?

[mattberther]

I'm not completely sold on the need for this. In winston-daily-rotate-file, it highlighted a legitimate issue that needed to be corrected (in that I was not explicitly depending on winston-transport). It is my opinion that transport authors need to address this, and I'd prefer not to keep something in place to work around these types of things.

Just my $.02.

[indexzero]

Thanks for the input @mattberther, but after investigating winstonjs/winston#1280 I am even more convinced we have to go this route. If we don't then the work we did to ensure maximum backwards compatibility with LegacyTransportStream is wasted. Let me explain:

1. le_node (LogEntries API client) defines a winston transport.
2. It inherits from winston.Transport – and assumes winston exists as a peerDependency.

The relevant code is:

const Transport = winston.Transport;
class LogentriesTransport extends Transport {

In this particular case we would be OK because it is defined with ES6 classes. What would happen if it was this syntax?

const Transport = winston.Transport;
function LogentriesTransport(opts) {
  Transport.call(this, opts);

... it would die for just this, breaking backwards compatibility.

[mattberther]

I see. Good point. 👍