Hey, looks like the type definitions for winston are managed separately and so can become out of sync with the code or have mistakes in them
The first issue – new Transport(); “winston_Transport is not a constructor” also happens just the same in typescript
// typescript
import {transport} from 'winston';
new transport({});
When I compile and run this I get
new winston_1.transport({});
^
TypeError: winston_1.transport is not a constructor
But there’s no error from typescript – this is because winston’s type definitions incorrectly say that transport is an exported member of the ‘winston’ module when it isn’t (you could open an issue on their repo).
The docs seem to suggest Transport is exported in the module ‘winston-transport’ so if you want to use that class you could do
npx dts2hx winston-transport
Then add --library winston-transport and finally use it like new WinstonTransport(); (which I’ve tested works). So dtshx is working as expected there – the index.d.ts file needs correcting.
On FileTransportInstance, looking at the index.d.ts file, the developers have used interface for everything – I’m not sure that’s what they mean to do semantically, I think many of those types should be defined as classes, however in spite of that, it would be nice if dts2hx could support interfaces with constructors. It’s not trivial because haxe doesn’t have native support for this (I’ve explored this before in [js] Constructible variable · Issue #9335 · HaxeFoundation/haxe · GitHub). I can enable this in dts2hx by wrapping these types in abstracts like
typedef F = {
@:optional
var filename : String;
}
@:forward
abstract FConstructable(F) to F from F {
public inline function new() {
this = js.Syntax.construct('F');
}
}
But this requires some pretty big changes to dts2hx to make work so it’ll take a while before I get to it I’m afraid (but it is on the roadmap)
Best thing I can suggest for now is to explore improving winston’s .d.ts files as I don’t see a quick-fix haxe-side