codetheweb
Open to a rewrite in Typescript?
Hi there!
Native Typescript code (with builtin types instead of a separate declaration file, which sometimes causes problems depending in TS projects depending on their config) is IMO preferable to Javascript in most cases.
Would you be open to a PR rewriting the project's code in TypeScript? If so, I'd be happy to make one.
Otherwise, no problem!
I would be more then open for that ... I also have that on my list but not yet time to start with it. most of my other maintained projects currently are TS so it is always a pain to do pure JS :-)
I will finish current PR and then would be ideal time tbh
I've started rewriting the project in TypeScript, but I'm a bit stuck as there are tons of conflicting types in various places.
For instance, take the _decryptPre34 function:
No matter how I type it, it can't work. The decipher.update method takes a string, followed by an Encoding, followed by an OutputEncoding.
The thing is, Encoding can never be "buffer" as per Node.js' documentation. Also, the data cannot be a Buffer, it must be a string. So I don't know what's supposed to happen here.
There are lots of other things like that:
The getPayload method may return false if for instance the provided string or buffer is empty. But in Packet, the payload property cannot be false.
Also, the docs show that its type should be Buffer | Object | string, but when we provide it to getPayload it can't work as this method then provides it to this.cipher.decrypt, which only takes a Buffer, not an Object or a string. So I'm a bit confused...
Could you please enlighten me on these examples? Thanks.
@ClementNerma these are the interesting pars here... I also have not that many examples.
Following logs in other issues here the data received on UDP socket level should be Buffer ... thats means you are right "prsePayload" and the package definition from they is always a Buffer for the payload. We could call this the "Internal Payload" i guess ... after that the payload is tried to be parsed into more convenient variant which might be object/string/boolean ...
maybe thats the idea for this to have a "RawPayload" and a "Payload" /aka the convenient external one)...?
For the second around the decypher ... what about that from nodejs docs:
If the inputEncoding argument is not given, data must be a Buffer. If data is a Buffer then inputEncoding is ignored.
I would assume that node.js ignores the "invalid" first parameter value when it is a buffer