bytebuffer.js icon indicating copy to clipboard operation
bytebuffer.js copied to clipboard

Passing Long.js to writeInt64 Fails with Type Error

Open kbahr opened this issue 7 years ago • 3 comments

I'm using nodejs, I have a transitive dependency on bytebuffer, and when I pass Long.UZERO I get a type error from this line: https://github.com/dcodeIO/bytebuffer.js/blob/master/dist/bytebuffer-node.js#L1042

I've validated that UZero has the right structure, including the isLong property but that instanceof call fails. I know this is kind of a symptom of node but wouldn't it be better to have duck type checks rather than instanceof to allow better interop?

kbahr avatar Feb 06 '18 18:02 kbahr

Might be that your node_modules has multiple (maybe nested) versions of the long package. We can use duck-typing there, but I'd not agree that it is generally better. For instance, if there'd be any breaking API-changes between the two (which is unlikely for long.js, but perfectly possible for other packages), things would go haywire anyway.

dcodeIO avatar Feb 06 '18 21:02 dcodeIO

Sorry I was unclear - I didn't mean that duck typing is always better :) I just meant in this case, it's possible to have node_module versions that are slightly out of sync through no fault or intention and the error seems nonsensical at first blush.

I'll check that I'm using a consistent version of the long package but as I said, this is a transitive dependency and doesn't seem sustainable if I end up needing to reconcile across multiple dependencies. Maybe that's a n00b thing to say - I'm hardly a NodeJS master :)

kbahr avatar Feb 06 '18 23:02 kbahr

Alright, I've verified that both the library I'm using that depends on ByteBuffer/Long matches the version that I have in my package-lock file. It seems that they still conflict because the dependencies/modules don't collapse to a single source. Is this possibly an artifact of Flow types or Babel or some build tool silliness interacting with node_modules?

kbahr avatar Feb 08 '18 03:02 kbahr