oson doesn't work with Bun

[8549]

oson, which grammY's conversations plugin depends on, doesn't work with Bun (v1.0.14).
I think that merging #8 will fix this issue too.
Thanks

100 |   var keys = Object.keys(add), i = keys.length;
101 |   while (i--)
102 |     origin[keys[i]] = add[keys[i]];
103 |   return origin;
104 | 
105 | }, kCustomPromisifiedSymbol = Symbol.for("nodejs.util.promisify.custom"), promisify = function promisify2(original) {
                      ^
TypeError: The "original" argument must be of type Function
      at promisify2 (node:util:105:210)
      at node_modules/.deno/@deno+shim-deno@0.9.0/node_modules/@deno/shim-deno/dist/deno/stable/functions/fdatasync.js:7:6
      at globalThis (node_modules/.deno/@deno+shim-deno@0.9.0/node_modules/@deno/shim-deno/dist/deno/stable/functions/fdatasync.js:8:20)
      at overridableRequire (:1:20)
      at node_modules/.deno/@deno+shim-deno@0.9.0/node_modules/@deno/shim-deno/dist/deno/stable/functions.js:40:4
      at globalThis (node_modules/.deno/@deno+shim-deno@0.9.0/node_modules/@deno/shim-deno/dist/deno/stable/functions.js:158:104)
      at overridableRequire (:1:20)
      at node_modules/.deno/@deno+shim-deno@0.9.0/node_modules/@deno/shim-deno/dist/deno/stable/main.js:19:0

[KnorpelSenf]

#8 has merge conflicts. Do you want to fix them?

[KnorpelSenf]

Besides, there's no attempt at being compatible with bun. They promise to be compatible with Node. We actually are compatible with Node, and if they don't live up to their promises, then that's their problem, not ours.

[8549]

#8 has merge conflicts. Do you want to fix them?

I'm not very expert but I could give it a shot.

Besides, there's no attempt at being compatible with bun.

Understandable, but I think this issue and #7 could be seen as a reason to improve and make this library runtime-independent, if possible.

They promise to be compatible with Node. We actually are compatible with Node, and if they don't live up to their promises, then that's their problem, not ours.

I agree with this, they have yet to implement some Node features and can't claim to be a full replacement. But I think (if the common goal is to make grammY available to the biggest audience possible) it's reasonable to expect that the issue can be easily and promptly fixed library-side than waiting for a runtime (way bigger project) to implement new features.

[KnorpelSenf]

if the common goal is to make grammY available to the biggest audience possible

While this is generally a goal, it does not imply that we want to support every single runtime out there. We do have to factor in the maintenence burden. It is already quite high with all the edge runtimes that we support in addition to Deno+Node.

I do not want to spend time on Bun. If we would actually start caring about Bun, we would have to fix a myriad of other things in the entire ecosystem, and this is too much work. I do not want to signal to people that there is a chance of me spending any time on this, so I already don't do the small things.

That is to say, if there are improvements of any kind and they accidentally solve some of the problems with Bun, I'm happy to merge them. However, there won't be any workarounds or changes to the code or build system just because Bun is too immature. That would lead to way more follow-up questions than I'm willing to spend time on.

[KnorpelSenf]

Closing since I'm still not interested in Bun.